SEO 完整攻略

探索 SEO 的最佳實踐,提升網站能見度與流量。

URL 設計原則

短、易懂的 URL 讓搜尋引擎跟上你的節奏。

URL 設計原則

URL 設計基礎:從語法到實務

URL 語法概覽:協議、主機與路徑

在這篇文章裡,我們會把 URL 拆解成協議、主機跟路徑三個大段,像是把一封信拆成寄件人、收件人跟內容。你想知道每個部份長什麼樣子嗎?
我們會用許多實際範例來說明,讓你一次就能看懂 URL 的結構,也方便日後寫出更乾淨、更易讀的網址。

URL 語法概覽:協議、主機與路徑

URL(Uniform Resource Locator)就像是網際網路上的地址標籤,告訴瀏覽器「請往哪裡去」以及「用什麼方式拿資料」。它通常可以拆成三個主要部分:

  • 協議(Scheme):告訴你要用哪一種協定來抓取內容,例如 httphttpsftp 等。
  • 主機(Host):指定目標伺服器的位址,可能是域名、IPv4 或 IPv6。
  • 路徑(Path)+ 查詢字串 + 片段:指明你想要拿到哪個資源,以及額外參數或定位點。

下面先看一張簡單的表格,說明各部份在 URL 中的位置與常見範例。

部分 符號 範例 說明
協議 :// https 網路協定,決定連線方式
主機 直接位於 :// 後面 www.example.com 伺服器位置,可能帶埠號
路徑 / 開頭 /blog/post-1.html 資源路徑
查詢字串 ? + key=value ?id=123&sort=asc 送給伺服器的參數
片段 # + 標籤 #section-2 前端定位到頁面內部位置
協議(Scheme)

協議告訴瀏覽器用什麼方式跟伺服器溝通。常見的有:

  • http:// - 傳統的網路協定,沒有加密。
  • https:// - 加上 TLS/SSL 的安全版本,現在絕大多數網站都用這個。
  • ftp:// - 用來下載檔案。
  • file:// - 直接存取本機檔案(在瀏覽器中較少使用)。

舉例:

https://www.example.com → 這是一個安全的 HTTP 請求,主機是 www.example.com

主機(Host)

域名

最常見的是域名,例如 example.comblog.example.co.uk

子網域

你可以在前面加上子網域來區分功能:

  • api.example.com 用於 API 服務。
  • admin.example.com 是管理後台。

埠號(Port)

協議預設埠號通常隱藏在 URL 裡,例如 HTTP 預設是 80,HTTPS 是 443。若要改用非標準埠,就要明確寫出:

http://www.example.com:8080/path → 指定 8080 埠。

IPv4 / IPv6

有時候你會直接看到 IP 位址:

  • http://192.168.1.10/ (IPv4)
  • https://[2001:db8::1]/ (IPv6,注意方括號)。
路徑(Path)+ 查詢字串 + 片段

路徑(Path)

路徑告訴伺服器你想要哪個檔案或資源。它以 / 分隔,像是資料夾結構:

/blog/posts/2025/08/21.html → 這個位於 blog/posts/2025/ 資料夾中的 HTML 檔。

查詢字串(Query String)

查詢字串用來傳遞參數給伺服器,格式是 ?key=value&key2=value2。常見於搜尋或排序:

/search?q=URL+設計&page=2 → 搜尋關鍵字為「URL 設計」,翻到第二頁。

片段(Fragment)

片段是前端定位,瀏覽器不會把它送給伺服器。你常見於單頁面或長篇文章:

/blog/post-1.html#section-3 → 直接跳到 section-3 的位置。

綜合實例

把上述所有部分放在一起,完整的 URL 可能是這樣子:

https://shop.example.com:8443/products/42?ref=ad_campaign#reviews

  • 協議https → 安全 HTTPS。
  • 主機shop.example.com:8443 → 子網域 shop,埠號 8443。
  • 路徑/products/42 → 商品編號 42 的頁面。
  • 查詢字串?ref=ad_campaign → 傳遞參考來源資訊。
  • 片段#reviews → 跳到評論區塊。
小結
  1. 協議是「走哪條路」的指示;
  2. 主機告訴你「往哪個伺服器去」;
  3. 路徑、查詢字串跟片段則決定「拿什麼資料」以及前端顯示的位置。

記住這三大部份,未來寫 URL 或檢查 SEO 時,就能快速判斷結構是否符合最佳化原則。

乾淨 URL 原則:避免動態參數與重複內容

清晰的 URL:為什麼要避免動態參數?

在網頁設計裡,網址不只是機器人認識的路徑,更是使用者第一眼看到的資訊。若網址長得像 "https://example.com/product?id=123",那麼:

  • 搜尋引擎無法輕易判斷「商品名稱」與「類別」,
  • 使用者點進去後不容易記住或分享,
  • 站內重複內容的風險大幅上升。

動態參數的問題範例

  • 動態網址:/article?category=tech&title=ai-revolution
  • 靜態替代:/article/ai-revolution

