跳到主要內容

Shopify 遷移 SEO 決策紀錄

遷移排名之前，先接住每個搜尋入口。

遷移交接不能只留一份轉址表。每個舊網址都要決定保留、合併、退場或繼續調查，canonical、robots、sitemap、量測與切換證據也必須指向同一個決策。

建立我的三項優先先看平台遷移決策
從網址盤點到切換後監測的 SEO 決策鏈

網址交接台帳

來源 → 目的頁
  1. 盤點01

    找到入口

  2. 去向02

    決定去向

  3. 證據03

    留下證據

  4. 監測04

    監測例外

每個舊址
有去向
每個變更
有證據
每個例外
有負責人

網址去向

先決定網址命運，再寫轉址規則

盤點網址時，先用內容意圖、搜尋入口與新站責任判斷去向，再決定是否轉址。每條轉址都要能解釋，不能用來掩蓋錯誤。

Google 的網站移轉指南
01保留

保留一對一意圖

新頁是否承接相同商品、內容或任務？

決策方向

建立舊址到最相關新址的直接對照。

證據｜頁面對等、內鏈與最終回應狀態

02合併

合併重複需求

多個舊頁是否應共同指向一個更完整的主頁？

決策方向

指定主頁，合併必要內容並更新內部連結。

證據｜合併群組、主頁理由與內容差異

03下架

誠實退場

內容已無效，而且沒有真正相關的替代頁嗎？

決策方向

採用可解釋的退場狀態，不要把所有入口導向首頁。

證據｜退場理由、回應狀態與例外核准

04待查明

未知先隔離

資料、意圖、負責人或新站責任仍不清楚嗎？

決策方向

保留為待決項，不讓未知問題混進大批規則。

證據｜待問問題、需要資料與決策人

匿名本機規劃工具

把 27 個檢核，收斂成三個下一步

為每一列標記目前方向，再固定最多三項優先。這不是 SEO 分數，也不是上線核准；它只幫團隊看見未知、證據與下一個決策。

目前方向

尚未盤點已定位已有證據

最多固定三項，讓下一場會議有明確焦點。

01網址盤點與分類先看見所有入口，再決定哪些值得保留、合併或退場。

盤點來源已交叉比對

網站爬取、分析工具、Search Console、sitemap 與後台匯出是否互相補足？

證據｜來源清單、抓取日期與去重規則

網址都有內容或商務負責人

誰能判斷這個入口的商業價值、內容狀態與合法替代頁？

證據｜網址、類型、負責人與待決問題欄位

邊界網址已被標記

參數頁、分頁、搜尋頁、語系、已下架商品與活動頁是否被單獨分類？

證據｜邊界案例樣本與處理規則

02轉址對照一個轉址必須說得出新目的地為何相關，也必須找得到測試證據。

高價值舊網址已有相關目的地

新網址是否延續相同使用者意圖，而不是一律導向首頁或類別首頁？

證據｜舊址、新址、處置理由與簽核者

轉址鏈與循環已排除

每個舊網址是否直接到最終目的地，且不形成鏈結或循環？

證據｜完整轉址測試結果與異常清單

執行層與變更責任已確認

規則會在哪一層執行，誰能在切換後修正錯誤？

證據｜規則存放處、部署方式與回復步驟

03內容對等、合併與退場不要把舊站逐頁複製；要讓每個搜尋需求在新站有清楚去向。

核心意圖的內容對等已檢查

重要商品、類別與內容頁的主要資訊、選項與下一步是否仍然存在？

證據｜舊新頁面對照與缺口標記

內容合併有明確主頁

重複或競爭頁面合併後，哪個新頁承接意圖與內部連結？

證據｜合併群組、主頁與內鏈更新清單

退場內容沒有被誤導轉址

沒有相關替代頁的內容，是否採取可解釋的退場狀態？

證據｜退場理由、回應狀態與例外清單

04Canonical、robots、sitemap 與 schema索引控制應互相一致，不讓模板預設值替團隊做內容決策。

Canonical 與內容主頁一致

可索引頁是否指向預期主版本，且沒有仍指向舊網域？

證據｜範本層規則與代表頁面抽查

robots 與 sitemap 不互相衝突

需要被索引的網址是否可抓取、可索引，並出現在預期 sitemap？

證據｜robots.txt、meta 指令與 sitemap 交叉檢查

結構化資料已隨新內容模型重建

頁型、可見內容與結構化資料是否一致，且沒有殘留舊址？

證據｜頁型對照、驗證輸出與例外紀錄

05Analytics 與 Search Console 基準可用的基準要能對照頁型、查詢與關鍵旅程，一張總流量截圖還不夠。

搜尋基準可依頁面與查詢拆解

