目錄

• 一、網址規則制定
• 二、程式架構修改
• 三、網址轉換與 301 轉址設定
• 四、對既有 SEO 的影響與保護策略
• 五、實施時間表建議
• 六、總結

一、網址規則制定

改用 URL Rewrite 的第一步，是制定一套合理且可持續維護的網址規則。

規則制定原則：

• 簡潔有意義：網址應讓使用者和搜尋引擎都能理解內容，如 /articles/seo-guide 而非 /articles/123
• 層級不超過 3~4 層：過深的網址層級不利於搜尋引擎爬取，如 /blog/2026/seo/url-rewrite-guide 已是上限
• 使用連字號（-）分隔單字：搜尋引擎將連字號視為單字分隔，底線（_）則不被識別
• 全部小寫：避免大小寫混用導致重複內容問題（/Article/SEO 和 /article/seo 可能被視為不同頁面）
• 不包含查詢參數：將 ?id=123 改為 /articles/seo-guide，用 slug 而非 ID
• 結尾不加 .html/.php：隱藏副檔名讓網址更乾淨，未來更換技術棧也不需改網址

規則範例：

注意事項：

• 新規則一旦上線就不宜頻繁變動，制定時要考慮未來擴充性
• 如果網站有多語言版本，需規劃語言前綴（如 /zh-tw/articles/...、/en/articles/...）
• 與團隊討論確認規則後再進行後續修改，避免上線後又推翻重來

二、程式架構修改

URL Rewrite 不只是伺服器設定，程式端也需要配合調整。

後端程式修改

• 路由系統調整：如果使用框架（如 Laravel、Django、ASP.NET MVC），框架本身已內建路由系統，只需註冊新路由規則。如果是傳統 PHP/ASP 程式，則需要自行解析 URL 參數。
• 從查詢參數改為 Slug 查詢：原本用 $_GET['id'] 查資料庫，改為用 slug 查詢（如 WHERE slug = 'seo-guide'）。需確保每篇文章有唯一的 slug 欄位，並在資料庫加上索引。
• Slug 生成機制：為既有文章自動生成 slug，可從標題轉換（移除特殊字元、空格轉連字號、轉小寫）。需處理重複 slug 的情況。

前端程式修改

• 內部連結更新：所有網站內部的 <a href="article.php?id=123"> 都要改為 <a href="/articles/seo-guide">。這是工作量最大的部分，建議用全站搜尋替換的方式處理。
• sitemap.xml 更新：XML Sitemap 中的所有網址都要更新為新格式。
• Canonical 標籤更新：每個頁面的 <link rel="canonical"> 要指向新網址。
• 結構化資料（Schema.org）更新：JSON-LD 中的 URL 欄位也要改為新網址。
• Open Graph / Twitter Card 更新：社群分享的 meta 標籤中的 URL 也要同步更新。

資料庫修改

• 新增 slug 欄位（VARCHAR，加 UNIQUE INDEX）
• 為既有資料大量生成 slug
• 確保新增文章時自動生成 slug

三、網址轉換與 301 轉址設定

這是最關鍵的步驟——確保舊網址能自動轉址到新網址，避免 404 錯誤。

301 永久轉址的重要性

• 301 轉址告訴搜尋引擎「這個頁面已永久搬到新位置」，會將舊網址的 SEO 權重（排名訊號）傳遞到新網址
• 不設定 301 轉址的話，搜尋引擎會將舊網址視為 404（不存在），排名和流量將直接消失
• 使用者也會因為書籤或外部連結連到舊網址而看到 404 頁面

Nginx 設定範例

# 單頁轉址：舊網址 → 新網址
location = /article.php {
    if ($args ~* "id=123") {
        return 301 /articles/seo-guide;
    }
}
大量轉址：依規則轉換
/article.php?id=123 → /articles/{slug}
需搭配程式端處理，查資料庫取得對應 slug
location ~ ^/article.php$ {
# 透過 internal rewrite 交給程式查 slug 後轉址
rewrite ^ /redirect-handler.php last;
}
強制 HTTPS 和移除 www
server {
listen 80;
server_name example.com www.example.com;
return 301 https://example.com$request_uri;
}

