網站SEO發布日清單：部署後的前48小時

你的部署在下午2點47分發布。構建通過。DNS在名稱伺服器間傳播。你的域名已解析。瀏覽器載入主頁——字體渲染、圖像顯示、腳本執行。你鬆了一口氣。

然後第二個問題出現了：接下來48小時內你的SEO會發生什麼？

這個窗口決定了Google是在幾天內發現你的頁面，還是漂流數週。舊的URL是否乾淨地重定向，還是在索引中散落著404。Search Console是否在第一個爬蟲預算到達之前連接——或之後你已經浪費了它。

以下是我在每次生產部署後執行的確切48小時清單。它涵蓋Search Console驗證、IndexNow ping、重定向審計、規範檢查，以及將快速索引與緩慢隱沒分開的七個技術任務。如果你已經在第47小時，無論如何都要從任務一開始——遲到總比沒有好。

多年來我已經啟動了數十個網站——從小型行銷頁面到Next.js和Astro上的大型無頭CMS構建——發布後的前48小時是大多數團隊要麼為強大的有機增長做好準備，要麼無聲地在數月內破壞他們的SEO的地方。區別不是什麼祕密醬。這是一個清單。一個無聊、有方法、極其重要的清單。

這就是那個清單。不是你在其他地方找到的那種毛茸茸的「確保你的內容很好」建議。這是你在第一天內需要做的特定、技術性的東西，大致按照你應該做的順序。

目錄

• 第0-1小時：起飛前驗證
• 第1-2小時：robots.txt和站點地圖配置
• 第2-4小時：Google Search Console設置
• 第2-4小時：Bing網站管理員工具和IndexNow
• 第4-8小時：重定向——無聲的殺手
• 第4-8小時：分析和追蹤驗證
• 第8-24小時：實際上首先被索引的內容
• 第24-48小時：監控和修復問題
• 完整的48小時清單表
• 常見問題

第0-1小時：起飛前驗證

在你甚至考慮搜索引擎之前，你需要確保基礎沒有損壞。我看過啟動時在<head>中仍然有臨時noindex標籤的情況。那是三週後才發現的有趣事情。

檢查遺留的臨時指令

這是第一大錯誤。打開你的瀏覽器，在主頁查看源代碼，並搜索：

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

如果仍在那裡，停止一切並修復它。也檢查你的HTTP標頭——某些框架（特別是Next.js）可以在伺服器級別設置X-Robots-Tag標頭：

curl -I https://yourdomain.com | grep -i robots

你應該看不到任何東西。如果你看到X-Robots-Tag: noindex，你的整個網站對搜索引擎不可見，此清單上的其他內容都不重要。

驗證SSL和規範URL

手動點擊這四個URL：

• http://yourdomain.com
• http://www.yourdomain.com
• https://yourdomain.com
• https://www.yourdomain.com

所有四個應該301重定向到單一規範版本。大多數網站使用https://yourdomain.com（非www、HTTPS）。如果其中任何一個提供200回應而不是重定向，你從第一分鐘開始就有重複內容。

驗證頁面標題和元描述

抽查你的前10個頁面。確保每個都有唯一的<title>標籤和<meta name="description">。我使用Screaming Frog來做這個，但你也可以直接curl一些頁面：

curl -s https://yourdomain.com | grep -o '<title>[^<]*</title>'

如果你執行無頭CMS設置——Sanity、Contentful、Storyblok——確保你的層實際上從CMS內容填充這些字段，而不是硬編碼佔位符文本。

第1-2小時：robots.txt和站點地圖配置

robots.txt

你的robots.txt文件位於https://yourdomain.com/robots.txt。它需要存在，並且需要正確。

對於大多數新網站，它應該看起來像這樣：

User-agent: *
Allow: /

Sitemap: https://yourdomain.com/sitemap.xml

就這樣。不要在發布日使其複雜化。你稍後可以為管理頁面、搜索結果頁面或其他不可索引的內容添加特定的disallow規則。現在的關鍵事情是：

1. 你沒有意外地阻止所有東西（Disallow: /是核武器選項）
2. 你指向你的站點地圖
3. 文件是可訪問的（返回200，而不是404）