切換前是否保存重要頁面與查詢的點擊、曝光與 CTR 診斷視角？

證據｜篩選條件、報表日期與保存位置

關鍵分析事件已在新舊站對照

到站、商品探索、加入購物車與結帳相關事件的名稱與條件是否一致或有映射？

證據｜事件字典、觸發條件與測試紀錄

切換與行銷變動能被區分

是否記錄網站、媒體、商品供應或追蹤設定的同步變更？

證據｜變更日誌、負責人與影響假設

06預上線爬取用可重複的爬取設定，檢查預覽環境與預期規則之間的落差。

爬取範圍與環境限制已定義

爬蟲是否能存取必要頁面，又不會把預覽環境暴露給搜尋引擎？

證據｜爬取設定、環境限制與執行紀錄

所有重要頁型都有代表樣本

商品、集合、內容、搜尋、分頁、語系與錯誤狀態是否都被抽查？

證據｜頁型樣本、預期結果與差異清單

舊新爬取差異有人決策

狀態碼、標題、canonical、robots、內鏈與 schema 差異是否有負責人？

證據｜差異報告、決策與剩餘例外

07切換驗證切換清單要把 DNS、轉址、索引控制、追蹤與關鍵旅程放在同一個證據窗格。

關鍵舊址與新址路徑已實測

代表性舊網址、首頁、類別、商品、內容與錯誤頁是否回應預期？

證據｜帶時間戳的狀態碼與最終目的地紀錄

正式環境索引訊號已重驗

robots、canonical、sitemap、schema 與內部連結是否以正式網址運作？

證據｜正式站抽查與異常責任人

分析與搜尋驗證工具可用

關鍵事件、Search Console 驗證與 URL Inspection 是否能支援診斷？

證據｜測試事件、資源權限與檢查紀錄

08上線後監測監測看的是變化型態與集中位置，不用單一數字替代診斷。

抓取與轉址異常可被分流

新增 404、錯誤目的地、鏈結與伺服器錯誤是否有明確處理隊列？

證據｜異常分類、負責人、狀態與修正證據

搜尋變化能回到頁面與查詢診斷

團隊是否能區分全站、頁型、目錄、頁面與查詢層級的變化？

證據｜固定診斷視圖與註記方法

非遷移因素也納入判讀

媒體、促銷、庫存、季節性與追蹤變動是否與技術異常分開記錄？

證據｜跨團隊變更日誌與診斷假設

09回復、證據與升級先決定什麼情況停止、由誰判讀、保留哪些證據，再進入切換。

停止與回復決策權已指派

誰能暫停切換、回復規則或接受已知例外？

證據｜決策人、備援人與聯絡路徑

可回復與不可回復變更已分開

DNS、轉址、主題、追蹤與資料變更的回復邊界是否清楚？

證據｜變更類型、回復步驟與驗證方式

升級問題有共同證據包

異常發生時，是否能快速提供網址、時間、預期、實際與最近變更？

證據｜事件模板、日誌位置與分派規則

技術控制面

四組訊號，要講同一個版本

技術設定必須一起檢查。若 canonical、robots、sitemap 與頁面內容各自指向不同答案，團隊就需要回到內容責任與網址決策重新對齊。

01

標準網址

哪個網址是這份內容的預期主版本？

證據｜範本規則、代表樣本與舊址殘留檢查

查看官方依據
02

搜尋引擎存取控制

這個頁型應該被抓取與索引嗎？

證據｜robots.txt、meta 指令與環境差異

查看官方依據
03

網站地圖

提交的是否都是希望被發現的正式主網址？

證據｜sitemap 清單、正式回應與 Search Console 提交狀態

查看官方依據
04

結構化資料

結構化資料是否符合新頁型與使用者看得到的內容？

證據｜頁型對照、測試輸出與異常清單

查看官方依據

證據路徑

把切換前後，放進同一條診斷鏈

每一階段都留下可重看的輸出與例外。當變化出現時，團隊才有辦法區分設定、內容、追蹤、搜尋需求或其他營運因素。

  1. 01

    保存基準

    固定重要頁型、頁面與查詢的搜尋視角，同步記錄分析事件與近期變更。

    輸出｜基準視圖、事件字典、變更日誌

  2. 02

    預上線爬取

    以代表頁型比較狀態碼、索引控制、內鏈、內容與結構化資料。

    輸出｜差異清單、決策人、剩餘例外

  3. 03

    切換驗證

    在正式環境重驗舊址、新址、索引訊號、追蹤與核心商務旅程。

    輸出｜帶時間戳的實測、異常分派、回復判斷

  4. 04

    持續診斷

    用頁面、查詢、目錄與錯誤型態定位變化，同時保留非遷移因素。

    輸出｜監測視圖、假設、修正與重驗證據

