了解搜索引擎是如何抓取、渲染和索引網(wǎng)頁的，對(duì)于針對(duì)搜索引擎優(yōu)化網(wǎng)站至關(guān)重要。多年來，隨著谷歌等搜索引擎不斷改變其流程，我們很難了解哪些有效，哪些無效--尤其是客戶端 JavaScript。

我們注意到，一些陳舊的觀念一直存在，讓社區(qū)對(duì)應(yīng)用 SEO 的最佳實(shí)踐缺乏信心：

1. "谷歌無法渲染客戶端 JavaScript"。
2. "谷歌對(duì) JavaScript 頁面的處理方式不同"。
3. "渲染隊(duì)列和時(shí)間對(duì) SEO 有重大影響"。
4. "JavaScript 量大的網(wǎng)站頁面發(fā)現(xiàn)速度較慢"。

為了解決這些問題，我們與領(lǐng)先的搜索引擎優(yōu)化和數(shù)據(jù)工程咨詢公司 MERJ[1] 合作，對(duì) Google 的抓取行為進(jìn)行了新的實(shí)驗(yàn)。我們分析了不同網(wǎng)站上超過 100,000 次的 Googlelebot 抓取行為，以測(cè)試和驗(yàn)證 Google 的搜索引擎優(yōu)化能力。

讓我們來看看 Google 的渲染方式是如何演變的。然后，我們將探討我們的發(fā)現(xiàn)及其對(duì)現(xiàn)代web應(yīng)用的實(shí)際影響。

谷歌渲染能力的演變

多年來，谷歌抓取和索引網(wǎng)頁內(nèi)容的能力發(fā)生了顯著變化。了解這一演變對(duì)于理解現(xiàn)代web應(yīng)用的搜索引擎優(yōu)化現(xiàn)狀非常重要。

2009 年以前：對(duì) JavaScript 的支持有限

在搜索的早期，谷歌主要索引靜態(tài) HTML 內(nèi)容。搜索引擎基本上看不到 JavaScript 生成的內(nèi)容，這導(dǎo)致靜態(tài) HTML 被廣泛用于搜索引擎優(yōu)化。

2009-2015年：AJAX 抓取方案

谷歌推出了 AJAX 抓取方案，允許網(wǎng)站提供動(dòng)態(tài)生成內(nèi)容的 HTML 快照。這是一種權(quán)宜之計(jì)，需要開發(fā)人員為網(wǎng)頁創(chuàng)建單獨(dú)的可抓取版本

2015-2018年：早期 JavaScript 渲染

谷歌開始使用無頭 Chrome 瀏覽器渲染網(wǎng)頁，標(biāo)志著向前邁進(jìn)了一大步。不過，這種舊版瀏覽器在處理現(xiàn)代 JavaScript 功能方面仍有局限。

2018 年至今：現(xiàn)代渲染能力

如今，谷歌使用最新版本的 Chrome 瀏覽器進(jìn)行渲染，與最新的網(wǎng)絡(luò)技術(shù)保持同步。當(dāng)前系統(tǒng)的主要方面包括：

1. 通用渲染：Google 現(xiàn)在會(huì)嘗試渲染所有 HTML 頁面，而不僅僅是一個(gè)子集。
2. 最新的瀏覽器：Googlebot 使用最新穩(wěn)定版本的 Chrome/Chromium，支持現(xiàn)代 JS 功能。
3. 無狀態(tài)渲染：每次頁面渲染都是在一個(gè)全新的瀏覽器會(huì)話中進(jìn)行的，不會(huì)保留之前渲染的 cookie 或狀態(tài)。谷歌一般不會(huì)點(diǎn)擊頁面上的項(xiàng)目，如標(biāo)簽內(nèi)容或 cookie 橫幅。
4. 隱藏：谷歌禁止向用戶和搜索引擎顯示不同的內(nèi)容來操縱排名。避免根據(jù) User-Agent 更改內(nèi)容的代碼。取而代之的是，為 Google 優(yōu)化應(yīng)用程序的無狀態(tài)渲染，并通過有狀態(tài)方法實(shí)現(xiàn)個(gè)性化。
5. 資產(chǎn)緩存：Google 通過緩存資產(chǎn)加快網(wǎng)頁渲染速度，這對(duì)于共享資源的頁面和重復(fù)渲染同一頁面非常有用。Google 的網(wǎng)頁渲染服務(wù)不使用 HTTP Cache-Control 標(biāo)頭，而是采用自己的內(nèi)部啟發(fā)式方法來確定緩存資產(chǎn)何時(shí)仍然新鮮，何時(shí)需要再次下載。