如果你使用Next.js，App Router對生成robots.txt有內置支持：

// app/robots.ts
import { MetadataRoute } from 'next'

export default function robots(): MetadataRoute.Robots {
  return {
    rules: {
      userAgent: '*',
      allow: '/',
    },
    sitemap: 'https://yourdomain.com/sitemap.xml',
  }
}

對於Astro構建，你通常使用@astrojs/sitemap集成並在public/目錄中創建靜態robots.txt。

XML站點地圖

你的站點地圖告訴搜索引擎哪些頁面存在以及何時最後修改。它應該位於https://yourdomain.com/sitemap.xml。

好的發布日站點地圖：

• 僅包含你實際想要索引的頁面（無404、無重定向、無noindex頁面）
• 使用正確的規範URL（HTTPS、正確的www/非www）
• 具有準確的<lastmod>日期
• 每個站點地圖文件保持50,000個URL以下（如需要，使用站點地圖索引）

現在測試它：

curl -s https://yourdomain.com/sitemap.xml | head -50

確保它是有效的XML，而不是HTML頁面。我看過React應用攔截/sitemap.xml並改為提供應用殼層的情況。這對Googlebot沒有用。

第2-4小時：Google Search Console設置

這是你發布日最重要的單一SEO工具。不要跳過它。不要延遲它。

添加你的資產

1. 前往Google Search Console
2. 使用Domain選項添加你的資產（不是URL前綴）——這涵蓋所有子域和協議變體
3. 通過DNS TXT記錄驗證（你的主機提供商或Cloudflare使這很容易）

域級驗證需要幾分鐘才能傳播。在你等待的時候：

提交你的站點地圖

驗證後，轉到左側欄中的Sitemaps並提交你的站點地圖URL。Google將獲取它並報告任何錯誤。

我通常看到初始站點地圖處理在1-4小時內完成。Google會告訴你發現了多少個URL以及多少個有效。

為關鍵頁面請求索引

使用Search Console頂部的URL Inspection工具。粘貼你最重要的URL——主頁、關鍵著陸頁、頂級博客文章——並點擊Request Indexing。

Google每個資產大致限制每天10-12個索引請求。優先考慮：

1. 主頁
2. 核心服務/產品頁面
3. 關於頁面
4. 頂級內容頁面

不要浪費分頁頁面、標籤頁面或任何你認為是次要的東西的請求。

檢查覆蓋報告

在24小時內（通常更快），Pages報告將開始填充。注意：

• Not indexed: Crawled - currently not indexed — Google發現了頁面但選擇不索引它
• Not indexed: Discovered - currently not indexed — Google知道該頁面存在但尚未爬蟲它
• Excluded by robots.txt — 你的robots.txt阻止了你沒有打算阻止的東西

第2-4小時：Bing網站管理員工具和IndexNow

是的，Bing很重要。截至2026年初，它在美國約佔9%的搜索流量，加上DuckDuckGo、Yahoo，以及越來越多在Copilot和ChatGPT中使用AI驅動搜索結果（通過Bing的索引）。

Bing網站管理員工具設置

1. 前往Bing網站管理員工具
2. 你可以直接導入你的Google Search Console設置——Bing提供此選項並節省時間
3. 也在這裡提交你的站點地圖

Bing的索引通常比Google對新網站快，部分是因為IndexNow。

IndexNow協議

IndexNow是一個基於推送的協議，在內容更改時立即通知搜索引擎。Bing、Yandex和其他幾個引擎支持它。Google不支持（還沒有——自2022年以來他們一直在「評估」）。

以下是設置方法：

1. 生成API密鑰（任何字符串，如UUID）
2. 在https://yourdomain.com/{your-key}.txt創建密鑰文件，僅包含密鑰
3. Ping IndexNow API：

curl "https://api.indexnow.org/indexnow?url=https://yourdomain.com/&key=your-api-key"

對於大批量提交：

