GSC 出現「缺乏價值的內容」怎麼辦？Next.js Blog 完整修復指南

當你在 Google Search Console 看到「缺乏價值的內容」這個警告，第一反應通常是：「我的文章寫得不夠好嗎？」

大多數情況下，不是。

這個警告更常見的原因是網站結構問題——你的 blog 在你不知情的狀況下，自動生成了幾百個 Google 認為沒有獨立價值的頁面。這篇指南會解釋這件事為什麼會發生，以及怎麼在 Next.js 環境下修復它。

什麼是「缺乏價值的內容」

Google 在決定要不要把一個頁面收進搜尋結果時，會評估這個頁面對搜尋者有沒有獨立的價值。如果一個頁面：

內容跟其他頁面高度重疊
幾乎沒有原創文字
只是把別處的內容重新排列

Google 就可能判定它「缺乏價值」，不把它放進索引。

這不是懲罰，而是 Google 的資源分配決策。Google 的爬蟲有「爬蟲預算」（crawl budget），不可能無限制地爬取每個頁面。當它看到你的網站有幾百個薄頁面，它會優先處理其他更有價值的網站。

最常見的根源：Tag 頁面爆炸

使用 Next.js 或任何靜態 blog 框架的網站，最常見的薄頁面來源是標籤（tag）頁面。

原理很簡單：你每用一個新 tag，框架就自動生成一個 /tags/{tag} 的列表頁。這個頁面的內容是什麼？就是「有這個 tag 的文章列表」。

如果某個 tag 只有一篇文章，這個列表頁就只有一筆資料，頁面上幾乎沒有原創文字。它跟文章本身的內容高度重疊，Google 沒有理由把它當成一個獨立有價值的頁面來收錄。

舉個例子：一個寫了 300 篇文章的 blog，可能累積了 700 個 tag，其中 600 個只有 1–2 篇文章。這就製造了 600 個薄頁面。

Loading diagram...

第二個來源：分頁

大多數 blog 的文章列表不只一頁，會有 /blog/page/2、/blog/page/3 這樣的分頁。

這些分頁預設是可以被 Google 索引的，但它們的問題跟 tag 頁面類似：內容跟 /blog 首頁高度重疊，只是換了一批文章。Google 沒有理由把每個分頁都當成獨立的搜尋結果。

解法的核心概念：noindex

解決這類問題的標準方法是在薄頁面加上 noindex 標記。

noindex 是你告訴 Google 的一個指令：「這個頁面不需要收進搜尋結果。」Google 看到這個標記，就會跳過它，不把它算進薄頁面的數量裡。

重要的是，noindex 跟「隱藏頁面」不同。加了 noindex 的頁面：

使用者還是可以直接訪問
頁面上的連結 Google 還是會追蹤（這就是為什麼要用 noindex, follow 而不是 noindex, nofollow）
只是不會出現在搜尋結果裡

判斷一個頁面該不該 noindex，可以照這個流程：

Loading diagram...

在 Next.js 怎麼實作

薄 Tag 頁加 noindex

在 app/tags/[tag]/page.tsx 的 generateMetadata 函式裡，讀取這個 tag 有幾篇文章，少於 3 篇就回傳 noindex：

export async function generateMetadata(props: {
  params: Promise<{ tag: string }>
}): Promise<Metadata> {
  const params = await props.params
  const tag = decodeURI(params.tag)
  const tagCounts = tagData as Record<string, number>
  const postCount = tagCounts[tag] ?? 0
  const isThin = postCount < 3

  return genPageMetadata({
    title: `主題：${tag}`,
    alternates: {
      canonical: `${siteMetadata.siteUrl}/tags/${encodeURIComponent(tag)}`,
    },
    ...(isThin && { robots: { index: false, follow: true } }),
  })
}

這段程式碼在做的事：每次有人（或爬蟲）訪問 /tags/xxx，Next.js 會去查這個 tag 有幾篇文章。如果少於 3 篇，頁面的 HTML <head> 裡就會多一行：

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

