sitemap大家非常熟悉，但是如何更好利用sitemap，百度建議您開啟Etag。現(xiàn)在我們就來講講Etag：

Etag簡介

Etag(Entity Tags)是URL的tag，用來標示URL對象是否改變，這樣可利用客戶端（例如瀏覽器）的緩存。由服務器首先產(chǎn)生Etag，客戶端通過將該記號傳回服務器要求服務器驗證其（客戶端）緩存。服務器使用它來判斷頁面是否已經(jīng)被修改，如果未修改返回304，而不必重新傳輸整個對象。

sitemap現(xiàn)存弊端

1.發(fā)現(xiàn)更新不及時

當站點或其sitemap發(fā)生更新時，百度難以及時發(fā)現(xiàn)并響應，因為百度難以無時無刻地持續(xù)檢查站點內(nèi)容和sitemap是否更新。

2.全量抓取，消耗帶寬

現(xiàn)在百度對站點sitemap的抓取會將sitemap文件完整下載下來，鑒于sitemap文件一般較大，而這種下載可能存在多次，故比較消耗網(wǎng)站的流量和帶寬。站點啟用Etag的好處 1.對sitemap啟用ETag后，百度可以更快速地響應sitemap的更新，沒有更改內(nèi)容的情況下，服務器只發(fā)回304應答頭，對流量的消耗極小，在每個head平均227B大小的通常情形下，一整天24小時每秒都回應的流量消耗僅為18.7M。

2.現(xiàn)在站長平臺對每個站點的sitemap主動抓取次數(shù)設有上限，且這項功能沒有對所有站開放，如果您的站點sitemap啟用了ETag，并通過了測試，那么就可以用很小的流量享受百度及時更新您的sitemap的功能，以便于百度更好地收錄您網(wǎng)站的內(nèi)容。Etag的作用 HTTP1.1用Etag來判斷請求的文件是否被修改，主要為了解決Last-Modified無法解決的一些問題：

1、一些文件也許會周期性的更改，但是他的內(nèi)容并不改變(僅僅改變的修改時間)，這個時候并不希望客戶端認為這個文件被修改了重新GET;

2、某些文件修改非常頻繁， 1秒內(nèi)修改了N次，If-Modified-Since能檢查到的粒度是秒級的，這種修改無法判斷；

3、某些服務器不能精確的得到文件的最后修改時間。

為此，HTTP1.1引入了Etag. 但標準并沒有規(guī)定Etag的內(nèi)容是什么或者說要怎么實現(xiàn)，唯一規(guī)定的是Etag需要放在雙引號內(nèi)。Etag由服務器端生成，客戶端通過If-Match或者說If-None-Match這個條件判斷請求來驗證資源是否修改。我們常見的是使用If-None-Match.請求一個文件的流程可能如下：

第一次請求：

1.客戶端發(fā)起HTTP GET請求一個文件；

2.服務器處理請求，返回文件內(nèi)容和一堆Header，當然包括Etag(例如"1ec5-502264e2ae4c0")(假設服務器支持Etag生成和已經(jīng)開啟了Etag). 狀態(tài)碼200，如下圖所示，首次請求百度首頁時，成功得到百度logo圖片文件bd_logo1.png，狀態(tài)碼200，大小8.1KB，返回的Header中包括Etag（“1ec5-502264e2ae4c0”）。

第二次請求：

1.客戶端發(fā)起HTTP GET請求一個文件，這個時候客戶端同時發(fā)送一個If-None-Match頭，這個頭的內(nèi)容就是我們第一次請求時服務器返回的Etag：1ec5-502264e2ae4c0；

2.服務器判斷發(fā)送過來的Etag和計算出來的Etag是匹配的，不返回200，返回304，讓客戶端繼續(xù)使用本地緩存。如圖所示這次對bd_logo1.png的請求，服務器只返回了Header沒有返回內(nèi)容，大小僅為349B。

來源：seo優(yōu)化網(wǎng) 轉(zhuǎn)載注明出處！