curl -X POST "https://api.indexnow.org/indexnow" \
  -H "Content-Type: application/json" \
  -d '{
    "host": "yourdomain.com",
    "key": "your-api-key",
    "urlList": [
      "https://yourdomain.com/",
      "https://yourdomain.com/about",
      "https://yourdomain.com/services"
    ]
  }'

現在許多主機平台和CMS工具本身就支持IndexNow。Cloudflare有一個IndexNow集成。WordPress有插件。如果你運行一個Next.js網站，你可以向你的構建/部署管道或CMS網鉤處理程序添加IndexNow ping。

第4-8小時：重定向——無聲的殺手

如果這是一個全新的域名沒有歷史，你大多可以跳過本節。但如果你正在重新啟動一個現有網站——新設計、新CMS、新URL結構——重定向是啟動出錯的地方。

將每個舊URL映射到其新等效物

在發布前，你應該有一個重定向地圖。在發布後，你需要驗證它有效。

獲取你的舊站點地圖（你確實保存了，對嗎？）並測試每個URL：

# 快速bash單行程序檢查重定向
while read url; do
  status=$(curl -o /dev/null -s -w "%{http_code}" -L "$url")
  echo "$status $url"
done < old-urls.txt

你在尋找：

• 301重定向到正確的新頁面（不是302——使用301表示永久移動）
• 無重定向鏈（舊URL → 中間URL → 最終URL）。每個重定向應直接轉到目標
• 無重定向循環（URL A → URL B → URL A）

常見重定向陷阱

問題	發生的情況	如何發現
遺漏尾部斜線重定向	/about和/about/是不同的URL	檢查兩個變體
區分大小寫	/About vs /about	測試錯誤的大小寫
查詢參數處理	舊URL帶有?id=123	檢查舊參數化URL
片段處理	錨點#section被去掉	檢查舊鏈接錨點
混合內容重定向	HTTP → HTTPS加路徑更改	確保單一301，不是鏈

在Next.js中，你在next.config.js中處理重定向：

module.exports = {
  async redirects() {
    return [
      {
        source: '/old-blog/:slug',
        destination: '/articles/:slug',
        permanent: true,
      },
    ]
  },
}

對於大規模重定向（數百或數千），考慮在邊緣處理——Vercel Edge Config、Cloudflare Workers或你的CDN的重定向規則。將2,000個重定向放在你的應用程序配置中可能會減慢構建。

第4-8小時：分析和追蹤驗證

Google Analytics 4 (GA4)

確保你的GA4資產在每個頁面上都正確觸發。最簡單的檢查：

1. 在Chrome中打開你的網站
2. 打開DevTools → Network選項卡
3. 按collect或google-analytics過濾
4. 在頁面之間導航——你應該看到每個頁面瀏覽的網絡請求

對於單頁應用（至少部分是大多數Next.js和Astro網站），驗證客戶端導航觸發頁面瀏覽。這是一個超級常見的遺漏——初始頁面加載觸發分析，但後續導航不觸發。

如果你使用Next.js App Router和@next/third-parties包：

import { GoogleAnalytics } from '@next/third-parties/google'

export default function RootLayout({ children }) {
  return (
    <html>
      <body>{children}</body>
      <GoogleAnalytics gaId="G-XXXXXXXXXX" />
    </html>
  )
}

Google Tag Manager

如果你使用GTM，驗證容器正在加載且你的標籤正在觸發。使用GTM預覽模式（Tag Assistant）進行調試。

設置核心網絡生命力監控

這對SEO排名很重要。你的發布日指標將成為你的基線。設置實際用戶監控：

• Google Search Console → Core Web Vitals報告（需要幾天才能填充）
• web-vitals JavaScript庫用於實時數據
• Vercel Analytics如果你在Vercel上（內置於平台，Pro版本$10/月）

截至2026年，Google的排名使用這些CWV閾值：

指標	好	需要改進	差
LCP（最大內容繪製）	≤ 2.5s	2.5s - 4.0s	> 4.0s
INP（交互到下一次繪製）	≤ 200ms	200ms - 500ms	> 500ms
CLS（累積佈局移位）	≤ 0.1	0.1 - 0.25	> 0.25

