我喜歡把SEO說成是“別人的義務”（Somebody Else’s Obligation）的意思，因爲如果出了問題，可以把責任推給別人。工程師都知道這種痛苦，因爲如果出了問題，會有很多人（有時候是“SEO”團隊的人）指責他們。但現實卻是：除非你的技術已經解決了所有問題，否則根本不存在所謂的搜索引擎優化。
工程師有責任去了解他們在SEO中所起的作用，同樣，與工程師一起工作的人也有責任與他們合作——在出問題時不要責怪他們。要促成這種關係，需要公開和坦誠地分享一些信息。
我希望這篇文章能強調一些重要但很少被討論的話題，這些話題不僅值得工程界討論，也值得依賴工程團隊的人討論。
服務器穩定性和停機時間
- 在進行計劃或意外的停機時，可以使用HTTP響應碼“503 Service Unavailable”。與其他5XX響應碼相比，它對搜索排名的影響最小。
- HTTP響應碼500、502和504會導致Google禁止某個網頁或完全取消網頁索引。當有人或搜索爬蟲收到其中一個響應碼時，預計會丟失5到10次的有機訪問次數。
- 在出現問題時，進行快速的溝通，並通知利益相關者。否則，你會被很多提出疑問的人所困擾（這樣會妨礙你的團隊尋找解決方案）。
- 爲每個錯誤響應碼（例如4XX和5XX錯誤）創建自定義皮膚和跟蹤事件。如果外行人可以提供一些細節，問題就會變得更容易診斷。
- 在計算錯誤率時要十分小心。複雜的網頁在完成加載時可能會調用服務器150次。這意味着日誌文件將會低估預先發生的錯誤響應碼的頻率。例如，想象一下網頁被加載了兩次，第一次返回“200-OK”響應碼，並加載所有的內容。第二次返回“502-Bad Gateway”響應碼，並且無法加載頁面的其餘部分。服務器總共被調用了151次，其中只有一個是502，但是，用戶的錯誤率是50％，而不是0.6％！
- 不要忽視“詭異”的現象，一些被認爲“無法重現”的錯誤可能是更大問題的徵兆。
內容交付網絡和緩存
- 緩存不能替代基本的網站優化。緩存的頁面就像放在約會網站上的照片，剛開始人們只能看到照片，但在開始建立關係時，“那個人”就會知道“真實的你”。用戶和搜索引擎的關係也是如此。
- 類似的，啓用了AMP的頁面也無法替代速度慢的移動網站。
- 請注意頁面大小的限制。例如，Akamai的文件大小限制爲1MB，超出時會生成500響應碼。
- 將內部日誌與CDN日誌合併，否則，超過90％的問題可能無法檢測到。
- 考慮在大型網站（包含大量不經常修改的頁面）上使用“304-Not Modified”響應碼。
- 找出不必要的動態查詢（例如，填充很少更改的列表頁面的邏輯）。你可以通過緩存查詢和刷新緩存來避免給服務器造成不必要的壓力。
重寫規則和重定向管理
- 在改變URL時，要確保在啓動時對重定向進行驗證。這將在最大程度上結轉舊頁面的信任和權益。先讓URL遭到破壞，然後再去修復它們，這無異於自殺：谷歌會隨着時間的推移逐步讓舊頁面的價值衰減。
- 仔細檢查看看重寫標誌或規則是否會導致重定向鏈。當一個網站從HTTP遷移到HTTPS時很容易發生這種情況。有些URL在安全和非安全版本之間跳來跳去，直到到達最終目的地。這些額外的跳轉會破壞原始URL的權益。
- 如果撤消或撤消重定向，請清除CDN的緩存，以避免重定向循環。
反機器人
- 在被證明有罪之前，寧可做無罪的事。 由於“不自然”的瀏覽速度或安裝了瀏覽器插件，網站的超級用戶最有可能像機器人一樣。這聽起來像是一個邊緣案例，但在社區網站（例如Quora）上，一個超級用戶每月可以吸引1萬到1.2萬的訪問量。
- 俄羅斯的機器人不一定就是不好的，美國的機器人也不一定就是好的。有很多不良分子在亞馬遜的美國AWS服務器上部署機器人。
延遲和頁面加載速度
- 快速選擇一個度量工具（如Rigor、Lighthouse或PageSpeed Insights）並堅持下去。趨勢比確切的數字更加重要。
- 移動版頁面的加載速度非常重要，即使你正在運行AMP版本的網站。谷歌通過原生移動體驗（包括加載速度、用戶體驗和其他因素）來評判一個網站。
- 將添加到頁面中的每個跟蹤像素和標籤的所有權交給某人，然後讓利益相關者每六個月驗證這些標籤。如果不這樣做，人們會要求你在頁面中添加越來越多的垃圾，直到你的團隊因爲網站變慢而遭到指責。
- 對於擁有數百萬個頁面的網站來說，服務器響應時間變得尤爲重要。如果你的服務器響應速度慢，谷歌是不會耐心等待的。
- 如果在一個大型網站中使用NGINX，請確保即時Gzip壓縮不會帶來弊大於利的效果（減慢服務器響應速度）。
- 清除任何影響頁面渲染的東西，這樣可以一下子改善一系列的指標（即使是純文本網站，在加載JS、CSS和字體時也會遇到瓶頸）。
- 關注頁面加載的前200ms和2s期間發生的事情。因此有動態元素（如廣告），有些頁面不會立即“完整”加載。
關鍵的渲染路徑
- 加載第一批字節的時間是一個重要的指標，但第一批字節中包含的是哪些內容也同樣重要。在打開與服務器的新連接之前，瀏覽器應該能夠構建首屏內容。
- 定義頁面元素的大小，避免頁面出亂子。如果頁面四處移動，用戶會感到沮喪，即使加載速度很快，用戶也會感覺整個頁面很慢。
- 讀一下Ilya Grigorik寫的文章（https://developers.google.com/web/fundamentals/performance/critical-rendering-path/measure-crp），即使是資深開發人員也可以從中學到一些東西。
“新”技術和谷歌機器人的可訪問性
- 客戶端渲染可能意味着SEO已死。谷歌建議用戶爲其搜索爬蟲提供服務器端渲染的頁面，即使呈現給用戶的是客戶端渲染的頁面。
- 爲谷歌機器人提供簡單的分頁，以免讓用戶看到“無限滾動”的情況。
- 避免使用“塊級”鏈接，儘管這樣可以簡化代碼。包含在< a > 標籤中的所有額外內容都會導致谷歌機器人難以將上下文的值傳遞到目標頁面。
staging和QA
- 使用robots.txt文件禁止搜索引擎抓取staging和QA網站。
- 在Google Search Console中註冊staging和QA網站。這樣做似乎有點違反直覺（因爲你不希望搜索引擎找到這些資源），但如果測試網站被意外索引了，你可以在Search Console中取消索引。
產品需求
- 找一個人（最好是在SEO團隊，如果沒有，產品經理也可以）來定義必須構建到頁面中的所有內容，例如< title >標籤和其他元數據。這件事情很枯燥無味，他們會因此討厭你，但如果你構建了一個不能包含這些關鍵標籤的頁面，他們會更加討厭你。
內部鏈接
- 鏈接是網站和整個網絡的命脈。任何重要的東西都應該在離主頁五次點擊之內，因此要向那些想要消除登陸頁面、導航鏈接的“極簡主義者”提出很多問題。
登記和IP管理
- 永遠不要讓營銷人員從託管網站的IP發送簡訊和促銷電子郵件。違反CAN-SPAM法案的流氓員工可能導致整個網站被列入黑名單。
- 確保有人花時間填寫登記處要求的年度聯繫信息更新問卷調查。如果不這樣做，會讓一些不良分子更容易從技術上竊取你的域名。
JAVASCRIPT
- 開始渲染一個頁面，然後又變成純白色，通常是因爲只給了write()的起始標籤，而沒有給出結束標籤。
- 谷歌會嘗試遍歷JavaScript內的相對路徑，即使它們不存在。這樣會污染爬蟲錯誤報告。
當發生錯誤時
- 行動要快，因爲谷歌是個善變的情人。建造一所房子需要幾個月時間，而燒燬它只需要幾分鐘。所以，要迅速地熄滅火柴，並花時間向每個人傳授消防安全知識！