圖片

在更好地了解 Google 的能力之后，讓我們來看看一些常見的誤區(qū)以及它們對(duì)搜索引擎優(yōu)化的影響。

方法

為了研究以下誤區(qū)，我們使用 Vercel 的基礎(chǔ)架構(gòu)和 MERJ 的網(wǎng)絡(luò)渲染監(jiān)控器（WRM）技術(shù)進(jìn)行了一項(xiàng)研究。我們的研究重點(diǎn)是 nextjs.org[2]，以及 monogram.io[3] 和 basement.io[4] 的補(bǔ)充數(shù)據(jù)，時(shí)間跨度為 2024 年 4 月 1 日至 4 月 30 日。

數(shù)據(jù)收集

我們?cè)谶@些網(wǎng)站上放置了一個(gè)定制的邊緣中間件[5]，用于攔截和分析來自搜索引擎機(jī)器人的請(qǐng)求。通過該中間件，我們可以：

1. 識(shí)別并跟蹤來自各種搜索引擎和AI爬蟲的請(qǐng)求（查詢中不包括用戶數(shù)據(jù)）。
2. 在 HTML 響應(yīng)中為機(jī)器人注入一個(gè)輕量級(jí) JavaScript 庫[6]。

該 JavaScript 庫在頁面渲染完成時(shí)觸發(fā)，向長(zhǎng)期運(yùn)行的服務(wù)器發(fā)送數(shù)據(jù)，其中包括：

• 頁面 URL
• 唯一請(qǐng)求標(biāo)識(shí)符（用于將頁面渲染與常規(guī)服務(wù)器訪問日志進(jìn)行匹配）
• 渲染完成的時(shí)間戳（使用服務(wù)器上的 JavaScript 庫請(qǐng)求接收時(shí)間計(jì)算得出）。

數(shù)據(jù)分析

通過比較服務(wù)器訪問日志中的初始請(qǐng)求和我們的中間件向外部燈塔服務(wù)器發(fā)送的數(shù)據(jù)，我們可以：

1. 確認(rèn)哪些頁面被搜索引擎成功渲染。
2. 計(jì)算初始抓取和完成渲染之間的時(shí)間差。
3. 分析不同類型內(nèi)容和 URL 的處理模式。

數(shù)據(jù)范圍

在本文中，我們主要關(guān)注來自 Googlebot 的數(shù)據(jù)，它提供了最大、最可靠的數(shù)據(jù)集。我們的分析包括超過 37,000 個(gè)與服務(wù)器-燈塔對(duì)匹配的渲染 HTML 頁面，為我們提供了一個(gè)強(qiáng)大的樣本來得出結(jié)論。

我們?nèi)栽谑占渌阉饕娴臄?shù)據(jù)，包括 OpenAI 和 Anthropic 等人工智能提供商的數(shù)據(jù)，并希望在未來更多地討論我們的發(fā)現(xiàn)。

在下面的章節(jié)中，我們將深入探討每個(gè)誤區(qū)，并在必要時(shí)提供更多相關(guān)方法。

誤區(qū)1：谷歌無法渲染JavaScript內(nèi)容

這一誤區(qū)導(dǎo)致許多開發(fā)人員避開 JS 框架，或采用復(fù)雜的變通方法來實(shí)現(xiàn)SEO。

測(cè)試

為了測(cè)試 Google 渲染 JavaScript 內(nèi)容的能力，我們重點(diǎn)關(guān)注了三個(gè)關(guān)鍵方面：