建立量測與事件稽核

回復與升級處理

先寫好異常的處理語法

不要等單一流量數字觸發恐慌。用可觀察的技術或內容狀態決定誰介入、需要什麼證據，以及先修正、暫停還是回復。

01大批舊網址落到無關頁面、形成循環或無法到達最終頁

決策角色

技術負責人＋SEO 決策人

最小證據

代表網址、完整跳轉路徑、規則版本與部署紀錄

處理方向

停止擴大規則，修正或回復該批轉址，再重新爬取。

02正式頁面仍帶有預覽環境的 noindex、canonical 或網址

決策角色

前端／平台負責人＋發布決策人

最小證據

頁面 HTML、回應標頭、範本來源與受影響頁型

處理方向

隔離受影響頁型，修正範本並用正式頁面重驗。

03重要內容在新頁缺失，或合併頁無法承接原本使用者意圖

決策角色

內容負責人＋商品／商務負責人

最小證據

舊新頁對照、缺口、內鏈與原處置理由

處理方向

暫緩該群組交接，補齊內容或重新決定網址去向。

04搜尋或分析資料無法區分真實變化與追蹤中斷

決策角色

量測負責人＋SEO 決策人

最小證據

事件測試、資源權限、變更日誌與報表設定

處理方向

先恢復診斷能力並註記資料缺口，不用不完整數據下結論。

方法邊界／查核日期：2026-08-12

官方事實與 Tenten 決策框架，分開標示

Google 文件支撐網址移轉、索引控制與 Search Console 的產品邊界；本頁的三項優先、證據包與升級分工，是用來協作的決策設計，不是搜尋引擎規範。

搜尋引擎會自行抓取、處理與選擇訊號。本頁不承諾排名恢復、固定恢復時間、流量門檻或任何客戶成果。

  1. 01Site moves and migrationsGoogle Search Central · 查核 2026-08-12 · 網址映射、相關永久轉址、canonical／內鏈更新、sitemap 提交、避免轉址鏈與切換後檢查。官方來源
  2. 02Canonical URLsGoogle Search Central · 查核 2026-08-12 · 重複網址的主版本訊號與合併邊界。官方來源
  3. 03Build and submit a sitemapGoogle Search Central · 查核 2026-08-12 · sitemap 建立與提交的官方邊界。官方來源
  4. 04Robots meta tagGoogle Search Central · 查核 2026-08-12 · 頁面層級的索引與顯示控制。官方來源
  5. 05Debug drops in Google Search trafficGoogle Search Central · 查核 2026-08-12 · 用變化型態與搜尋需求背景診斷流量變動。官方來源
  6. 06Introduction to structured data markup in Google SearchGoogle Search Central · 查核 2026-08-12 · 結構化資料應描述所在頁面與使用者可見內容，並需要驗證。官方來源
  7. 07URL Inspection toolGoogle Search Console Help · 查核 2026-08-12 · 已索引版本與即時頁面的檢查邊界；可被索引不等於保證出現在搜尋結果。官方來源
  8. 08Performance reportsGoogle Search Console Help · 查核 2026-08-12 · 以查詢與頁面觀察點擊、曝光和 CTR，以及資料歸屬限制。官方來源

FAQ

先把常見誤解排除

完成這份檢核表，排名就會維持或恢復嗎？

不會。檢核表的作用是讓網址、內容、索引訊號與證據更可控，無法保證搜尋引擎的抓取、索引、排序或恢復時間。

所有舊網址都應該轉址到新站嗎？

不是。只有存在真正相關目的地時，轉址才有清楚意義。沒有替代內容的網址應明確退場；意圖或責任不清楚的網址則先列入調查。

只檢查 canonical、robots 和 sitemap 夠嗎？

不夠。技術訊號還需要和內容對等、內部連結、轉址目的地、結構化資料、量測基準及正式環境行為一起驗證。

規劃器會把我的網站或 Search Console 資料傳給 Tenten 嗎？

不會。規劃器不要求輸入網站、流量、查詢、帳號或姓名；檢核狀態只以匿名固定代碼保存在你的瀏覽器。

什麼時候應該找 SEO、工程與內容團隊一起判讀？

當網址去向、索引控制、內容責任或量測證據互相矛盾時，就應共同決策。越早留下負責人與證據，越不需要在切換後猜測問題來源。

讓交接內容可檢查

帶著三項優先，進入架構與量測對話

如果你的未知集中在網址、追蹤或切換責任，我們可以從現有證據開始，先釐清決策邊界，再定義需要驗證的交付。

討論遷移 SEO 決策前往量測稽核

還沒確定遷移路線？ 回到平台遷移決策中心