注意：INP在2024年3月替換了FID（第一輸入延遲）作為響應指標。如果任何指南仍然提到FID，它已過時。

第8-24小時：實際上首先被索引的內容

這是每個人都問的問題，答案可能會讓你驚訝。

Google的爬蟲優先級

根據我在數十次啟動中的經驗，這是典型的索引順序：

1. 主頁 — 幾乎總是第一個，通常在站點地圖提交和索引請求後的4-24小時內
2. 從主頁鏈接的頁面 — 你的主導航頁面接下來被爬蟲
3. 具有外部反向鏈接的頁面 — 如果你的新網站已經從其他網站有指向它的鏈接，那些目標頁面會優先
4. 僅限站點地圖的頁面 — 只能通過站點地圖發現的頁面（沒有從導航鏈接）最後被爬蟲

減慢索引的原因

• 內容較少 — 文本很少的頁面被降低優先級
• 重複內容 — 如果Google檢測到太相似的頁面，它會索引一個並跳過其餘的
• 孤立頁面 — 沒有內部鏈接指向它們的頁面（即使它們在站點地圖中）被視為低優先級
• 沒有權限的新域名 — 全新域名需要更長時間。這只是現實。Google對未知域名很謹慎。

新域名的現實索引時間表（2026年）

時間框架	預期結果
0-4小時	站點地圖已獲取，主頁已爬蟲
4-24小時	主頁已索引，頂級頁面已爬蟲
1-3天	主導航頁面已索引
1-2週	大多數站點地圖URL已爬蟲
2-4週	完整索引覆蓋品質頁面
1-3個月	搜索排名開始穩定

對於執行重新啟動的已建立域名，索引速度快得多——通常24-72小時內大多數頁面，假設你的重定向工作正確且你沒有根本改變URL結構。

第24-48小時：監控和修復問題

檢查Google Search Console覆蓋

現在，你應該看到數據流入。查看Pages報告並解決任何問題：

• 軟404 — 返回200的頁面但Google認為是錯誤頁面（通常是因為它們幾乎沒有內容）
• 伺服器錯誤（5xx） — 即使在你的瀏覽器中看起來不錯，你的網站也向Googlebot返回錯誤（這可能因激進的速率限制或機器人檢測而發生）
• 重定向錯誤 — 損壞的重定向鏈或循環

監控你的404

檢查你的伺服器日誌或分析是否有404錯誤。真實用戶和搜索引擎正在點擊不存在的URL。對於重新啟動，每個404都是一個遺漏的重定向，正在讓你損失鏈接權益。

獲取和渲染關鍵頁面

使用URL Inspection工具的Live Test功能來查看Google如何精確渲染你的頁面。這對JavaScript重型網站至關重要。如果你對重要內容使用客戶端渲染，Google可能看不到它。

這是我們經常為內容豐富的網站推薦伺服器端渲染或靜態生成的原因之一。我們的Next.js開發和Astro開發工作幾乎總是使用SSR或SSG。

完整的48小時清單表

時間	任務	優先級	工具
第0小時	移除臨時noindex標籤	關鍵	查看源、curl
第0小時	驗證SSL和規範重定向	關鍵	瀏覽器、curl
第0小時	抽查頁面標題和元描述	高	Screaming Frog、curl
第1小時	驗證robots.txt是否可訪問且正確	關鍵	瀏覽器
第1小時	驗證XML站點地圖有效且完整	關鍵	瀏覽器、XML驗證器
第2小時	設置Google Search Console	關鍵	GSC
第2小時	向Google提交站點地圖	關鍵	GSC
第2小時	為前10個頁面請求索引	高	GSC URL Inspection
第3小時	設置Bing網站管理員工具	高	Bing
第3小時	實現IndexNow	中	API、主機配置
第4小時	驗證所有重定向（僅重新啟動）	關鍵	curl、Screaming Frog
第4小時	驗證GA4跟蹤所有頁面	高	GA4實時、DevTools
第4小時	設置核心網絡生命力監控	中	GSC、web-vitals
第8小時	檢查GSC中的初始爬蟲統計	高	GSC
第24小時	檢查GSC覆蓋報告	高	GSC
第24小時	在日誌/分析中檢查404錯誤	高	伺服器日誌、GA4
第48小時	獲取和渲染測試關鍵頁面	中	GSC URL Inspection
第48小時	驗證索引頁面計數符合預期	高	site:yourdomain.com