1. JS 框架兼容性：我們使用 nextjs.org[7] 上的數(shù)據(jù)分析了 Googlebot 與 Next.js 的交互，Next.js.org[8] 混合使用了靜態(tài)預(yù)渲染、服務(wù)器端渲染和客戶端渲染。
2. 動(dòng)態(tài)內(nèi)容索引：我們檢查了 nextjs.org[9] 上通過 API 調(diào)用異步加載內(nèi)容的頁面。這使我們能夠確定 Googlebot 是否能夠處理和索引初始 HTML 響應(yīng)中不存在的內(nèi)容。
3. 通過 React 服務(wù)器組件 (RSC) 流式加載內(nèi)容：與上述情況類似，nextjs.org[10] 的大部分內(nèi)容都是使用 Next.js App Router[11] 和 RSC[12] 構(gòu)建的。我們可以看到 Googlebot 是如何處理并索引增量流向頁面的內(nèi)容的。
4. 渲染成功率：我們將服務(wù)器日志中的 Googlebot 請(qǐng)求數(shù)與收到的成功渲染燈塔數(shù)進(jìn)行了比較。這讓我們深入了解了完全渲染的抓取頁面所占的比例。

發(fā)現(xiàn)

1. 在 nextjs.org[13] 上分析的 100,000 多次 Googlebot 抓取中，除去狀態(tài)代碼錯(cuò)誤和不可索引的頁面，100% 的 HTML 頁面都實(shí)現(xiàn)了全頁面渲染，包括具有復(fù)雜 JS 交互的頁面。
2. 所有通過 API 調(diào)用異步加載的內(nèi)容都被成功索引，這證明了 Googlebot 處理動(dòng)態(tài)加載內(nèi)容的能力。
3. 基于 React 框架的 Next.js 被 Googlebot 完全渲染，這證明了它與現(xiàn)代 JavaScript 框架的兼容性。
4. 通過 RSC 流式傳輸?shù)膬?nèi)容也被完全渲染，這證明流式傳輸不會(huì)對(duì) SEO 產(chǎn)生不利影響[14]。
5. Google 會(huì)嘗試渲染它抓取的幾乎所有 HTML 頁面，而不僅僅是 JavaScript 重度頁面的子集。

誤區(qū)2：谷歌對(duì) JavaScript 頁面的處理方式不同

一個(gè)常見的誤解是，谷歌對(duì) JavaScript 較多的網(wǎng)頁有單獨(dú)的處理程序或標(biāo)準(zhǔn)。我們的研究以及 Google 的官方聲明揭穿了這一誤區(qū)。

測(cè)試

為了測(cè)試 Google 在哪些方面對(duì) JS 較多的頁面采取了不同的處理方式，我們采取了幾種有針對(duì)性的方法：

1. CSS @import測(cè)試：我們創(chuàng)建了一個(gè)不含 JavaScript 的測(cè)試頁面，但其中的 CSS 文件會(huì) @import 第二個(gè) CSS 文件（只有在渲染第一個(gè) CSS 文件時(shí)才會(huì)下載并顯示在服務(wù)器日志中）。通過將這一行為與啟用 JS 的頁面進(jìn)行比較，我們可以驗(yàn)證在啟用和未啟用 JS 的情況下，Google 渲染器處理 CSS 的方式是否有所不同。
2. 狀態(tài)碼和元標(biāo)簽處理：我們開發(fā)了一個(gè)帶有中間件的 Next.js 應(yīng)用程序，用于測(cè)試 Google 的各種 HTTP 狀態(tài)代碼。我們的分析重點(diǎn)是谷歌如何處理不同狀態(tài)代碼（200、304、3xx、4xx、5xx）的網(wǎng)頁以及帶有 noindex 元標(biāo)簽的網(wǎng)頁。這有助于我們了解在這些情況下，JavaScript 較多的頁面是否會(huì)受到不同的處理。
3. JavaScript 復(fù)雜性分析：我們比較了 nextjs.org[15] 上不同 JavaScript 復(fù)雜程度頁面的 Google 渲染行為。這包括使用最少 JS 的頁面、具有適度交互性的頁面和具有大量客戶端渲染的高動(dòng)態(tài)頁面。我們還計(jì)算并比較了初始抓取和完成渲染之間的時(shí)間，以了解更復(fù)雜的 JS 是否會(huì)導(dǎo)致更長(zhǎng)的渲染隊(duì)列或處理時(shí)間。

發(fā)現(xiàn)

