網站工程師的SEO: 38個來之不易的教訓和提示

网站工程师的SEO: 38个来之不易的教训和提示

基礎知識:SEO(Search Engine Optimization):漢譯為搜索引擎優化,它利用搜索引擎的規則提高網站在有關搜索引擎內的自然排名

John DeFeo

我喜歡開玩笑說SEO代表“其他人的義務”,因為當出現問題時很容易被指責。工程師們懂得這種痛。很多人指責他們,有時是“SEO人員”。但是,事實是這樣的:如果你的技術問題已經全部解決,就不會有搜索引擎優化這樣的事情。

工程師有責任理解他們在SEO中的角色,同樣,那些與工程師一起工作的人也有責任與他們合作,而不是在出現問題時責怪他們。這種關係需要公開和誠實地分享信息。

我希望這篇文章突出了一些重要但很少討論的話題,這些話題不僅值得工程界討論,也值得依賴工程團隊的人討論。

服務器穩定性和停機時間

  • 503服務不可用”HTTP響應代碼是處理計劃停機或意外停機的最佳方式。與其他5XX響應相比,它對搜索排名的影響很小。


  • 500、502和504 HTTP響應代碼會導致谷歌關閉一個網頁或完全取消索引。每次一個人或搜索爬蟲收到這些響應代碼中的一個,隨著時間的推移,預計會失去5-10次有機訪問。

  • 快速溝通,並在出現問題時向管理者發送更新。否則,你會被許多尋找答案的人所困擾(這會妨礙你的團隊尋找解決方案)。


  • 為每個有害響應代碼(例如4XX和5XX錯誤)創建自定義皮膚和跟蹤事件。當外行人能夠提供一些細節時,問題就更容易診斷。


  • 計算錯誤率時要非常小心。一個複雜的web頁面在加載完成時可能會調用服務器150次。這意味著日誌文件將低估預先發生的有害響應代碼的頻率。假設一個web頁面被加載了兩次。第一次,它響應一個“200-OK”狀態碼,並加載頁面上的其他所有內容。第二次嘗試時,它會響應一個“502-Bad Gateway”狀態碼,頁面的其餘部分無法加載。服務器總共被調用了151次,其中只有一次是502狀態,但是,該用戶的錯誤率是50%,而不是0.6%!


  • 抵抗擱置軼事證據的誘惑。許多被認為是“不能重現”而擱置的bug是更大問題的預兆。

內容交付網絡和緩存

  • 緩存不能替代基本的站點優化。可以把緩存頁面想象成約會網站上一張很棒的照片。這是人們看到的第一件事,但是當你開始一段關係,一個人開始瞭解“真正的你”。用戶和搜索引擎也是如此。

  • 類似地,支持AMP的頁面也不能替代速度慢的移動站點。

  • 注意頁面大小限制。例如,Akamai有一個嚴格的的1MB文件大小限制,當超過該限制時將導致一個500響應代碼。

  • 將內部日誌與CDN日誌合併,否則90%以上的問題可能無法檢測到。

  • 考慮在大型網站上使用“304-Not Modified”響應代碼,這些網站有很多頁面不經常更改。

  • 尋找沒有必要的動態查詢(例如填充很少更改的列表頁面的邏輯)。你可以通過緩存查詢和調度刷新來避免服務器上不必要的負擔。

重寫規則和重定向管理

  • 當你更改URL時,確保在啟動時驗證了重定向。這將帶來最大程度的舊頁面的信任和公平。讓URL斷開,然後再修復它們這無異於自殺:谷歌會隨著時間的推移而降低此故障頁面的值。

  • 檢查重寫標誌或規則是否正在導致重定向鏈。當站點以HTTP形式啟動並遷移到HTTPs時,這很容易發生。一些URL在安全版本和非安全版本之間來回切換,直到到達最終目的地。這些額外的跳轉會破壞原始URL具有的公平性(equity)。

  • 如果撤銷或反向重定向,請清除你的CDN緩存,以避免重定向循環。

機器人阻塞

  • 在被證明有罪之前,寧可做無罪的事。網站的超級用戶最有可能是那些像機器人一樣的人,因為他們的瀏覽速度很“不正常”,或者瀏覽器安裝的插件也可能會讓人掉入陷阱。這聽起來像是一個邊緣案例,但在Quora這樣的社區網站上,一個超級用戶每月可以吸引1萬到1.2萬的訪問量。

  • 俄羅斯的機器人不會自動變壞,美國的機器人也不會自動變好。許多壞蛋在亞馬遜公司的美國境內部署基於AWS服務器的機器人。

延遲和PageSpeed