動態網址裡的每一個 query string 都可能造成「相同內容不同 URL」的情況,進而被搜尋引擎視為重複內容。

乾淨 URL 的好處

  • 易於閱讀:使用者能夠直接從網址猜到頁面主題。
  • 提升分享率:短小、直觀的網址更容易被貼在社群或訊息裡。
  • 減少重複內容:固定路徑讓搜尋引擎明確知道哪個 URL 是正本,避免多個變體同時爬取。

實務操作:把動態參數轉成靜態路徑

  • 步驟一:在後端設定「重寫規則」或「路由」將 query string 轉為斜線分隔。
    例如:"/product?id=123" -> "/product/123"。
  • 步驟二:確保舊網址使用 HTTP 301 永久轉向到新的靜態網址,告訴搜尋引擎搬遷完成。
  • 步驟三:若頁面內容仍需根據參數顯示不同資料(如商品編號),就用「路徑參數」而非 query string。
    範例:/product/123 而不是 /product?id=123。

什麼情況下還是需要動態參數?

  • 登入、註冊或搜尋表單:這類頁面通常不會被索引,使用 query string 不影響 SEO。
    範例:/login?error=invalid 或 /search?q=手機。
  • 統計追蹤:如 Google Analytics 的 UTM 參數,僅供分析用途,可保留於外部連結不重寫。

小提醒

  • 避免多個相同內容的 URL:若兩個不同網址顯示相同產品,請使用 canonical 標籤指向正本。
    範例:<link rel="canonical" href="https://example.com/product/123">。
  • 保持一致性:一經決定結構,就全站統一執行;不然搜尋引擎會因頻繁變動而產生抓取困難。

總之,乾淨的 URL 不是為了美觀,而是為了讓使用者、搜尋引擎與機器人都能輕鬆理解。從今天起,先把所有動態參數轉成靜態路徑,再用 301 永久重定向,給網站一個更穩固的基礎吧!

Slug 設計最佳實踐:易讀且有關鍵字

Slug 設計最佳實踐:易讀且有關鍵字

Slug 是 URL 中最後一段文字,直接影響使用者與搜尋引擎的閱讀體驗。以下整理幾項核心原則,讓你在設計 Slug 時能兼顧可讀性、SEO 與維護性。

Slug 的基本結構

  • 只用小寫英文字母、數字與連桿(-)
  • 避免使用下劃線(_)、特殊符號或空白
  • 每段長度保持在 50~60 個字元以內,既能完整描述內容又不會被截斷。

1️⃣ 關鍵字先行:關鍵字放在前面

把最重要的關鍵字放在 Slug 開頭,這樣搜尋引擎更容易辨識主題,使用者也能一眼看懂內容。舉例來說,若文章標題是「2024 年台北最佳咖啡館」,Slug 建議為 taipei-best-cafes-2024

2️⃣ 避免冗長的參數

不要把日期、作者或無意義數字塞進 Slug,除非它對內容有實質貢獻。過多的參數會讓 URL 顯得雜亂,也可能被搜尋引擎視為垃圾訊息。

3️⃣ 用連桿分隔詞語

連桿是最常見且被搜尋引擎接受的單字分隔符號。舉例:台北-最佳咖啡館 會比 台北最佳咖啡館 更易辨識。

4️⃣ 保持一致性

  • 所有 Slug 都使用同一種分隔方式(連桿或底線)
  • 同一網站內相似主題保持統一格式,例如所有「旅遊」相關頁面都以 taipei- 為開頭。

5️⃣ 適度使用關鍵字,避免堆砌

關鍵字過多會適得其反。Slug 的目的是說明內容,而不是為了「塞滿」關鍵字。保持自然的語句長度即可。

6️⃣ 測試可讀性與易用性

  • 在手機瀏覽時,URL 是否能完整顯示?
  • 使用者點擊連結時,是否能預判內容?

範例對照表

原始 Slug 改良後 Slug 解析說明
taipei-2024-best-cafes taipei-best-cafes-2024 關鍵字前置,日期最後
blog-post-12345 travel-tips-in-taipei 移除無意義數字,加入主題關鍵字