1. 我們的 CSS @import 測(cè)試證實(shí)，無論是否有 JS，Google 都能成功渲染頁面。
2. 無論是否有 JS 內(nèi)容，Google 都能渲染所有 200 狀態(tài)的 HTML 頁面。使用原始 200 狀態(tài)頁面的內(nèi)容渲染 304 狀態(tài)頁面。不渲染其他 3xx、4xx 和 5xx 錯(cuò)誤的頁面。
3. 不渲染初始 HTML 響應(yīng)中包含 noindex 元標(biāo)記的頁面，無論 JS 內(nèi)容如何?？蛻舳艘瞥?noindex 標(biāo)簽對(duì)搜索引擎優(yōu)化無效；如果一個(gè)頁面在初始 HTML 響應(yīng)中包含 noindex 標(biāo)簽，它將不會(huì)被渲染，而移除該標(biāo)簽的 JavaScript 也不會(huì)被執(zhí)行。
4. 我們發(fā)現(xiàn)，在渲染具有不同 JS 復(fù)雜程度的頁面時(shí)，Google 的成功率沒有顯著差異。在 nextjs.org[16] 的規(guī)模上，我們也沒有發(fā)現(xiàn) JavaScript 復(fù)雜性與渲染延遲之間的相關(guān)性。不過，在規(guī)模更大的網(wǎng)站上，更復(fù)雜的 JavaScript 可能會(huì)影響抓取效率。

誤區(qū)3：渲染隊(duì)列和時(shí)間對(duì) SEO 有重大影響

許多SEO從業(yè)人員認(rèn)為，由于渲染隊(duì)列的原因，JavaScript 較多的網(wǎng)頁在索引過程中會(huì)面臨嚴(yán)重的延遲。我們的研究對(duì)這一過程有了更清晰的認(rèn)識(shí)。

測(cè)試

為了解決渲染隊(duì)列和時(shí)間對(duì)搜索引擎優(yōu)化的影響，我們進(jìn)行了以下調(diào)查：

1. 渲染延遲：我們使用 nextjs.org[17] 上超過 37,000 個(gè)匹配服務(wù)器-燈塔對(duì)的數(shù)據(jù)，檢查了谷歌最初抓取頁面與完成渲染之間的時(shí)間差。
2. URL 類型：我們分析了帶查詢字符串和不帶查詢字符串的 URL 以及 nextjs.org[18] 不同部分（如 /docs、/learn、/showcase）的渲染時(shí)間。
3. 頻率模式：我們研究了 Google 重新渲染頁面的頻率，以及不同類型內(nèi)容的渲染頻率是否存在模式。

發(fā)現(xiàn)

渲染延遲分布如下：

• 第 50 個(gè)百分位數(shù)（中位數(shù)）：10 秒
• 第 75 個(gè)百分位數(shù)：26 秒
• 第 90 個(gè)百分位數(shù)：~3 小時(shí)
• 第 95 個(gè)百分位數(shù)：~6 小時(shí)
• 第 99 個(gè)百分位數(shù)：~18 小時(shí)

圖片

令人驚訝的是，第 25 百分位數(shù)的頁面在初始抓取后 4 秒內(nèi)就能渲染，這對(duì) "長(zhǎng)隊(duì)列" 的概念提出了質(zhì)疑。

雖然有些頁面面臨嚴(yán)重的延遲（第 99 百分位數(shù)的頁面延遲時(shí)間長(zhǎng)達(dá)約 18 小時(shí)），但這些都是例外，而不是常規(guī)。

我們還觀察到一些有趣的模式，這些模式與 Google 如何快速渲染帶有查詢字符串 (?param=xyz)的 URL 有關(guān)：

圖片

這些數(shù)據(jù)表明，如果 URL 包含不影響內(nèi)容的查詢字符串，Google 會(huì)以不同的方式處理 URL。例如，在 nextjs.org[19] 上，帶有 ?ref= 參數(shù)的頁面的渲染延遲時(shí)間更長(zhǎng)，尤其是在百分位數(shù)較高的情況下。

此外，我們注意到，與較靜態(tài)的部分相比，/docs 等經(jīng)常更新的部分的中位渲染時(shí)間較短。例如，/showcase 頁面盡管經(jīng)常被鏈接，但渲染時(shí)間卻更長(zhǎng)，這表明 Google 可能會(huì)放慢對(duì)變化不大的頁面的重新渲染速度。

誤區(qū)4：大量使用 JavaScript 的網(wǎng)站頁面發(fā)現(xiàn)速度較慢

