網站遷移:SEO 策略和最佳實踐
已發表: 2021-07-14您可能出於特定原因需要遷移您的網站/業務。 作為 SEO,我們稱之為“遷移”或“站點遷移”。 準備不當的遷移可能會導致自然流量顯著減少。 在本指南中,我將分享如何以最無縫的方式完成站點遷移過程。
為什麼需要遷移您的網站? 這可能有一個或多個原因。
首先,我們來看看遷移類型
- 域名變更:
您可能希望將您的 x.com 網站移至 y.com - 網址結構更改:
包含與您網站的內容和結構相關的字詞的 URL 對瀏覽您網站的訪問者更友好。 如果網站的網址對 SEO 不友好,您可能需要更改它們。 - HTTP > HTTPS 遷移:
安全是谷歌的重中之重。 如果您將網站從 HTTP 遷移到 HTTPS,Google 會將此視為帶有 URL 更改的網站移動。 這可能會暫時影響您的一些流量數字。 - 平台變化:
網站平台是我們網站的基礎。 您可以在 WordPress、Shopify、Wix 或任何其他平台上創建您的網站。 此外,您可以擁有由開發團隊創建的自定義站點。 您可能想切換到更好的平台。 在更改您的網站構建平台時,我們應該測試您的新平台的 SEO 功能。 - 結構和層次結構變化:
您的網站可能會開始在完全不同的區域提供服務。 或者您網站的 URL 和類別結構可能對 SEO 不友好。 不管出於什麼原因,我們都可以開始在一個全新的網站上工作。 - 服務器變更:
服務器遷移主要在頁面加載速度方面存在風險。 網站速度是一個 SEO 排名因素,但更重要的是,它是一個用戶體驗和轉化率問題。 您可能會考慮在新服務器上設置一個臨時站點並在其上測試頁面速度。 此外,不要忘記檢查重定向以確保它們按預期運行。 - 單獨的移動站點遷移:
Google 推薦響應式網頁設計作為設計模式,因為它最容易實現和維護。 因此,您可以計劃將您的 m-dot 版本重定向到主響應版本。 在那裡進行重定向絕對是正確的。 這應該是相當簡單的並且應該相當容易做到。
如果整個結構保持不變,只是域發生變化(第一種遷移類型),可以說我們的工作很容易。 在其他遷移類型中或當組合了多個遷移類型時,事情可能會更複雜。
有幾十個例子在遷移過程中經歷了巨大的流量損失。
移動站點時導致流量丟失的一些錯誤:
- 缺乏規劃
- SEO和UX知識低
- 低預算
- 重定向問題
- 網址映射錯誤
- 抓取錯誤
- 不要干擾即時錯誤
為了不遇到這些問題,你會在文章的後續中找到正確的規劃策略和需要考慮的要點。
在開始之前,我想警告您一些事情:
- ! Google 不建議同時更改設計和 URL 結構。 如果可能的話,在不同的時間一步一步地進行這兩種或更多類型的遷移是很有用的。
- ! 如果站點被移動到不同的域,則應調查新域地址的歷史記錄。 Archive.org、“yoursite.com”搜索查詢和審核工具都可以使用。 如果之前有域名註冊或者建站,需要重新考慮。 在 Google 中安裝帶有品牌實體的域,如果該域暴露於垃圾鏈接或黑客攻擊等問題,或者服務於完全不同的主題,則會導致很大一部分流量丟失。
- ! 在某些情況下,即使遷移計劃和實施沒有任何問題,自然流量也有可能減少 15% 或更多。 由於網站有重要的結構變化,谷歌對每一頁一一重新學習和評估。 這段時間通常是幾週,但對於大型網站來說可能更長。 如果一切順利,您的自然流量將在此評估後的很短的時間內獲得積極的動力。
- ! 該站點不應在遷移期間或遷移之前對用戶關閉。 如果要進行設計或結構更改,您可以通過簡單的方法提前向您的聽眾宣布此信息。 (輪播、電子郵件、短信、推送通知等)具有不同狀態代碼或警告消息的頁面可能會被 Googlebot 否定解釋。
- ! 遷移(啟動新結構)的時刻應該在網站接收最少流量的時區。 這樣,在遇到不良問題的情況下,將受到影響的觀眾數量將保持在最低水平。 此外,在服務器負載較低的這段時間內,Googlebot 會更快地抓取新網站並將其編入索引。
[案例研究] 避免重新設計對您的 SEO 造成不利影響
規劃和數據收集
不跳過任何移動步驟的項目計劃可確保工作順利進行。 當工作計劃確定後,任務的分配就會變得清晰。 該計劃需要在遷移前至少 30 天制定。
保留當前訪問者數據很重要。 根據您的 Web 項目的大小,有必要對流量最高的頁面和查詢進行分組。
提示:保留遷移日期前 45 天的日誌文件可讓您分析 Googlebot 的行為並在出現差異時立即採取行動。
創建測試站點並禁止
遷移過程從 SEO 的線框圖開始。 如果在創建線框期間檢查了線框並進行了 SEO 評論,則在測試站點中進行的更改會減少。 這使項目能夠更快地進行。 這也使 UX/UI 設計師的工作更輕鬆。
關閉機器人對測試站點的訪問也很重要。 否則,您可能會在很短的時間內體驗到您的新頁面已包含在 Google 索引中。
如何通過 robots.txt 文件禁止搜索引擎機器人?
創建 robots.txt 文件:您可以創建一個名為 test.example.com/robots.txt 的文件並執行以下命令:
——
用戶代理: *
不允許: /
# 此命令阻止所有機器人訪問我的網站。
——
用戶代理:OnCrawl
允許: /
# 此命令只允許“OnCrawl bot 訪問我的網站。
——
可以決定使用哪些機器人進行測試,並通過 robots.txt 文件定義對用戶代理的跟踪。 Oncrawl 具有使事情變得更容易的功能。
IP限制:如果您參與了某公司網站的遷移計劃,為了防止新項目被暴露,您只能開放對該公司IP的訪問,禁用對所有其他IP的訪問。 在這種情況下,您需要向與您合作的機構或顧問(如果有)授予私有 IP 訪問權限。 即使你做了 IP 限制,你也必須通過 robots.txt 文件禁止機器人。
密碼保護:可以創建一個ID和密碼組合進入考場。 Oncrawl 等爬行應用程序具有密碼訪問功能。
Noindex 標籤:可以在所有頁面的 head 部分添加一個 noindex 元標籤,以防止測試站點頁面被 Google 索引。
提示:最常見的錯誤之一是在遷移到新網站後忘記刪除 noindex 標籤。 請記住確認標籤已更新為索引,請在遷移時遵循。
使用 Google Analytics 進行性能跟踪
性能跟踪最重要的一點是從同一個 Google Analytics(分析)帳戶繼續,而不會丟失數據。 因此,現有的 GA 和 GTM 代碼必須在遷移的新站點上處於活動狀態。
生成新的 GA 代碼會使您更難衡量 Web 性能。
在搬家當天向您的 Google Analytics(分析)儀表板添加提醒將使您更容易在以後比較性能。
創建現有 URL 列表
我在文章開頭提到,如果我們只是改變我們的域名,我們的工作很容易。 我們可以使用以下或類似代碼從 .htaccess 文件中批量應用它。
* .htaccess 文件是位於 Apache 服務器上的配置文件。
RewriteEngine On RewriteCond %{HTTP_HOST} ^oldsitee\.com$ [OR]
RewriteCond %{HTTP_HOST} ^www\.newsite\.com$
重寫規則 (.*)$ https://newsite.com/$1 [R=301,L]
此規則集將確保在 oldsite.com 或 www.oldsite.com 到達任何 url 時,域地址自動 301 重定向到 https://newsite.com。
但是,如果您的工作是修復不正確的 URL 結構,那麼事情就會變得複雜。 我在文章後面解釋了這種情況。
現在,我們正處於遷移過程中最重要的時刻之一。 獲取當前站點的重要 URL 的完整列表是關鍵。 如果您忘記了具有大量訪問者和高 PageRank 的 URL,並將其排除在遷移之外,請做好自然流量下降的準備。
提示:通過從多個來源導出 URL,您可以確保沒有遺漏任何 URL。
從 XML Sitemap 開始總是正確的一步。 要將 XML 文件中的 URL 簡單地傳輸到電子表格中,您可以在此處複製鏈接並在第一行編寫您自己的站點地圖 URL,而不是 https://www.sinanyesiltas.com/post-sitemap.xml。
- 在 Search Console 中展示的所有網址,
- 通過 Google Analytics 獲得頁面瀏覽量的所有 URL,
- 由於使用 Oncrawl 抓取而獲得的所有 URL,
- 使用多個第 3 方抓取工具繼續前進可確保工作清晰。 通過利用每個爬取應用程序的不同功能,確保沒有遺漏任何 URL,這一點很重要。
- 重要的是在此處包含已經獲得鏈接的頁面。 為此,有必要通過 Search Console、Ahrefs、Semrush 和 Majestic 工具發現鏈接頁面並將它們添加到同一個文檔中。
獲取所有 URL 後,您將在單個 Excel 文檔中擁有類似於下面的分組數據。
我們得到了許多帶有可用 URL 的不同 Excel 表。 是時候將它們全部合併到一個文件中並使其獨一無二了。 我們繼續處理沒有匹配 URL 的文檔,列出了您當前的 URL,並且沒有遺漏任何重要的 URL。 圖像中的 ALL 選項卡代表我正在談論的區域。
URL 映射(舊 - 新 URL 映射)
在 URL 結構發生變化的項目中,需要將現有的 URL 與新的 URL 進行匹配。 以最佳方式執行此操作的 SEO 可以確保遷移過程順利進行且沒有損失。
有必要將新 URL 與我們在上一步中創建的文檔中的每個現有 URL 進行匹配。 您可以直接與 IT 團隊共享您將完成的文檔,並通過 .htaccess 文件請求識別重定向。 或者你可以自己做。
在此步驟中需要考慮一些關鍵事項:
- 在要應用的重定向中應使用 301 服務器端重定向。 這種重定向類型永久將X頁面重定向到Y頁面,並確保X頁面的所有值都轉移到Y頁面。使用302、307、JS、Meta或其他重定向類型是遷移過程中非常關鍵的錯誤。
- 不要在 URL 映射文件中包含沒有訪問者、內容不佳以及您認為會損害您的抓取預算的 URL。 請記住,Google 已在其數據中心為您的網站保留了一個空間,您應該將此空間用於最高效的頁面。 如果您確定了一個不必要的頁面組,請讓這些頁面以 410 狀態代碼進行響應。
為什麼是410? 410 狀態碼與 404 不同,表示該頁面現在已被刪除並且不會再次處於活動狀態。 如果您使用 404 狀態代碼,Googlebot 會訪問您的服務器以檢查同一頁面是否再次處於活動狀態。 通過消除這些訪問,410 是有效利用抓取預算的重要解決方案。 - 不要將多個頁面批量重定向到單個頁面。 這會給用戶和機器人造成混淆。 不要為您不使用且發現效率低下的頁面應用批量 301,而是查看解決方案 410。
- 如果您正在遷移具有數千個頁面的電子商務網站,則無法為每個 URL 準備一對一的映射。 在這種情況下,您可以通過準備模式來指導您的 IT 團隊。
圖像重定向
圖像也包含在站點遷移和重定向映射中。 我們看到的最常見的錯誤之一是圖像方向不包括在遷移中。 為了不丟失在 Google 圖片中獲得的排名和值,為圖片準備單獨的 URL 映射非常重要。 遷移工作應該基於 URL,而不是基於頁面。
怎麼做?
- 使用 Oncrawl 抓取您的圖像文件。
- 您可以使用 Ahrefs、Semrush 和 Majestic 分析獲得反向鏈接的圖像源。
- 您可以通過 Search Console > 搜索類型 > 圖片來解析帶有圖片的頁面。
- 以我們為頁面所做的相同 Excel 格式收集您獲得的所有 URL,消除重複項並完成您的映射設置。
(如果域正在更改)Google 地址更改工具
在完成所有初步工作並激活重定向後,有一個工具可以讓我們將網站指定到 Google 並使事情變得更容易:地址更改工具。 在此工具中選擇舊站點和新站點後,將在更短的時間內處理信號。
- 舊網站和新網站都需要 Search Console 資源所有權。
- 地址更改僅用於域更改。 不適用於子文件夾 URL 更改或 HTTP > HTTPS 遷移。
- 在此更改工具中,如果有的話,必須單獨處理每個子域。
- 當滿足這些條件時,可以通過使用 Google 更改地址工具選擇舊站點和新站點來啟動該過程。
鏈接更新
該網站現在將具有新的 URL 結構。 在這種情況下,網站上的所有鏈接都應該在新版本中工作。 如果在站點內的鏈接中繼續使用舊的 URL,許多無意義的重定向將起作用。 因此,必須檢查以下鏈接:
- 頁面內的所有內部鏈接
- 規範標籤
- -如果有的話- Hreflang 標籤
- -如果有的話-備用標籤
- - 如果有的話 - HTML 站點地圖鏈接
- 社交媒體資料鏈接
- 廣告活動中使用的著陸頁鏈接
提示:如果您更改了整個 URL 結構,我建議您將 XML 站點地圖文件與舊 URL 保持一段時間。 使用您的新 URL 結構創建一個單獨的 XML 站點地圖。 繼續向 Googlebot 發送舊網址一段時間。 通過這種方式,Googlebot 將加快查看舊網址上的重定向並將其編入索引的過程。 根據站點大小,我建議您的 XML 站點地圖文件至少保持 1 個月前處於活動狀態。
控件
應用重定向後,需要通過爬取之前獲取的舊網址,確認每個網址的狀態碼為301。 在這裡,當檢測到狀態碼不是 301 的 URL 時,迅速採取行動非常重要。
其他需要注意的檢查點:
- 機器人.txt 文件
- 谷歌分析跟踪代碼
- Search Console 驗證控制(如果域已更改,應繼續使用 2 個不同的域,舊的和新的)
- 元標籤(noindex,follow)
- 規範標籤
還要注意這些:
- 如果可能,應聯繫反向鏈接提供商,並用新鏈接替換舊鏈接。 如果反向鏈接網絡很大,可以按重要性進行規劃,只聯繫重要的。/li>
- 應審查廣告活動中使用的目標網頁或通知相關團隊。
- 通過爬取新站點,應檢查所有鏈接是否正常工作,如果站點內出現重定向循環,應立即進行干預。
- 應更新社交媒體資料中的鏈接。
- 應遵循新頁面的索引。
- 應監控關鍵字效果。
- 301 重定向不應很快停用,它們應始終保持活動狀態。
- 如果域已更改; 舊域名必須至少再保留 2 年。
- 舊數據(網址、日誌、關鍵字效果等)應保留一段時間。
- 如果舊站點上安裝了拒絕文件,則還應將其上傳到新域。
Google 會在 180 天內處理新舊站點之間的路由設置。 在 180 天期限之後,它不會識別新舊站點之間的任何關聯,並且如果舊站點仍然存在且可抓取,則將其視為不相關站點。