Apache .htaccess 設定範例

# 啟用 Rewrite Engine
RewriteEngine On
單頁轉址
RewriteCond %{QUERY_STRING} ^id=123$
RewriteRule ^article.php$ /articles/seo-guide? [R=301,L]
大量轉址（需搭配程式處理）
RewriteRule ^article.php$ /redirect-handler.php [L]

轉址策略建議

• 少量頁面（<50 頁）：可手動逐一設定 301 轉址規則
• 大量頁面（>50 頁）：寫一個轉址處理程式，接收舊網址參數，查資料庫取得對應 slug，再 301 轉址到新網址
• 轉址鏈避免超過 1 跳：不要 A → B → C，應該直接 A → C
• 舊網址至少保留 6 個月：搜尋引擎需要時間收錄新網址，不要太早移除轉址規則

四、對既有 SEO 的影響與保護策略

改網址結構對 SEO 有重大影響，需要謹慎評估和準備。

短期影響

• 排名波動：即使設定 301 轉址，搜尋引擎在重新收錄期間（通常 2~8 週）排名可能出現暫時性下降
• 流量下降：過渡期間，部分頁面可能因為轉址延遲或索引未更新而流失流量
• Search Console 警告：Google Search Console 會顯示大量 301 轉址和索引變更，屬正常現象

長期影響（正面）

• 排名提升：SEO 友善網址有助於搜尋引擎理解頁面內容，長期排名會優於動態網址
• 點擊率提升：搜尋結果中乾淨的網址更容易被使用者點擊
• 收錄效率提升：結構化的網址更容易被搜尋引擎爬蟲發現和收錄

保護策略

1. 遷移前準備

• 完整記錄所有舊網址與對應新網址的對應表（URL Mapping）
• 在 Google Search Console 提交現有的 sitemap.xml，記錄當前索引狀態
• 確認所有舊網址都有對應的 301 轉址目標

2. 遷移時執行

• 選擇低流量時段切換（深夜或週末）
• 上線後立即檢查 301 轉址是否正常運作
• 提交新的 sitemap.xml 到 Google Search Console
• 使用 Search Console 的「網址檢查」工具逐一驗證重要頁面

3. 遷移後監控

• 每週檢查 Search Console 的索引狀態和排名變化
• 監控 404 錯誤報告，找出未設定轉址的漏網之魚
• 觀察搜尋流量變化趨勢，通常 4~8 週後恢復
• 如果 8 週後排名仍未恢復，需檢查轉址是否正確或是否有其他技術問題

常見錯誤與避免方式

五、實施時間表建議

完整的遷移建議分階段執行，避免一次改動太多造成混亂：

第 1 週：規劃與準備

• 制定網址規則
• 建立舊網址與新網址的對應表
• 在測試環境驗證新網址和轉址規則

第 2 週：程式修改

• 後端路由系統調整
• 資料庫新增 slug 欄位
• 前端連結更新
• Sitemap、canonical、結構化資料更新

第 3 週：測試與驗證

• 在測試環境完整測試所有頁面的新網址
• 測試所有 301 轉址規則
• 確認無 404 錯誤

第 4 週：正式上線與監控

• 選擇低流量時段切換
• 提交新 sitemap 到 Search Console
• 開始持續監控排名和流量

六、總結

將既有網站改用 URL Rewrite 是一項值得投資的工程，但必須有周全的計劃。最關鍵的原則是：不要讓任何一個舊網址變成 404。每一個舊網址都必須有對應的 301 永久轉址指向新網址，確保 SEO 權重完整轉移。短期可能會有排名波動，但長期來看，SEO 友善網址將帶來更好的搜尋能見度和使用者體驗。