SEO界始終認(rèn)為，JavaScript 量大的網(wǎng)站，尤其是那些依賴于客戶端渲染（CSR）的網(wǎng)站，如單頁應(yīng)用程序（SPA），谷歌發(fā)現(xiàn)頁面的速度較慢。我們的研究在這方面提供了新的見解。

測(cè)試

為了研究 JavaScript 對(duì)頁面發(fā)現(xiàn)的影響，我們：

1. 分析了不同渲染場(chǎng)景下的鏈接發(fā)現(xiàn)：我們比較了 Google 在 nextjs.org[20] 上服務(wù)器渲染、靜態(tài)生成和客戶端渲染的頁面中發(fā)現(xiàn)和抓取鏈接的速度。
2. 測(cè)試非渲染的 JavaScript 有效載荷：我們?cè)?nextjs.org[21] 的 /showcase 頁面上添加了一個(gè)類似于 React 服務(wù)器組件 (RSC) 有效負(fù)載的 JSON 對(duì)象，其中包含指向以前未發(fā)現(xiàn)的新頁面的鏈接。這樣，我們就可以測(cè)試 Google 能否發(fā)現(xiàn)未渲染的 JavaScript 數(shù)據(jù)中的鏈接。
3. 比較發(fā)現(xiàn)時(shí)間：我們監(jiān)測(cè)了 Google 發(fā)現(xiàn)和抓取以不同方式鏈接的新網(wǎng)頁的速度：標(biāo)準(zhǔn) HTML 鏈接、客戶端渲染內(nèi)容中的鏈接以及未渲染的 JavaScript 有效載荷中的鏈接。

發(fā)現(xiàn)

1. 無論采用何種渲染方法，Google 都能成功發(fā)現(xiàn)并抓取完全渲染頁面中的鏈接。
2. Google 可以發(fā)現(xiàn)頁面上未渲染 JavaScript 有效載荷中的鏈接，例如 React Server Components 或類似結(jié)構(gòu)中的鏈接。
3. 在初始和渲染的 HTML 中，谷歌都會(huì)使用當(dāng)前主機(jī)和端口作為相對(duì) URL 的基礎(chǔ)，通過識(shí)別類似 URL 的字符串來處理內(nèi)容。(在我們類似 RSC 的有效負(fù)載中，谷歌沒有發(fā)現(xiàn)編碼 URL（即 https%3A%2F%2Fwebsite.com[22]），這表明谷歌的鏈接解析非常嚴(yán)格）。
4. 鏈接的來源和格式（如在 <a> 標(biāo)記中或嵌入在 JSON 有效負(fù)載中）并不影響 Google 抓取的優(yōu)先級(jí)。無論 URL 是在初始抓取中發(fā)現(xiàn)還是在渲染后發(fā)現(xiàn)，抓取優(yōu)先級(jí)都保持一致。
5. 雖然 Google 能成功發(fā)現(xiàn) CSR 頁面中的鏈接，但這些頁面確實(shí)需要先進(jìn)行渲染。服務(wù)器渲染的頁面或部分預(yù)渲染的頁面在即時(shí)鏈接發(fā)現(xiàn)方面略占優(yōu)勢(shì)。
6. 谷歌對(duì)鏈接發(fā)現(xiàn)和鏈接價(jià)值評(píng)估進(jìn)行了區(qū)分。對(duì)網(wǎng)站架構(gòu)和抓取優(yōu)先級(jí)的鏈接價(jià)值評(píng)估是在全頁面渲染之后進(jìn)行的。
7. 更新 sitemap.xml 即使不能消除不同渲染模式之間的鏈接發(fā)現(xiàn)時(shí)間差異，也能大大減少這種差異。

總體影響和建議

我們的研究揭穿了 Google 處理 JavaScript 重度網(wǎng)站的幾個(gè)常見誤區(qū)。以下是主要結(jié)論和可行建議：

影響

1. JavaScript 兼容性：Google 可以有效地渲染 JavaScript 內(nèi)容并編制索引，包括復(fù)雜的 SPA、動(dòng)態(tài)加載的內(nèi)容和流媒體內(nèi)容。
2. 渲染平等性：與靜態(tài) HTML 網(wǎng)頁相比，谷歌處理 JavaScript 內(nèi)容較多的網(wǎng)頁的方式?jīng)]有本質(zhì)區(qū)別。所有頁面都會(huì)被渲染。
3. 渲染隊(duì)列現(xiàn)實(shí)：雖然存在渲染隊(duì)列，但其影響沒有以前想象的那么大。大多數(shù)頁面都是在幾分鐘內(nèi)渲染，而不是幾天或幾周。
4. 頁面發(fā)現(xiàn)：JavaScript 較多的網(wǎng)站（包括 SPA）在谷歌頁面發(fā)現(xiàn)方面并不處于劣勢(shì)。
5. 內(nèi)容時(shí)機(jī)：某些元素（如 noindex 標(biāo)簽）何時(shí)添加到頁面至關(guān)重要，因?yàn)?Google 可能不會(huì)處理客戶端的更改。
6. 鏈接價(jià)值評(píng)估：Google 區(qū)分鏈接發(fā)現(xiàn)和鏈接價(jià)值評(píng)估。后者發(fā)生在全頁面渲染之后。
7. 渲染優(yōu)先級(jí)：Google 的渲染過程并不是嚴(yán)格的先入先出。與 JavaScript 的復(fù)雜性相比，內(nèi)容的新鮮度和更新頻率等因素對(duì)優(yōu)先級(jí)的影響更大。
8. 渲染性能和抓取預(yù)算：雖然 Google 可以有效渲染 JS 較多的頁面，但與靜態(tài) HTML 相比，渲染過程對(duì)你和 Google 來說都是資源密集型的。對(duì)于大型網(wǎng)站（10,000 個(gè)以上唯一且經(jīng)常變化的頁面），這會(huì)影響網(wǎng)站的抓取預(yù)算。優(yōu)化應(yīng)用程序性能并盡量減少不必要的 JS 可以幫助加快渲染過程、提高抓取效率，并有可能讓更多頁面被抓取、渲染和索引。