PageSpeed(一款網頁速度測量工具,也可以理解為頁面加載速度)

  • 快速選擇一種測量工具(比如Rigor, Lighthouse 或 PageSpeed Insights)並堅持使用。趨勢比精確的數字更重要,在工具上吹毛求疵很容易浪費時間。

  • 手機移動頁面速度很重要,即使你運行的是一個AMP版本的網站。谷歌根據網站的本地移動體驗(包括速度、用戶體驗和其他因素)來判斷網站。

  • 要求某個人擁有添加到頁面中的每個跟蹤像素和標記的所有權,然後讓這些責任人每六個月對他們的標記整理一次。如果你不這樣做,人們會要求你在頁面中添加垃圾,直到你的團隊因為站點緩慢而受到指責。

  • 服務器響應時間對於擁有數百萬頁面的站點尤其重要。如果你的服務器響應緩慢,谷歌不會停留太久。

  • 如果你在大型網站上運行NGINX,請確保實時Gzip壓縮不會弊大於利(比如,造成瓶頸,從而降低服務器響應時間)。

  • 清除任何阻礙頁面呈現的東西。這將同時改善許多指標。(即使是純文本網站[1],在加載JS、CSS和字體時也會遇到瓶頸。)

  • 關注頁面加載的前200ms和2s期間發生的事情。由於動態元素(如廣告)的影響,有些頁面從不會加載“完全”。

關鍵渲染路徑

  • Time-to-first-byte(TTFB全稱Time To First Byte,是指網絡請求被髮起到從服務器接收到第一個字節的這段時間,它包含了 TCP連接時間,發送HTTP請求時間和獲得響應消息第一個字節的時間。)是一個重要的指標,但同樣重要的是第一個字節中包含的內容。在打開與服務器的新連接之前,瀏覽器應該能夠構建第一屏的內容。

  • 定義頁面元素的大小,以避免跳躍和搖晃頁面。當頁面來回移動時,用戶會感到沮喪,這會讓整個頁面看上去很慢,即使它加載得很快。

  • 閱讀Ilya Grigorik在這個主題上發表的文章[2]。即使是經驗豐富的開發人員也可以從中學到一些東西。

GOOGLEBOT(谷歌網頁抓取機器人)的“新”技術和可訪問性

  • 客戶端呈現可能意味著SEO的死亡。(看看Hulu發生了什麼[3]。)谷歌建議你為他們的搜索爬蟲程序提供一個服務器端呈現的頁面,即使用戶也將會看到客戶端呈現的頁面。(注:谷歌並不認為這是一種掩飾,儘管它看起來是。)

  • 在用戶看到“無限滾動”的情況下,為Googlebot提供簡單的分頁。

  • 避免使用“塊級別”鏈接,即使它簡化了代碼。所有這些額外的東西都被打包到一個

STAGING(模擬)和QA

  • 使用robots.txt文件阻止搜索引擎從模擬和QA(Question Asked)站點爬取數據。

  • 在谷歌搜索控制檯註冊staging和QA站點。這聽起來不可思議(因為你不希望搜索引擎找到這些域名),但是如果測試域名意外地被索引時,你可以在搜索控制檯中刪除整個域名的索引。

產品需求

  • 找個人(最好是SEO團隊裡的,但如果沒有的話,那就是產品經理)來定義必須構建到頁面中的所有東西,包括一些顯而易見的東西,比如

    <title>標籤和其他元數據。這很乏味,他們會討厭你問這問那,但如果你創建的頁面沒有考慮到這些關鍵標籤,他們會更討厭你。/<title>

內部鏈接

  • 鏈接是網站和整個網絡的生命線。任何重要的東西離主頁的距離都不應該超過5次點擊,所以對於那些想要去掉登錄頁面、導航鏈接等的“偉大的簡化者”來說,這會存在很多問題。

註冊商和IP管理

  • 永遠不要讓營銷人員從網站託管的IP地址發送時事通訊和促銷電子郵件。一個違反CAN-SPAM(反垃圾電子郵件)法案的流氓員工可能會導致整個網站被列入黑名單。

  • 確保有人花時間填寫註冊機構要求的年度“你的聯繫方式是最新的嗎”調查問卷。如果你不這樣做,就會使某些不法分子更容易地從技術上竊取你的域名。

JAVASCRIPT腳本

  • 一個頁面開始呈現,然後變成純白色,經常會因為開啟 write標記而中斷。

  • Google會嘗試在Javascript中遵循相對路徑,即使它們不存在。這會導致受汙染的爬取錯誤報告。

當錯誤發生時

  • 行動要快,因為谷歌是個善變的情人。建造一所房子需要幾個月的時間,而燒燬它只需幾分鐘,所以要迅速地熄滅火柴,並花時間向每個人傳授消防安全知識!

相關鏈接:

[1]——https://www.goodcheapandfast.com/

[2]——https://developers.google.com/web/fundamentals/performance/critical-rendering-path/measure-crp

[3]——https://www.elephate.com/blog/javascript-seo-backfire-hulu-com-case-study/

[4]——https://twitter.com/johndefeo

[5]——https://www.linkedin.com/in/johndefeo/

英文原文:https://www.johnwdefeo.com/articles/seo-for-engineers
譯者:憂鬱的紅秋褲


分享到:


相關文章: