域遷移 SEO:Web 專業人士的清單
已發表: 2019-05-22遷移網站有很多很好的理由:
- 對於一些企業來說,這是一個安全問題。 一個很好的例子是需要遷移到 https 的 http 域。
- 對於其他人來說,這是在更改內容管理系統等內容的同時進行清理的問題。 如果您要從 Joomla 遷移到 Drupal,這也可能是遷移仍然重要的內容並為此做好計劃的好時機。
- 對於某些組織來說,這是一個收購問題。 被收購的公司有時需要融入“母”域。
- 對於一些公司來說,是時候進行品牌重塑了,而域名是要改變的事情之一。
無論您遷移的原因是什麼,您都需要了解所有域遷移都會帶來一些風險,其中一些是良性的,另一些會破壞網站流量。
精心計劃的遷移可以減輕這些風險。 它還使網站所有者可以更好地保留現有的搜索引擎推薦,或實際改善整體網站流量。
搬家前的基準測試
在規劃遷移的更多技術方面之前,您需要挖掘許多東西以使用不同的工具。 這類似於在長途駕駛之前踢你的輪胎。 最好進入準備好的遷移項目。
每個網站都不同,但您可能需要以下項目的一些變化:
- 從Google Search Console導出一年的 Google 展示次數、點擊次數和排名。 這將為您在移動後需要滿足的搜索引擎存在建立基線。
- 從網站分析工具(如 WebTrends 或 Google Analytics)導出自然流量、總訪問量、平均 404 錯誤數、跳出率和轉換的月度統計數據。 得到這個至少一年為好。 如果您的工具具有實時功能,請感受一下工作日的並發流量,這樣您還可以在啟動後將其與新域進行比較。
- 如果您有調查工具(如 ForeSee 或 Qualaroo),請導出滿意度,以及可以找到所需內容的人的百分比。
- 如果您的轉化是表單提交而不是購買,請從您的營銷自動化工具和/或客戶關係管理 (CRM)中導出。
這些統計數據將為您提供定性和定量統計數據的混合對比。 為遷移收集一系列統計數據的優點之一是,如果出現問題,您將能夠進行三角測量,並很快找出問題所在。
一些遷移可能有大量移動部件,大多數團隊在遷移過程中可能會非常忙碌。 您需要優化識別和隔離問題所需的時間,這樣就不會給已經很忙的團隊增加太多壓力。 這樣,數據緊縮是在準備階段,而不是在發布當天,所有團隊都可能會被拉伸。
收集基線統計數據以隔離問題是所有營銷人員在計劃進行網站遷移時都應該做的事情。
規劃不同類型的網站遷移
根據您要進行的遷移類型,您需要計劃不同的任務。 您需要確定以下幾點:
- 僅域更改與 URL 路徑更改
- 相同內容或不同內容
- 新的內容管理系統 (CMS) 或相同的 CMS
- 新工具或相同工具
考慮到差異,讓我們來看看您需要計劃什麼。
僅域更改與 URL 路徑更改
僅域移動不會更改頂級域之後的任何字符串。 (這些是“路徑”或“URL 路徑”。)
例如,如果您的所有字符串(如/products/product1或/about/company )都不會更改,但您的域將從 domain.com 更改為 new-domain.com,那麼您只有一個域更改。
域更改
- www.domain.com/ path1到www.new-domain.com/ path1
- www.domain.com/ path2到www.new-domain.com/ path2
- www.domain.com/ path3到www.new-domain.com/ path3
http 到 https 重定向也將被視為僅域移動。
相比之下,具有 URL 路徑更改的遷移將意味著更改域之後的字符串。
域和 URL 路徑更改
- www.domain.com/ path1到www.new-domain.com/ new-path1
- www.domain.com/ path2到www.new-domain.com/ new-path2
- www.domain.com/ path3到www.new-domain.com/newfolder/ newstringsfornewpath3
對於 URL 路徑不變的遷移,通常有一些技術方法可以自動更改重定向的域字符串,而無需為網站上的每個頁面編寫一個重定向。
對於 URL 路徑實際更改的遷移,將需要編寫一些頁面級別 301 重定向。 這肯定更麻煩。
如果對一個擁有成千上萬個頁面的站點進行信息架構更改,那麼為所有內容編寫頁面級重定向可能是不可行的。 您可能需要確定流量閾值。 例如,您可能希望根據搜索引擎和總流量排名僅重定向前 5,000 個頁面,而不是全部 175,000 個頁面。
相同內容或不同內容
如果您在新域上有效地擁有與舊域上相同的內容,那麼就內部鏈接而言,無需考慮太多事情,確保內容組仍然有意義等。
但是,如果您要添加或刪除大量內容,則需要仔細映射。
- 您是否會更改任何類別,並且您會在此過程中“孤立”頁面嗎? 這些頁面可能需要找到新家或折疊到其他頁面中。 這需要成為你計劃的一部分。
- 考慮到您的新內容,主菜單仍然有意義嗎? 如果有重要頁面的部分在移動後將更難到達,請考慮在內容更改後為它們提供額外的路徑。
新的 CMS 或相同的 CMS
如果您要從www.example.com遷移到www.new-example.com並且您沒有更改 CMS,那麼內容的實際遷移應該非常簡單。
如果您要從一個 CMS 切換到另一個 CMS,那麼同樣的移動可能不是一項簡單的任務。 你需要……
- 確保舊站點上的佈局和模板將得到新系統的合理支持。
- 確定是否有辦法將您的 CMS 內容導出到新的內容管理系統將接受的內容中(即使這不是 100%,內容遷移的部分自動化也會有所幫助)。
- 為因 CMS 更改而手動進行的內容遷移部分留出時間。
新工具或相同工具
您的實際工具和部署工具的方式可能在舊域和新域之間有所不同。
你需要考慮幾件事:
- 在新系統上,是否有一個母版頁或類似於插件腳本的工具,無論是獨立的還是作為標籤管理工具的一部分? 或者您是否需要在整個站點中多次插入腳本? 如果是後者,請確保您有足夠的時間。
- 如果您要從逐個工具的實施切換到像 Google 跟踪代碼管理器這樣的代碼管理工具,請確保您有足夠的時間來測試這種情況。 標籤管理工具很有用,但它們可能需要時間來適應,這應該考慮到您的域切換時間表中。
- 如果您要添加工具,請確保您有時間進行回歸測試。 您的新工具可能無法立即與舊工具很好地配合使用,您需要時間進行調試。
完成網站遷移計劃
一旦您掌握了不同類型的站點遷移,就該設置站點遷移計劃了。
讓我們為一個相當複雜的場景構建一個示例,這樣您就可以去掉不需要的部分。
假設您要從舊 CMS 遷移到新 CMS。 而且您在新站點上的信息架構會略有不同——一些 URL 路徑將被移動到新位置。
從重定向的角度來看,您需要儘早做以下幾件事:
1. 確保您有辦法處理頁面級 301 重定向
有多種方法可以設置“手動”頁面級重定向。 其中一些涉及編輯配置文件,其他涉及將 XML 放入模塊中,還有一些仍然具有處理此問題的基本 CMS 功能(假設您仍然可以訪問舊 CMS)。 儘早確定你要走哪條路,這樣你就可以避免頭疼了。
2.檢查您是否可以處理通配符或條件重定向
如果您能夠調整 .htaccess 文件或類似的配置文件,則可以通過條件管理一些重定向,而不是單獨設置每個重定向。 這將為您節省一些時間。
3. 導出舊網站首頁
在總流量和自然流量之間進行選擇,作為排名的決定因素。 (自然流量對此非常有用,因此您知道您將在遷移之前重定向實際驅動搜索引擎推薦的頁面。)
- 考慮到網站的大小,選擇一個有意義的閾值。 對於擁有 500 個左右 URL 的網站來說,前 100 個頁面可能是最佳選擇,因為其中大部分流量都來自前 80 個頁面。 但是,對於具有數万個 URL 的站點,您可能需要前 5,000 個頁面。
4. 將首頁映射到新位置
這是一個手動步驟,您可以執行此操作以節省時間。 在電子表格上排列首頁列表並將它們標記為舊 URL,然後在它們旁邊添加新 URL。 當您知道要構建什麼(如 XML 文件)時,您將擁有可以開始使用的文件。
301 重定向的好處
當您移至新域時,將 301(或“永久”)頁面級重定向添加到您最有價值的頁面可以完成兩件事:
- 它將用戶發送到正確的頁面,以獲得用戶體驗 (UX) 的好處
- 它告訴搜索引擎蜘蛛這一舉動,以獲得SEO 的好處
當您的網站只有一部分發生了信息架構更改時,您通常可以對仍然具有相同 URL 路徑的網站部分進行條件或通配符重定向,並且只對較小的部分使用逐一頁面級重定向絕對必要的用例數量。
例如,可能/product/下的所有內容在新站點上都更改為/products/ 。 您可以使用通配符替換來處理移動的那部分。 但是我們也假設/about/下的所有內容都有一個新的“路徑”,所以/about/之後的實際字符串會改變。 對於/about/下的所有內容,您需要將舊 URL 映射到新 URL,並添加 301 頁面級重定向。
這樣,您就可以從舊域中獲得鏈接權益轉移的好處,而不會壓倒管理重定向的團隊。
避免常見的陷阱
域遷移失敗的方式有很多種。
以下是您需要注意的一些常見問題:
1. 您可以使用的重定向工具對於切換來說不夠健壯。
- 一些重定向工具只管理 http 的 URL,而不能處理 https 的。 因此,您需要找到其他方法來處理您的 https URL。
- 一些重定向工具是 CMS 的本機部分,需要大量時間來設置。 當您擁有數百或數千個 URL 時,這最終會出現問題。
- 一些重定向工具無法處理通配符,因此您需要計劃手動重定向。 而且您需要考慮所需的額外時間。
成功的網站遷移依賴於營銷人員充分了解他們可以使用的重定向工具,並且只為可能的事情進行規劃。
使用上面列出的說明,儘早開始向您的開發人員說明可用的內容。
請注意在發布日之前您會遇到的限制。 如果有很多手動步驟,請預留足夠的時間來處理這些步驟。
這確保了當切換之日到來時,該區域不會出現意外。
2.團隊無法正確評估成功或失敗。
如果團隊沒有建立要滿足的基準——網站排名的搜索詞、總有機流量、總訪問量、網站上的滿意度和成功率等——很難判斷遷移是否順利。
也許整體流量大致相同,但成功率開始下降。 也許滿意度分數是相同的,但網站排名的搜索詞更少,自然流量下降。
如果您沒有查看一系列數據,則在網站實際受到打擊時,域切換可能看起來很順利。 表現不佳並認識到它比表現不佳並認為自己做得很好更可取。
確保您對網站的多個方面都有基準,以避免此問題。
3. 團隊錯過了重要的頁面遷移。
對於信息架構發生變化的域,很容易丟失在搜索引擎上排名或從多個來源獲得大量流量的頁面。
如果沒有人導出首頁以確保所有這些都被遷移,那麼團隊通常會在遷移後看到流量下降。
如果發生這種情況,團隊需要一起整理一份報告,並檢查舊內容是否仍在某個文件中,以便將其轉移到新域中,或者忍受流量損失。 這種類型的計劃失敗確實會損害整體流量。
您需要確保您已經查看了您的分析工具並導出了首頁,並且在您拉動重定向觸發器之前內容計劃處於良好狀態。
4. 任務量變得太多,團隊無法處理
有許多事情可以改變域遷移所需的任務量。
該站點可能具有絕對鏈接而不是相對鏈接,並且您需要進行比您最初預期的更多的內部鏈接調整。
重定向工具可能無法支持通配符,您需要管理比計劃更多的手動重定向。
您可能需要將非頁面內容項目轉移到新的 CMS,例如現場搜索的特色結果,並且您需要在發布後花時間處理它。
通常最好在切換發生時為站點分配一些額外的資源,這樣當事情沒有完全按計劃進行時,您就有迴旋餘地。
管理切換當天的任務
假設所有重定向都按預期工作。
您想要移動的所有內容都已被移動。 您不會收到 404 錯誤峰值,您的所有工具都像以前一樣觸發,所有非頁面內容配置都正確移動。
這是一個很好的開始,但它仍然在發布日為 SEO 任務留下了一些任務:
1. 在 robots.txt 上設置您的禁止條件
robots.txt 文件告訴搜索引擎蜘蛛他們應該和不應該在網站上抓取什麼。
請與您的開發人員和 SEO 確認您已配置 robots.txt 文件,然後將其移過來。 如果你沒有,至少要確保你的 robots.txt 文件不會是這樣的:
- 用戶代理: *
- 不允許: /
這種組合將告訴谷歌和其他搜索引擎不要索引您網站上的任何內容。 這是您應該盡量避免的情況。
2. 創建和驗證新的 Google Search Console 帳戶
建立新域後,您需要將其註冊到 Google Search Console,並證明您擁有該域。 您可以使用多種方法來執行此操作,從刪除 Google 將在根目錄識別的文件到使用 Google 跟踪代碼管理器。
- 為文件夾設置 Google Search Console 帳戶。 驗證域後,您可以將站點的部分添加為附加屬性。 這將允許您執行一些操作,例如查看指向“產品”部分或“關於我們”部分的搜索(如果有的話)。 這將為您提供一個額外的層來檢查您的自然流量是否在域遷移中倖存下來。
3.提交站點地圖
根據您的內容管理系統,您可以從 CMS、爬網工具或通過記事本手動生成帶有 URL 列表的站點地圖。
您可以在這裡做的一件事是為您網站的每個部分生成一個單獨的站點地圖(一個站點地圖用於您的“產品”部分,一個站點地圖用於“關於我們”等)如果 Google 索引您 90% 的產品頁面但只有 5% 的關於頁面,您會知道只修復索引不佳的部分。 只有在網站的每個部分都有單獨的站點地圖時,您才會看到該問題。
為不同的網站部分生成站點地圖後,您應該通過 Search Console 將它們提交給 Google。
4. 告訴谷歌域名切換
即使是一些經驗豐富的營銷人員也錯過了這一步驟。 Google Search Console 有一個工具可讓您聲明“地址更改”。 要使用它,您需要驗證舊域和新域的 Google Search Console 屬性,然後按照 Google Search Console 列出的步驟操作。
啟動後監控統計信息
如果到目前為止您已經遵循了這篇文章中的建議,那麼您將有定量和定性的基准進行比較。
- 調查工具數據。 滿意度和人們找到所需內容的能力顯著下降可能意味著網站的新結構可能會讓訪問者感到困惑。 您需要重新考慮新架構。
- 谷歌搜索控制台和分析工具數據。 404 錯誤的激增加上一些排名損失和自然流量下降通常意味著至少有一些重定向失敗。 您需要調查重定向方法。
- 分析工具數據。 總流量和推薦流量顯著下降而搜索引擎流量沒有大幅下降可能意味著您沒有移動其他網站鏈接到的內容。 您需要重新訪問該內容。
交通的實時監控在這裡也有幫助。 如果您網站上的同時訪問者數量大大低於發布前的數據(例如,不到原來的一半),那麼您就會知道有些事情不對勁,您需要深入挖掘。
在域遷移中沒有過度準備
移動域可能是一個痛苦的過程。
對於您的網站,該過程有很多方法可能會很糟糕。 並且很少有通往成功的途徑。
綜上所述,如果您需要更改域,最好做好充分準備。 如果你 …
- 儘早了解您的重定向工具可以為您做什麼,
- 痴迷於內容計劃,直到你看不到任何漏洞,並且
- 使用數據管理過渡
…您有更好的機會無縫遷移到新域。
對於某些類型的搬家,如果你執著於計劃,你甚至可能在切換後增加流量和轉化。