推薦

1. 擁抱 JavaScript：自由使用 JavaScript 框架，以增強(qiáng)用戶和開發(fā)人員的體驗(yàn)，但要優(yōu)先考慮性能，并遵守 Google 的懶加載最佳實(shí)踐[23]。
2. 錯(cuò)誤處理：在 React 應(yīng)用程序中實(shí)施錯(cuò)誤邊界[24]，以防止因單個(gè)組件錯(cuò)誤而導(dǎo)致整體渲染失敗。
3. 關(guān)鍵SEO元素：對(duì)關(guān)鍵的 SEO 標(biāo)記和重要內(nèi)容使用服務(wù)器端渲染或靜態(tài)生成，以確保它們出現(xiàn)在初始 HTML 響應(yīng)中。
4. 資源管理：確保用于渲染的關(guān)鍵資源[25]（API、JavaScript 文件、CSS 文件）不被 robots.txt 屏蔽。
5. 內(nèi)容更新：對(duì)于需要快速重新索引的內(nèi)容，確保在服務(wù)器渲染的 HTML 中反映更改，而不僅僅是客戶端 JavaScript。考慮采用增量靜態(tài)再生[26]等策略，在內(nèi)容新鮮度與搜索引擎優(yōu)化和性能之間取得平衡。
6. 內(nèi)部鏈接和 URL 結(jié)構(gòu)：創(chuàng)建清晰、合理的內(nèi)部鏈接結(jié)構(gòu)。將重要的導(dǎo)航鏈接作為真正的 HTML 錨標(biāo)簽 (<a href="...">)，而不是基于 JavaScript 的導(dǎo)航。這種方法有助于提高用戶導(dǎo)航和搜索引擎抓取效率，同時(shí)還能減少渲染延遲。
7. 網(wǎng)站地圖：使用并定期更新網(wǎng)站地圖[27]。對(duì)于大型網(wǎng)站或經(jīng)常更新的網(wǎng)站，在 XML 網(wǎng)站地圖中使用 <lastmod> 標(biāo)簽來引導(dǎo) Google 的抓取和索引過程。請(qǐng)記住，只有在發(fā)生重大內(nèi)容更新時(shí)才更新 <lastmod>。
8. 監(jiān)控：使用 Google Search Console 的 URL 檢查工具[28]或富媒體搜索結(jié)果工具[29]來驗(yàn)證 Googlebot 如何查看你的網(wǎng)頁。監(jiān)控抓取統(tǒng)計(jì)數(shù)據(jù)，確保你選擇的渲染策略不會(huì)導(dǎo)致意外問題。

