6月27號google工具條pr更新了一次，然後很多人注意到twitter首頁pr降為零。（google首頁也降到9，不過這不是重點。）7月19號google居然又更新一次工具條pr。google更新工具條pr值從乙個月一次變到3個月一次，甚至半年一次，所以這次不到乙個月就再次更新有點蹊蹺。據目前透露的資訊，這次更新pr貌似主要就是為了修正twitter pr值的問題。
為什麼不是google的錯誤，google卻這麼上心，更新了pr呢？猜測原因有二，一是無論任何情況下twitter首頁pr為零，大家肯定是說google有問題，而不是twitter有問題，雖然其實確實是twitter自己造成的。二是，在google+推出的同時，google與twitter合作合同到期了，不能直接通過api抓資料了，這時候twitter pr降為零，大家恐怕心裡會嘀咕，這google真是過了河馬上就拆橋啊，google不想被這個黑鍋。
言歸正傳。
google一位發言人回覆sel關於twitter pr時說：
最近twitter不斷修改它們的robots.txt檔案和http頭資訊，玩得太起勁了，暫時造成google演算法處理twitter時的url規範化問題。現在規範化問題差不多解決了，所以我們更新了工具條pr以反映最新資料。twitter在google索引庫里一直有很高pr，沒有懲罰。
所以vanessa fox研究了一下twitter到底有什麼robots檔案、伺服器頭資訊、url規範化問題。真是不看不知道，一看嚇一跳。順便提一下，vanessa fox是前google員工，負責網管工具webmaster tools的。
預感這篇帖子會比較長，才剛開始就這麼長了…
vanessa fox搜了一下自己名字「vanessa fox」，結果如下圖：
有url，但沒標題，沒說明，也就是其實沒抓取，只是部分索引。
直接搜vanessa fox自己twitter頁面url的結果是：
為什麼出現了大寫？url最後面那個點（.）又是什麼東東？到底怎麼回事呢？
先來看看twitter的robots.txt檔案
twitter.com和www.twitter.com的robots.txt檔案居然是不一樣的。twitter.com/robots.txt是這樣的：
#google search engine robot
user-agent: googlebot
# crawl-delay: 10 — googlebot ignores crawl-delay ftl
allow: /*?*_escaped_fragment_
disallow: /*?
disallow: /*/with_friends
#yahoo! search engine robot
user-agent: slurp
crawl-delay: 1
disallow: /*?
disallow: /*/with_friends
#microsoft search engine robot
user-agent: msnbot
disallow: /*?
disallow: /*/with_friends
# every bot that might possibly read and respect this file.
user-agent: *
disallow: /*?
disallow: /*/
disallow: /oauth
disallow: /1/oauth
www.twitt程式設計客棧er.com/robots.txt是這樣的：
user-agent： *
disallow： /
也就是說：
某些情況下，帶與不帶www的兩個版本內容可能是不一樣的。
twitter貌似為了規範和**，禁止搜尋引擎爬行www版本。
所以雖然www版本做了301轉向到不帶www的版本，但twitter禁止搜尋引擎抓www版本，所以搜尋引擎蜘蛛看不到那個301啊。杯具啊。
連向twitter的鏈結有的是鏈到www版本，有的是不帶www的版本，既然www版本禁止爬行，看不到301，鏈結權重不能傳遞，浪費了。
所以在第乙個抓圖裡看到返回的是帶www的版本，可能原因是這個版本外鏈比較多，但twitter禁止爬行，所以只是部分索引（也就是只有一些來自鏈結的資料，沒有頁面本身的內容）。
再來看看302轉向
查一下twitter.com/vanessafox這個url頭資訊，居然返回302轉向到twitter.com/#！/vanessafox。為什麼說「居然」呢？請參考301轉向和302轉向的區別。由於用的是302，權重沒有轉到twitter.com/#！/vanessafox
而www.twitter.com/vanessafox做了301到twitter.com/vanessafox，當然，原因www版本被遮蔽，鏈結權重也傳遞不過來。為什麼不從www.twitter.com/vanessafox直接301到twitter.com/#！/vanessafox（這才是twitter想要的規範化版本）呢？就算要做兩次轉向，也都要用301嘛，也不能遮蔽www版本嘛。
再來看看twitter意圖的ajax抓取
twitter想要的規範化url是twitter.com/#！/vanessafox，其中的#表示twitter希望搜尋引擎抓取頁面ajax內容。（這裡技術問題比較複雜，就不解釋了，即將出版的《seo藝術》有關於ajax內容和#符號使用的解釋，廣告一下，呵呵）。
不過由於一系列複雜的轉向，可能造成了問題：
google爬行不帶www帶#！的url（twitter.com/#！/vanessafox），然後被轉向到rabkhjtwitter.com/_escaped_fragment_/vanessafox
然後google又被301轉向到帶www不帶#！的版本www.twitter.com/vanessafox
而使用者訪問時js將使用者又轉回到帶#！的版本
我讀到這裡時頭腦已經比較凌亂了，總之，twitter弄了一堆轉向，目的是讓twitter.com/vanessafox這個看著看著乾乾淨淨的版本出現在搜尋結果中，但使用者點選後又被轉到twitter.com/#！/vanessafox。弄這麼複雜幹什麼呢，越複雜越容易出錯啊。
rate limiting又是什麼呢
twitter頁面頭資訊裡有乙個rate limiting部分：
這個limiting又limit（限制）了什麼呢？vanessa fox不清楚，我就更不知道了，以前沒見過這個引數。但limit這個詞暗示著是限制了什麼和速度有關的東西，要是指抓取速度就慘了。
url中的大小寫字母
最後，如第二個抓圖顯示的，url**現大小寫字母，這些都是不同url，又會造成**規範化、pr/權重分散、複製內容等等問題。
終於到結尾了。總之，這種技術問題在很多大型**是經常出現的，看似小問題，其實可能導致嚴重後果。
文章**：seo每天一貼
本文標題: twitter技術問題導致抓取和url規範化問題
本文位址:
容器技術問題
1.為什麼會出現容器技術？容器是針對以下問題的解決方案 在切換執行環境後，如何保證軟體能夠可靠地執行？這種切換可能是從程式設計師的膝上型電腦到測試環境 從某個測試階段部署到線上，也可能是從資料中心的某台物理機到私有雲或者公有雲上的某台虛擬機器。2.容器是什麼？3.容器技術的未來發展趨勢？截至今天，業...
非技術問題彙總
1 您在前一家公司的離職原因是什麼？2 講一件你印象最深的一件事情 3 介紹乙個你影響最深的專案 4 介紹你最熱愛最擅長的專業領域 5 公司實習最大的收穫是什麼 6 與上級意見不一致時，你將怎麼辦 7 自己的優點和缺點是什麼？並舉例說明？8 你的學習方法是什麼樣的？實習過程中如何學習？實習專案中遇到...
Flask技術問題彙總
好處 flask封裝了 c端發起 request 物件，這樣就可以使用上下文臨時把某些物件變為全域性可訪問 如果不封裝，檢視函式就要傳入 request 物件，這時候檢視函式要是還要訪問其他物件，會把檢視函式弄得一團糟，壞處 增加了理解的難度。雖然用起來很爽。但是request是怎麼來的，傳遞過程，...