常見問題

Google在2026年索引新網站需要多長時間？ 對於全新域名，如果你通過Google Search Console提交站點地圖並通過URL Inspection工具請求索引，主頁應在24小時內被索引。完整網站索引通常需要2-4週。正在重新啟動的已建立域名通常在3-7天內看到完整重新索引。這些時間表假設你已完成此清單中的所有內容——沒有Search Console提交，新域名可能在幾週內等待Google甚至發現它。

我應該將我的網站提交給Google還是等待其自然發現？ 總是主動提交。你應該「讓Google發現你」的想法是十年前過時的建議。通過Google Search Console提交你的站點地圖並使用URL Inspection工具為你最重要的頁面請求索引。沒有缺點，它會加速發現數天或數週。

IndexNow適用於Google嗎？ 不，截至2026年中期。Google自2021年末以來一直在評估IndexNow，但尚未正式採納。IndexNow目前適用於Bing、Yandex、Naver和一些其他。仍然值得實現，因為Bing的索引為DuckDuckGo、Yahoo Search提供動力，並由Microsoft Copilot和（部分）ChatGPT等AI助手使用。

301和302重定向對於SEO有什麼區別？ A 301是永久重定向，將大多數鏈接權益（排名力量）傳遞給目標URL。A 302是臨時的，告訴搜索引擎原始URL可能回來，所以他們不太可能傳輸排名信號。對於網站重新啟動和你不計劃反轉的URL更改，始終使用301。我看到許多團隊意外地使用302，因為這是某些框架的默認值。

為什麼我的頁面在Google Search Console中顯示為「Discovered - currently not indexed」？ 這意味著Google知道你的頁面存在（來自你的站點地圖或內部鏈接）但尚未爬蟲它。對於新網站，這在前幾天是正常的——Google將URL排隊並根據優先級爬蟲它們。如果頁面在2-3週內保持此狀態，通常意味著Google不認為它們的優先級足夠高。改進這些頁面的內部鏈接和添加獨特的有價值內容有幫助。

我需要Google Search Console和Bing網站管理員工具嗎？ 是的。它們為不同的搜索引擎服務並為你提供不同的數據。Google Search Console涵蓋大多數市場約90%的搜索流量，但Bing網站管理員工具涵蓋其餘的加上提供對IndexNow集成的訪問，這可以加速在Bing驅動的引擎上的索引。Bing設置只需大約5分鐘，因為你可以直接導入你的GSC配置。

我如何檢查我的JavaScript內容是否被Google索引？ 在Google Search Console中使用URL Inspection工具並點擊「Test Live URL」。然後查看渲染的HTML——這顯示Googlebot在執行你的JavaScript後看到的確切內容。如果關鍵內容從渲染輸出中丟失，你需要為該內容切換到伺服器端渲染。這特別常見於客戶端獲取內容的React SPA。Next.js和Astro等框架開箱即用地很好地處理這個問題。

我應該在發布日的robots.txt中阻止AI爬蟲嗎？ 這是一個取決於你的業務的判斷呼籲。GPTBot（OpenAI）、ClaudeBot（Anthropic）和Google-Extended（Gemini訓練）等機器人可以通過robots.txt阻止，如果你不希望你的內容用於AI訓練。但是，阻止GPTBot可能會影響你的內容在ChatGPT搜索結果中的顯示方式。我的建議：以允許一切的方式啟動，監控AI爬蟲的伺服器負載，並根據需要選擇性地添加塊。不要讓這個決定延遲你的啟動——你可以隨時稍後更新robots.txt。

如果你計劃網站啟動並希望從一開始就正確獲得技術SEO基礎，聯繫我們或查看我們的定價。弄錯這個東西稍後修復很昂貴。從一開始就正確做是便宜得多。