渲染策略

正如我們已經(jīng)探討過的，在谷歌的能力方面，不同的渲染策略[30]存在一些差異：

• 更新 sitemap.xml，即使不能消除不同渲染模式之間的時(shí)間差，也能大大減少發(fā)現(xiàn)時(shí)間。

** 谷歌渲染通常不會(huì)失敗，我們的研究已經(jīng)證明了這一點(diǎn)；如果失敗，通常是由于 robots.txt 中的資源被封或特定的邊緣情況。

雖然存在這些細(xì)微差別，但無論采用哪種渲染策略，谷歌都會(huì)很快發(fā)現(xiàn)并索引你的網(wǎng)站。與其擔(dān)心谷歌渲染過程的特殊適應(yīng)性，不如專注于創(chuàng)建有益于用戶的高性能網(wǎng)絡(luò)應(yīng)用程序。

畢竟，頁面速度仍然是一個(gè)排名因素，因?yàn)楣雀璧捻撁骟w驗(yàn)排名系統(tǒng)會(huì)根據(jù)谷歌的核心Web指標(biāo)[31]來評(píng)估網(wǎng)站的性能。

此外，頁面速度與良好的用戶體驗(yàn)息息相關(guān)--每節(jié)省 100 毫秒的加載時(shí)間，網(wǎng)站轉(zhuǎn)化率就會(huì)提高 8%。更少的用戶跳出你的頁面意味著谷歌將其視為更相關(guān)的頁面。性能決定一切，毫秒至關(guān)重要。

本文譯自：https://vercel.com/blog/how-google-handles-javascript-throughout-the-indexing-process

Reference

[1]MERJ: https://merj.com/

[2]nextjs.org: http://nextjs.org/

[3]monogram.io: http://monogram.io/

[4]basement.io: http://basement.io/

[5]邊緣中間件: https://vercel.com/docs/functions/edge-middleware

[6]輕量級(jí) JavaScript 庫: https://github.com/merj/wrm-research-vercel

[7]nextjs.org: http://nextjs.org/

[8]Next.js.org: http://next.js.org/

[9]nextjs.org: http://nextjs.org/

[10]nextjs.org: http://nextjs.org/

[11]Next.js App Router: https://nextjs.org/docs/app

[12]RSC: https://vercel.com/blog/understanding-react-server-components?nxtPslug=understanding-react-server-components

[13]nextjs.org: http://nextjs.org/

[14]流式傳輸不會(huì)對(duì) SEO 產(chǎn)生不利影響: https://vercel.com/guides/does-streaming-affect-seo

[15]nextjs.org: http://nextjs.org/

[16]nextjs.org: http://nextjs.org/

[17]nextjs.org: http://nextjs.org/

[18]nextjs.org: http://nextjs.org/

[19]nextjs.org: http://nextjs.org/

[20]nextjs.org: http://nextjs.org/

[21]nextjs.org: http://nextjs.org/

[22]2Fwebsite.com: http://2Fwebsite.com

[23]Google 的懶加載最佳實(shí)踐: https://developers.google.com/search/docs/crawling-indexing/javascript/lazy-loading

[24]錯(cuò)誤邊界: https://react.dev/reference/react/Component#catching-rendering-errors-with-an-error-boundary

[25]用于渲染的關(guān)鍵資源: https://merj.com/blog/managing-webpages-resources-for-efficient-crawling-and-rendering

[26]增量靜態(tài)再生: https://vercel.com/docs/incremental-static-regeneration#differences-between-isr-and-cache-control-headers

[27]使用并定期更新網(wǎng)站地圖: https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview

[28]URL 檢查工具: https://support.google.com/webmasters/answer/9012289?hl=en

[29]富媒體搜索結(jié)果工具: https://search.google.com/test/rich-results

[30]渲染策略: https://vercel.com/blog/how-to-choose-the-best-rendering-strategy-for-your-app

[31]核心Web指標(biāo): https://developers.google.com/search/docs/appearance/core-web-vitals