Google 看到這行，就知道不要把這個頁面收進索引。

3 篇的門檻怎麼決定？ 這沒有絕對標準。1–2 篇的 tag 頁幾乎確定是薄頁面；有 3 篇以上，頁面開始有一定的資訊量。你可以根據自己網站的狀況調整這個數字。

分頁加 noindex

在 app/blog/page/[page]/page.tsx 加上：

export async function generateMetadata(): Promise<Metadata> {
  return { robots: { index: false, follow: true } }
}

這讓 /blog/page/2 以後的所有分頁都帶上 noindex。/blog 首頁不受影響，繼續被索引。

Tag 的分頁（/tags/{tag}/page/{n}）也用同樣方式處理：

// app/tags/[tag]/page/[page]/page.tsx
export async function generateMetadata(): Promise<Metadata> {
  return { robots: { index: false, follow: true } }
}

修正 Canonical URL

如果你的 canonical URL 是相對路徑（'./'），要改成絕對 URL：

alternates: {
  canonical: `${siteMetadata.siteUrl}/tags/${encodeURIComponent(tag)}`,
}

Canonical URL 是什麼？ 它是你告訴 Google「這個頁面的正規網址是這個」的標記。如果你有分頁（/tags/ai、/tags/ai/page/2），正確的 canonical 能讓 Google 把這些頁面的 link equity 合併到主頁面，而不是分散掉。

清理 Sitemap

Sitemap 是你交給 Google 的「核准清單」——你在告訴 Google 哪些頁面值得收錄。

把薄 tag 頁從 sitemap 移除：

// app/sitemap.ts
const tagRoutes = Object.entries(tagData as Record<string, number>)
  .filter(([, count]) => count >= 3)  // 只保留有 3 篇以上的 tag
  .map(([tag]) => ({
    url: `${siteUrl}/tags/${encodeURIComponent(tag)}`,
    lastModified: new Date().toISOString().split('T')[0],
  }))

不要把分頁網址放進 sitemap。Sitemap 只放你真正想讓 Google 收錄的頁面。

部署之後：在 GSC 完成驗證

程式碼改好部署之後，還需要在 Google Search Console 主動告訴 Google 你修好了。不做這步，Google 不一定會馬上重新審查這些頁面。

Step 1：驗證修正

開 Google Search Console
左側選單：「產生索引」→「網頁」
找到「已找到 - 目前尚未建立索引」，點進去
右上角點 「驗證修正」，確認送出

Google 會重新抓取這些頁面，確認它們現在是否有 noindex 標記。

Step 2：重新提交 Sitemap

左側選單：「產生索引」→「Sitemap」
如有舊的 sitemap 記錄，點右側三個點 → 「移除 Sitemap」
輸入框填 sitemap.xml → 點「提交」

這讓 Google 拿到最新版的 sitemap，也就是只包含真正有價值頁面的版本。

要等多久

GSC 的驗證通常需要 2–4 週。這段時間 Google 會逐步重新審查那些頁面，確認 noindex 標記存在，然後更新索引狀態。

驗證期間不需要做任何事。可以在 GSC 看到驗證進度，狀態從「驗證中」變成「已修正」就代表完成。

預防勝於治療

幾個避免這類問題再次出現的習慣：

控制 tag 的數量。 寫文章時，優先使用已有的 tag，而不是每篇都創新 tag。一個 tag 至少要有 3 篇以上的文章才有意義。

定期審查索引狀態。 每隔幾個月看一下 GSC 的「網頁」報告，如果「未建立索引」的數量在增加，就值得追查原因。

Sitemap 只放精選內容。 把 sitemap 當成你對 Google 的推薦清單，不要把所有自動生成的 URL 都放進去。

「缺乏價值的內容」這個警告出現，代表你的網站結構在傳遞模糊的訊號給 Google。用 noindex 把薄頁面標記出來、更新 sitemap、在 GSC 驗證修正——這三步做完，問題基本上就解決了。