常見錯誤案例

  • 使用大寫字母:URL 會因大小寫不同而產生重複頁面。
  • 連續多個連桿(---):看起來雜亂,且搜尋引擎不易解析。
  • 含有特殊符號(@、#、$ 等):瀏覽器可能需要編碼處理,降低可讀性。

工具建議

  • Slug Generator:輸入文章標題即可自動產生符合規範的 Slug。
  • SEO Audit Tools:檢查現有 URL 是否含有重複或不必要參數,並提供優化建議。

總結

Slug 既是網址,也是內容的小標題。遵循「小寫、連桿、關鍵字前置」的簡易規則,能夠讓使用者快速抓住重點,也有助於搜尋引擎正確索引。下次在建立新頁面時,先想好 Slug,再撰寫內容,就能一次搞定 URL 與 SEO 的雙贏!

參考資源

  • Google Search Central – URL 結構:了解搜尋引擎對 URL 的基本規範。
  • Moz – How to Write SEO-Friendly URLs:深入探討關鍵字在 Slug 中的最佳位置。
  • Yoast SEO Blog:提供多語系網站設定 Slug 的技巧與實務建議。

Canonical 標籤使用技巧:統一同源網址

Canonical 標籤:統一同源網址的實務技巧

如果你在管理多個網站或同一站點有不同入口,最常見的問題之一就是搜尋引擎會把相同內容拆成多個頁面。這不僅浪費時間,也可能讓排名被分散。

為什麼要統一同源網址?
  • 避免重複內容:當兩個 URL 指向相同資訊時,搜尋引擎會疑惑哪一個才是「正確」的來源。
  • 集中權重:把所有連結、引用與流量聚到單一頁面,能讓排名更穩定。

Canonical 標籤基本語法

<link rel="canonical" href="https://www.example.com/商品-ABC">

  • rel="canonical" 表示這是標準版本。
  • href 必須寫成完整網址(含協定),且與實際存取的頁面一致。若你使用的是相對路徑,搜尋引擎可能會解析錯誤,導致效果不佳。
常見同源差異示例
  • http 與 https:兩者被視為不同站點。建議統一為 https。
  • www 與非 www:例如 https://example.com vs https://www.example.com,同樣會分散權重。
  • 尾部斜線差異/page/page/ 兩個 URL 通常指向相同內容,但搜尋引擎視為不同頁面。
  • 查詢字串變化?utm_source=fb?utm_source=ig,即使是同一文章,也會被算作兩個獨立頁面。

實務操作步驟

  • 第一步:確定主網址。選擇你想要的正式 URL(例如 https://www.example.com/商品-ABC)。
  • 第二步:在每一個變體頁面加入 canonical 標籤,指向主網址。
  • 第三步:測試。使用瀏覽器開發者工具確認 <link rel="canonical" ...> 是否正確顯示。

具體範例

假設你有一篇產品說明,允許以下三種訪問方式:

  • https://example.com/商品-ABC
  • https://www.example.com/商品-ABC/
  • https://example.com/商品-ABC?utm_source=fb

在這些頁面中加入相同的 canonical:

<link rel="canonical" href="https://www.example.com/商品-ABC">

不管使用者從哪個連結進來,搜尋引擎都會統一認為官方網址是 https://www.example.com/商品-ABC

常見錯誤與排除方法
  • 忘記加協定:若寫成 <link rel="canonical" href="//www.example.com/…">,某些搜尋引擎可能解析不一致。最好寫明 https://
  • 指向自己站外網址:例如把 canonical 指向別人的網站,會造成排名錯亂。永遠只引用自己的主頁面。
  • 多重 canonical:同一頁面內出現兩個不同的 <link rel="canonical"> 會讓搜尋引擎不知所措,只保留最後一筆即可。

在 CMS 中自動加入

許多內容管理系統(如 WordPress、Drupal)都有插件或模組可以自動為每篇文章產生 canonical 標籤。若你使用的是 Shopify、Magento,則可在主題檔案中添加以下程式碼:

{{ 'canonical' | tag: page.url }}(Shopify 範例)

小結

  • 統一同源網址 能有效提升搜尋引擎對你的信任度。
  • 正確寫法:完整 URL、協定明確、只指向自己站點。
  • 測試與驗證:使用瀏覽器工具或搜尋引擎的結構化資料測試工具確認無誤。

只要按上述流程執行,你就能把所有同源變體合併成一個「官方」頁面,讓排名更穩定,也減少維護成本。

SEO友善 URL:提升搜尋能見度

關鍵字放置策略:首位、尾端與中間

關鍵字放置策略:首位、尾端與中間

在 URL 裡把關鍵字放在哪裡,直接影響到搜尋引擎對該頁面主題的判斷。以下會用實際例子說明三種常見的位置:開頭、中間跟結尾。

1️⃣ 首位(URL 開頭)

把關鍵字放在 URL 的最前面,能讓搜尋引擎一眼就抓到主題。例如:

這種寫法的好處是:

  • 讀者看到 URL 就能知道內容焦點。
  • 搜尋引擎對關鍵字的權重略高,因為它在前面更顯眼。
2️⃣ 尾端(URL 結尾)

把關鍵字放在結尾通常用於產品或服務頁面,例如:

好處:

  • 方便加上後綴(如 -2025 或 -官方)來做版本控制。
  • 讓整個結構更乾淨,避免重複關鍵字。
3️⃣ 中間(URL 之中)

在 URL 的中間位置放關鍵字,可以把主題與分類分開:

優點:

  • 方便把頁面歸類到更廣泛的目錄。
  • 讓 URL 看起來像路徑,易於閱讀。

實務小技巧

  • 用短而清晰的關鍵字,不要塞滿整個 URL。
  • 避免使用多餘的符號(如 _ 或 %)。
  • 盡量保持一致性,例如同一類別的頁面都放在「分類/關鍵字」結構。
  • 若網址已經固定,改動要慎重;不然會造成 404 或流量遺失。

小結

總結來說:

  • 首位最能吸引搜尋引擎注意,但適合主題標題頁面。
  • 尾端方便版本或品牌後綴,常用於產品、部落格文章。
  • 中間則是分類與關鍵字的平衡點,易於組織結構。

依照內容性質選擇最合適的位置,再配合簡短清晰,就能打造 SEO 友善 URL 了。

手機優先考量:簡短且易輸入

手機友善 URL 的重要性

手機使用者大多數會透過螢幕鍵盤輸入網址。若網址長且複雜,
就像在小型畫面上寫下『https://www.example.com/very-long-and-complicated-path』
這不僅耗時,也容易出錯。

  • 減少錯誤:短網址更易於手動輸入與複製。
  • 提升速度:簡短字串在瀏覽器載入時會稍快,尤其在慢速網路環境下表現明顯。
  • 加強品牌記憶:容易被使用者口述或筆寫,方便下次再訪。

因此,在設計網站結構時,就應把手機友善作為首要考量。

設計簡短且易輸入的手機 URL

  1. 限制長度:盡量控制在 50 個字元以內,
    這樣即使使用滑鼠或鍵盤,也不會被截斷。

  2. 避免特殊符號與空格:只保留英文字母、數字及連字符(-),
    例如『https://www.example.com/手機配件』可改寫成『https://www.example.com/shouji-paiqian』。

  3. 使用關鍵詞:選擇最能描述頁面內容的單一詞彙,避免冗長。
    例子:「最新」+「手機配件」可以寫成『latest-shouji-paiqian』。

  4. 去除停用字:如『the、and、in』等在網址中不必要,
    省略後可大幅縮短。

  5. 保持一致性:全站使用相同的命名規則與分隔符,
    讓瀏覽器能快速辨識結構。

  6. 測試輸入方便度:用實際手機鍵盤測試 URL 的輸入是否順暢,
    如有需要再微調長度或分割方式。

範例對照
  • 原始網址:https://www.example.com/2024-08-19/手機配件/最新款手機殼/高清圖片

  • 簡化後的手機友善網址:https://www.example.com/shouji-paiqian/latest-shouji-hu

以上步驟可以確保使用者在任何裝置上都能迅速且準確地輸入或點擊網址。

多國語言 URL:使用 hreflang 及地區子域

多國語言 URL 的設計思考

想要讓不同地區的使用者都能順利找到對應的內容,URL 就得好好規劃。下面我們用實際範例說明如何結合 hreflang 與地區子域來提升搜尋能見度,並避免重複內容被搜尋引擎誤判。

先把整個流程拆成三步:

  • 1️⃣ 決定 URL 結構(子域、路徑或類別)
  • 2️⃣ 在每一頁加上 hreflang 標籤,告訴搜尋引擎這是多語言版的同一內容
  • 3️⃣ 用 canonical 或 noindex + rel=canonical 來避免重複索引

1️⃣ 地區子域 VS 路徑 VS 類別

大多數情況下,我們推薦使用地區子域結合 hreflang。這樣既能保留清晰的 URL,又能讓搜尋引擎快速判斷目標國家。

2️⃣ Hreflang 標籤範例

  • <head> 加入
<link rel="alternate" hreflang="zh-tw" href="https://tw.example.com/產品/1234/">  <!-- 台灣華語版 -->
<link rel="alternate" hreflang="en-us" href="https://us.example.com/product/1234/">  <!-- 美國英語版 -->
<link rel="alternate" hreflang="ja-jp" href="https://jp.example.com/produto/1234/">  <!-- 日本日語版 -->
  • 注意hreflang 必須使用 ISO 639‑1(語言)+ ISO 3166‑1 Alpha‑2(國家)組合,例如 en-uszh-tw

3️⃣ Canonical 與 Noindex 的配合

  • 當一個子域只針對特定地區,且內容完全一致時,可在該子域加上 noindex
<meta name="robots" content="noindex, follow">  <!-- 不索引此頁,但允許追蹤連結 -->
  • 或者在主站(如 www.example.com)放一個 canonical 指向該子域,確保搜尋引擎只索引一次:
<link rel="canonical" href="https://tw.example.com/產品/1234/">
  • 案例:如果你有 www.example.com/product/1234 這個頁面,並且已經在子域上建立了同一內容,那麼在主站加上 noindexcanonical 可以避免重複索引。

4️⃣ 常見問題整理表

類別 優點 缺點 適用情境
地區子域 清晰、SEO友善、可直接定位國家 需要額外設定 DNS & SSL 多國語言大型站點
路徑 設定簡單、易於維護 可能被搜尋引擎誤判為同一內容 小型站點或測試環境
類別 快速部署 SEO不佳、難以區分語言 內部工具或管理頁面

5️⃣ 小結

  • 先決條件:確定每個子域都有獨立的 SSL 憑證,否則 HTTPS 會被搜尋引擎視為錯誤。
  • 測試工具:Google Search Console 的「國家/語言」報告可以快速確認 hreflang 是否正確工作。
  • 持續優化:若後續新增語言,只需要在對應子域加上相同的 <link rel="alternate">,不必大幅改動整站結構。

只要把以上步驟落實到每一頁,就能確保不同地區使用者都能順利找到適合自己的內容,同時避免搜尋引擎因重複內容而降低排名。祝你 SEO 成功 🚀

避免重複內容:noindex 與 robots.txt 配合

避免重複內容:noindex 與 robots.txt 配合

在台灣的網頁設計與 SEO 場景裡,往往會碰到「相同或極類似內容被搜尋引擎抓取多次」的問題。這不僅會讓排名受損,更可能導致使用者在搜尋結果中看到重複資訊而感到困惑。下面,我們將從實務角度說明,如何結合 noindexrobots.txt 兩種技術來有效避免重複內容。

為什麼會出現重複內容?

  • 多個 URL 指向同一篇文章:例如 https://example.com/https://www.example.com/ 或帶參數的版本(?utm_source=)。
  • 分類與標籤頁面:同樣的商品或文章被放在不同的分類或標籤中,造成內容重複。
  • 多語系網站:如果未正確使用 hreflang,相同文字可能以不同網址呈現。

noindex 的使用場景

  • 臨時頁面:如訂單確認、報名成功等不需要被搜尋引擎索引的頁面。
  • 重複內容聚合頁:例如 https://example.com/category/abc?sort=popularhttps://example.com/category/abc?sort=newest,只保留一個版本供搜尋引擎抓取。

使用方式很簡單,只要在 <head> 區塊加入以下 meta 標籤即可:

<meta name="robots" content="noindex, follow">

  • noindex 表示不要索引此頁面。
  • follow 仍允許搜尋機器人跟隨內部連結,保持站內其他重要頁面的權重流動。

robots.txt 的限制範圍

robots.txt 用來告訴搜尋引擎哪些 路徑檔案類型 不應該被抓取。它的語法很直覺,例如:

阻止所有機器人抓取 /private/ 目錄

User-agent: *
Disallow: /private/

僅允許 Google 抓取 /blog/ 目錄

User-agent: Googlebot
Allow: /blog/
Disallow: /

注意:robots.txt 不會 阻止搜尋引擎索引已經抓到的頁面;它只控制「是否被抓取」。如果你已經把某個重複頁面索引進來,僅靠 robots.txt 是無法將其從索引中移除。這時就需要 noindex 或者在 Google Search Console 裡手動刪除 URL。

noindex + robots.txt 如何配合

  1. 先用 robots.txt 阻止抓取:對於不想讓搜尋引擎偶爾進入的頁面(如登入後台、測試環境),使用 Disallow

  2. 在必要時加上 noindex:若某些頁面已被搜尋機器人抓取但你不希望它們顯示在搜尋結果中,則在該頁面加入 noindex meta 標籤。這樣即使 robots.txt 允許抓取,搜尋引擎也會忽略索引。

  3. 避免重複 URL 的「權重分散」:把所有重複內容集中到一個主頁面並加上 canonical 標籤,再將其他副本設為 noindex,這樣搜尋引擎只會索引主要版本。

實際操作示例

  • 案例 1:多參數排序頁

    • 主 URL:https://example.com/product/123

    • 排序變體:https://example.com/product/123?sort=price_asc?sort=price_desc

      
      <!-- 主頁面加入 canonical -->
      
      <link rel="canonical" href="https://example.com/product/123">
      
      ```,
      
      
    • 在排序變體中使用 noindex:

      
      <meta name="robots" content="noindex, follow">
      
      
  • 案例 2:分類與標籤重複

    • https://example.com/category/techhttps://example.com/tag/technology

    • 在標籤頁面加上 canonical 指向分類頁,並加 noindex。

  • 案例 3:測試環境

    • robots.txt:

      
      User-agent: *
      
      Disallow: /test/
      
      
    • 若有必要,對 /test/ 內頁面加入 noindex,確保不被索引。

常見錯誤與排查

  • 忘記加 follow:若只寫 noindex 而沒有 follow,搜尋機器人可能會停止跟隨該頁面內的連結,導致站內其他重要頁面的權重流失。
  • robots.txt 與 meta 標籤衝突:如果 robots.txt 阻止抓取,而你又在同一頁面加 noindex,搜尋機器人根本無法看到該標籤。先確保 robots.txt 允許抓取,再使用 noindex。
  • 重複的 canonicalnoindex:若主頁設了 canonical 指向自己,卻同時加了 noindex,那麼搜尋引擎會把整個主頁都忽略。確保只有副本才是 noindex。

小結

  1. robots.txt 用來控制「誰能抓取」;noindex 用來控制「是否被索引」。兩者配合,既能避免重複內容,又不會影響站內重要頁面的權重。
  • 把多餘的 URL 或測試環境先用 robots.txt 阻止。
  • 對已經抓取但你不想顯示的頁面加 noindex。
  • 用 canonical 把重複內容集中到一個主版本,其他副本設為 noindex。

掌握這三招,你就能讓搜尋引擎更清楚地理解你的站點結構,同時提升使用者在搜尋結果中的體驗。

URL 維護與升級:確保長期穩定

301/302 轉址策略:維持流量與 SEO

301/302 轉址策略:維持流量與 SEO

在網站搬遷、網址重構或產品頁面更新時,常會用到 301 或 302 的 HTTP 重新導向。這兩種方式不只是把使用者帶去新位置,更關係到搜尋引擎對舊 URL 的評估與權重轉移。

為什麼要選擇 301?

  • 301 表示「永久搬遷」,瀏覽器會把原本的網址記錄到快取,之後每次請求都自動跳轉至新位置。
  • 搜尋引擎收到 301 後,會把舊頁面的權重(PageRank、外部連結等)大部分移轉到新的 URL,幫助你維持排名與流量。

302 適用情境

  • 302 是「臨時搬遷」。如果只是短期測試或季節性活動,使用 302 可以避免搜尋引擎把舊頁面的權重全部轉走。
  • 例如:假設你要在某天推出限量版商品,暫時將購物車指向促銷頁面;等結束後再回到原本的產品介紹頁。這時候就用 302 比較合適。

如何正確寫 .htaccess(Apache)或 Nginx 指令?

  • Apache:在 .htaccess 裡加入 Redirect 301 /old-page.html https://example.com/new-page.html 或使用 RewriteRule ^old-page\.html$ https://example.com/new-page.html [R=301,L]
    • 若要同時保留原本的 Query String,可加上 [QSA,R=301,L]
  • Nginx:在伺服器區塊中寫 rewrite ^/old-page\.html$ https://example.com/new-page.html? permanent;,或使用 return 301 https://example.com$new_uri;

常見錯誤與避免方法

  • 把 302 用於永久搬遷:搜尋引擎會保留舊頁面的索引,導致分散權重、排名下滑。
  • 忽略 Query String:如果你在重寫時沒有保留 ?param=value,使用者可能丟失資料。
  • 設定錯誤的狀態碼:例如把 301 寫成 302 或反之,都會影響 SEO 成效。

小技巧:同時維持舊頁面索引但轉移流量

  • 在舊 URL 上放一個「此頁已搬遷」的訊息,並提供返回連結;這樣不僅能保留搜尋結果,還能讓訪客知道更新。

301 與 302 的差異表格

狀態碼 目的 搜尋引擎行為 使用範例
301 永久搬遷 權重大部分轉移,舊頁面不再索引 /old -> https://new.com/
302 臨時搬遷 搜尋引擎保留權重,舊頁面可繼續索引 /temp -> https://promo.com/

參考連結(簡易版)

URL 變更監控工具:Google Search Console 與站外連結追蹤

URL 變更監控工具:Google Search Console 與站外連結追蹤

當你要調整網站的網址結構(例如把 old-blog.com/post/123 改成 new-blog.com/articles/2024-08)時,除了確保內部連結正確無誤之外,也必須告訴搜尋引擎這個變動。否則舊鏈結會卡在 404 或被視為失效,導致流量下滑。

以下列出兩大工具的實務操作:

  • Google Search Console (GSC):直接告訴搜尋引擎新網址,並確認重定向是否正確。
  • 站外連結追蹤:利用第三方工具或自訂腳本檢查哪些外部網站仍指向舊網址,協助你發送修正請求。

接下來,我們一步步教你如何使用這些工具,並附上實際範例讓你快速上手。

Google Search Console 的基本操作流程
  1. 進入 GSC:開啟瀏覽器輸入 https://search.google.com/search-console,並以管理者帳號登入。

  2. 新增網站屬性:點擊左上角「新增屬性」,填入你要監控的域名,例如 new-blog.com,完成驗證後即可進入面板。

  3. 設定 301 重定向:在實際伺服器端先確保舊網址到新網址的 301(永久)重定向已正確。你可以用以下範例測試:

  • Apache .htaccess 範例:

將所有 /post/123 改成 /articles/2024-08

Redirect 301 /post/123 https://new-blog.com/articles/2024-08

  • Nginx 配置範例:

rewrite ^/post/123$ https://new-blog.com/articles/2024-08 permanent;

  1. 使用 GSC 的「URL 重新導向測試」:在左側選單點擊「覆寫」,輸入舊網址,系統會告訴你重定向是否正確。若顯示 301 並跳到新網址,就表示設定成功。

  2. 提交變更報告

  • 前往 GSC 左側「覆寫」>「重新導向測試」,將所有舊網址列入表格,確保都已被 Google 檢索。
  • 若你有大量 URL 需要更新,可以使用「抓取 > 爬蟲設定」或直接在 GSC 提交 sitemap,以加速搜尋引擎的重新編錄。
  1. 監控結果:回到 GSC 主頁面的「檢測問題」,Google 會列出因重定向失敗而造成的錯誤。你只要修正後,等幾天 Google 就會自動更新狀態。
站外連結追蹤與維護技巧

改版後,你可能仍有不少外部網站(例如合作夥伴、行銷平台)在指向舊網址。這些連結不但會浪費時間,也影響 SEO 表現。下面介紹幾個常用方法,協助你找出並修正這些連結:

  • 利用 Google Search Console 的「外部連結」報告:在左側選單點擊「連結」>「其他網站的連結」,可以看到指向你站台最常見的外部 URL。若看到舊網址,表示還有人使用。

  • 利用 Google 搜尋命令 link::在 Google 搜尋框輸入 link:old-blog.com/post/123,Google 會列出已索引的指向該頁面的網站。但這種方法不一定全能,因為搜尋結果經常變動。

  • 使用站外連結分析工具

    • Ahrefs / SEMrush(收費): 在「Backlink」報告中輸入舊網址即可看到所有指向它的域名。你可以直接從這裡發送修正請求或聯絡網站管理員。
    • Open Site Explorer (Moz):同樣提供外部連結列表,並可下載 CSV 方便後續處理。
  • 自訂腳本抓取:若你想更靈活(例如只抓特定域名),可以寫一個簡單的 Python 腳本利用 requests + BeautifulSoup 抓取搜尋結果。範例程式碼如下:

依賴: pip install requests beautifulsoup4

import requests
from bs4 import BeautifulSoup

def find_backlinks(url):
query = f"link:{url}"
headers = {"User-Agent": "Mozilla/5.0"}
r = requests.get(f"https://www.google.com/search?q={query}", headers=headers)
soup = BeautifulSoup(r.text, 'html.parser')

for a in soup.select('a[href]'):  # 選取所有連結
    href = a['href']
    if url not in href:     # 排除搜尋結果本身
        print(href)

範例呼叫

find_backlinks("old-blog.com/post/123")

  • 發送修正請求:一旦找出外部連結,最直接的做法是聯絡網站管理員或作者,告知他們舊網址已搬移並請求更新。你可以在郵件中附上新的 URL 與簡短說明。

  • 使用 301 重定向:如果無法即時修正外部連結,確保你已有的 301 設定能夠自動帶走流量。這樣即使對方還在舊網址,也不會造成失效。

小技巧
  • 批次發送郵件:若外部連結很多,建議製作一個表格(例如 Google Sheet),列出「來源網站」、「舊 URL」與「新 URL」。用這張表做為聯絡的參考。
  • 使用社群平台公告:在你的部落格或公司官方帳號上貼一則訊息,說明網址變更,並附上新連結。這不僅能提醒現有讀者,也可能吸引一些舊連結持續點擊。

透過上述方法,你可以快速掌握外部連結的狀況,確保網站在 URL 變動後仍維持良好的流量與使用體驗。

Schema.org URL 使用:提升 Rich Snippet 表現

為什麼要將網址納入 Schema.org 標記?

在搜尋結果中,Google 常會把「Rich Snippet」顯示為一個精美的卡片。這張卡片能夠直接呈現產品價格、星級評分、餐廳營業時間等資訊,吸引點擊率。

但若沒有將網址放進 Schema.org 的結構化資料裡,搜尋機器人就無法正確判斷哪個 URL 代表這筆資訊。結果就是卡片會顯示錯誤的連結,甚至不出現 Rich Snippet。

舉例來說:

  • 商品頁面 A:正確標記後,搜尋結果會顯示『購買此商品』的按鈕並導向 /product/1234
  • 同一個產品如果只用 /product/1234 作為 URL,但沒有在結構化資料裡告訴 Google 這是該商品,Google 可能把連結指到錯誤的頁面或直接忽略。

所以,把網址寫進 Schema.org,可以確保搜尋結果中的連結永遠指向正確的內容。

如何在頁面中加入網址的 Schema.org 標記?

最常見的做法是使用 JSON‑LD,因為它不會影響 HTML 的結構,也方便開發者維護。

以下以「商品」範例說明:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "高級咖啡杯",
  "image": [
    "https://www.example.com/images/cup1.jpg"
  ],
  "description": "這是一款專為咖啡愛好者設計的陶瓷杯,容量 350ml。",
  "sku": "CUP-001",
  "url": "https://www.example.com/product/cup-001",
  "offers": {
    "@type": "Offer",
    "priceCurrency": "TWD",
    "price": "299.00",
    "availability": "https://schema.org/InStock"
  }
}
</script>

重點說明:

  • url 欄位一定要寫成絕對網址,確保搜尋機器人能直接存取。
  • 若頁面有多個商品,只需在每個 JSON‑LD 片段裡換不同的 url 即可。

如果你喜歡 Microdata 或 RDFa,也可以這樣做:

<div itemscope itemtype="https://schema.org/Product">
  <span itemprop="name">高級咖啡杯</span>
  <img itemprop="image" src="/images/cup1.jpg" alt="咖啡杯圖片">
  <link itemprop="url" href="https://www.example.com/product/cup-001">
  <meta itemprop="sku" content="CUP-001">
  <!-- 省略其他屬性 -->
</div>

常見錯誤與排查技巧

  • 忘記加 url:如果 JSON‑LD 裡沒有 url 欄位,Google 會把搜尋結果的連結指向原始頁面,但如果該頁面包含多個產品,點擊後可能進到不正確的位置。
  • 使用相對路徑:像是 '/product/cup-001' 這樣的寫法,雖然在瀏覽器裡沒問題,但搜尋機器人無法確定完整域名,容易產生錯誤。一定要加上 https://yourdomain.com
  • 重複 URL:同一個頁面如果在多處標記不同的 url(例如 /product/1234 與 /item/1234),Google 會混淆,最終可能只顯示其中一個或根本不顯示 Rich Snippet。

排查工具:

  • 結構化資料測試工具:貼上整段 JSON‑LD,確認沒有語法錯誤並且 url 能夠正確存取。
  • Google 搜尋控制台:在「搜尋外觀」裡查看 Rich Snippet 的實際顯示效果,若連結不對就回到程式碼檢查。

範例:不同類型頁面的 URL 標記

  • 文章(Blog)
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://www.example.com/blog/how-to-cook-taiwanese-dumplings"
  },
  "headline": "台灣餃子做法大公開",
  "author": {"@type": "Person", "name": "阿明」},
  "datePublished": "2024-07-01",
  "url": "https://www.example.com/blog/how-to-cook-taiwanese-dumplings"
}
</script>
  • 餐廳(Restaurant)
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "name": "金鼎小吃",
  "image": ["https://www.example.com/images/restaurant.jpg"],
  "telephone": "+886-2-1234-5678",
  "url": "https://www.example.com/restaurants/gold-ding",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "台北市中正區仁愛路二段1號",
    "postalCode": "100"
  },
  "openingHoursSpecification": [
    {"@type": "OpeningHoursSpecification", "opens": "11:00", "closes": "22:00", "dayOfWeek": "https://schema.org/Monday"}
  ]
}
</script>

注意:所有範例都把 url 放在最外層,確保搜尋機器人能直接對應到這個實體。

如何測試 Rich Snippet 的表現?

  • 使用 Google Search Console:在「結構化資料」報告裡,確認每筆資料的 URL 已被索引並且沒有錯誤。

  • 搜尋結果預覽:輸入關鍵字後,在搜尋列右側通常會出現「富含標記」(Rich Result) 的預覽。若看到正確的連結、價格或評分,代表 URL 已被正確認識。

  • 第三方工具:如 Screaming Frog 或 Ahrefs 可以抓取頁面並顯示 JSON‑LD 片段,方便快速比對是否有遺漏 URL。

最後,記得定期檢查舊版網址或已搬移的頁面。若 URL 發生變動,務必同步更新 Schema.org 裡的 url 欄位,否則 Rich Snippet 可能會失效。

災難復原計畫:備份與測試 URL 轉址

災難復原計畫:備份與測試 URL 轉址

在網站長期經營過程中,URL 轉址往往是必不可少的調整。若沒做好備份和測試,一旦發生失誤,可能造成大量流量流失或搜尋引擎排名下滑。因此,本章將帶你一步步設計一套完整、可執行的災難復原流程。

1️⃣ 建立備份清單

  1. 先把所有目前使用中的 URL 列表匯出成 CSV 或 Google Sheet,包含:
  • 原始網址 (舊)
  • 新目標網址 (新)
  • HTTP 狀態碼 (301、302 等)
  • 轉址發佈日期
  1. 在雲端硬碟(如 Google Drive)建立一個「URL 備份」資料夾,並將 CSV 放入。若有多台同事協作,請設定版本控制或使用 Google Sheet 的「版本歷史」。

2️⃣ 測試轉址前的驗證

在正式發佈之前,你可以利用下列工具一次性測試整批 URL 是否正確:

  • Redirect Path:輸入 CSV,會顯示每個舊網址的最終跳轉位置。
  • HTTP Status Checker:檢查 301、302 等狀態碼是否符合預期。

若工具提示失敗,請回到原始清單修正並重新測試。

3️⃣ 災難情境模擬

假設你在某次更新後發現大量頁面跳轉錯誤(如 404 或無效連結)。此時可執行:

  • 快速回滾:使用之前備份的 CSV,將舊網址重新映射到原始目標。
  • 暫停轉址:在伺服器端關閉相關重寫規則(例如 .htaccess 或 Nginx config),讓舊頁面能直接存取。
  • 監控流量:透過分析工具查看回滾後的跳轉情況,確保問題已解決。

4️⃣ 定期檢查與維護清單

項目 說明 頻率
URL 清單更新 每次改版後立即匯出 隨時
測試工具執行 重新跑一次完整測試 每月
監控報告 檢查流量與錯誤碼 每週
備份存檔 將舊版 CSV 存入雲端 每次變更

小結

備份、測試、回滾三個環節缺一不可。只要你把每一步都寫成流程,並定期執行,就能在遇到 URL 轉址問題時快速恢復正常服務。