原文：https://vercel.com/blog/how..

原標(biāo)題：How Google handles JavaScript throughout the indexing process

作者：Giacomo Zecchini 等

MERJ 和 Vercel 的研究通過(guò)經(jīng)驗(yàn)證據(jù)揭開了 Google 渲染的神秘面紗。

了解搜索引擎如何抓取、呈現(xiàn)和索引網(wǎng)頁(yè)對(duì)于優(yōu)化搜索引擎的網(wǎng)站至關(guān)重要。多年來(lái)，隨著 Google 等搜索引擎改變其流程，很難跟蹤哪些有效，哪些無(wú)效，尤其是對(duì)于客戶端 JavaScript。

我們注意到，一些舊的理念仍然存在，并使社區(qū)對(duì)應(yīng)用程序SEO的最佳實(shí)踐不確定。

1. “Google 無(wú)法呈現(xiàn)客戶端 JavaScript?！?/p>

2. “Google 以不同的方式對(duì)待 JavaScript 頁(yè)面?！?/p>

3. “渲染隊(duì)列和時(shí)間對(duì) SEO 有重大影響?！?/p>

4. “大量使用 JavaScript 的網(wǎng)站的頁(yè)面發(fā)現(xiàn)速度較慢?！?/p>

為了解決這些理念，我們與領(lǐng)先的 SEO 和數(shù)據(jù)工程咨詢公司 MERJ 合作，對(duì) Google 的抓取行為進(jìn)行了新的實(shí)驗(yàn)。我們分析了各個(gè)網(wǎng)站上超過(guò) 100,000 次 Googlebot 抓取，以測(cè)試和驗(yàn)證 Google 的 SEO 功能。

Google 渲染能力的演變

多年來(lái)，Google 抓取和索引網(wǎng)絡(luò)內(nèi)容的能力發(fā)生了重大變化?？吹竭@種演變對(duì)于了解現(xiàn)代 Web 應(yīng)用程序的 SEO 的當(dāng)前狀態(tài)非常重要。

2009 年之前：有限的 JavaScript 支持

在搜索的早期，Google 主要索引靜態(tài) HTML 內(nèi)容。JavaScript 生成的內(nèi)容對(duì)搜索引擎來(lái)說(shuō)基本上是不可見的，導(dǎo)致靜態(tài) HTML 被廣泛用于 SEO 目的。

2009–2015：AJAX 爬蟲方案

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

2015–2018：早期 JavaScript 渲染

谷歌開始使用無(wú)頭Chrome瀏覽器渲染頁(yè)面，這標(biāo)志著向前邁出了重要的一步。但是，這個(gè)較舊的瀏覽器版本在處理現(xiàn)代 JS 功能方面仍然存在限制。

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

如今，Google 使用最新版本的 Chrome 進(jìn)行渲染，與最新的 Web 技術(shù)保持同步。當(dāng)前系統(tǒng)的關(guān)鍵方面包括：

1. 通用渲染： Google 現(xiàn)在嘗試呈現(xiàn)所有 HTML 頁(yè)面，而不僅僅是一個(gè)子集。

2. 最新的瀏覽器： Googlebot 使用最新的穩(wěn)定版 Chrome/Chromium，支持現(xiàn)代 JS 功能。

3. 無(wú)狀態(tài)渲染： 每個(gè)頁(yè)面呈現(xiàn)都在新的瀏覽器會(huì)話中進(jìn)行，而不保留先前呈現(xiàn)的 cookie 或狀態(tài)。Google 通常不會(huì)點(diǎn)擊頁(yè)面上的項(xiàng)目，例如選項(xiàng)卡式內(nèi)容或 Cookie 橫幅。

4. 偽裝：谷歌禁止向用戶和搜索引擎展示不同的內(nèi)容以操縱排名。避免使用 User-Agent 更改內(nèi)容的代碼。相反，應(yīng)針對(duì) Google 優(yōu)化應(yīng)用的無(wú)狀態(tài)呈現(xiàn)，并通過(guò)有狀態(tài)方法實(shí)現(xiàn)個(gè)性化。

5. 資產(chǎn)緩存： Google 通過(guò)緩存資產(chǎn)來(lái)加快網(wǎng)頁(yè)呈現(xiàn)速度，這對(duì)于共享資源的頁(yè)面和同一頁(yè)面的重復(fù)呈現(xiàn)非常有用。Google 的 Web Rendering Service 不使用 HTTP Cache-Control 標(biāo)頭，而是采用自己的內(nèi)部啟發(fā)式方法來(lái)確定緩存資產(chǎn)何時(shí)仍是最新的，以及何時(shí)需要再次下載。

在更好地了解谷歌的能力之后，讓我們來(lái)看看一些常見的方法論以及它們?nèi)绾斡绊慡EO。

方法論

為了調(diào)查以下誤區(qū)，我們使用 Vercel 的基礎(chǔ)設(shè)施和 MERJ 的 Web 渲染監(jiān)視器 （WRM） 技術(shù)進(jìn)行了一項(xiàng)研究。我們的研究主要針對(duì) nextjs.org，補(bǔ)充數(shù)據(jù)來(lái)自 monogram.io 和 basement.io，時(shí)間跨度為 2024 年 4 月 1 日至 4 月 30 日。

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

我們?cè)谶@些網(wǎng)站上放置了一個(gè)定制的邊緣中間件，以攔截和分析來(lái)自搜索引擎機(jī)器人的請(qǐng)求。這個(gè)中間件使我們能夠：

1. 識(shí)別和跟蹤來(lái)自各種搜索引擎和 AI 爬蟲的請(qǐng)求。（此查詢中未包含任何用戶數(shù)據(jù)。

2. 在機(jī)器人的 HTML 響應(yīng)中注入輕量級(jí) JavaScript 庫(kù)。

JavaScript 庫(kù)在頁(yè)面完成呈現(xiàn)時(shí)觸發(fā)，將數(shù)據(jù)發(fā)送回長(zhǎng)時(shí)間運(yùn)行的服務(wù)器，包括：

• 頁(yè)面 URL。

• 唯一請(qǐng)求標(biāo)識(shí)符（用于將頁(yè)面呈現(xiàn)與常規(guī)服務(wù)器訪問(wèn)日志進(jìn)行匹配）。

• 渲染完成的時(shí)間戳（這是使用服務(wù)器上的 JavaScript 庫(kù)請(qǐng)求接收時(shí)間計(jì)算得出的）。

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

通過(guò)將服務(wù)器訪問(wèn)日志中存在的初始請(qǐng)求與從我們的中間件發(fā)送到外部信標(biāo)服務(wù)器的數(shù)據(jù)進(jìn)行比較，我們可以：

• 確認(rèn)搜索引擎已成功呈現(xiàn)哪些頁(yè)面。

• 計(jì)算初始爬網(wǎng)和完成渲染之間的時(shí)間差。

• 分析如何處理不同類型的內(nèi)容和 URL 的模式。

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

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

我們?nèi)栽谑占嘘P(guān)其他搜索引擎的數(shù)據(jù)，包括 OpenAI 和 Anthropic 等 AI 提供商，并希望將來(lái)更多地談?wù)撐覀兊陌l(fā)現(xiàn)。

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

誤區(qū) 1：“Google 無(wú)法呈現(xiàn) JavaScript 內(nèi)容”

這個(gè)誤區(qū)導(dǎo)致許多開發(fā)人員避免使用 JS 框架或求助于 SEO 的復(fù)雜解決方法。

測(cè)試

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

1. **JS框架兼容性：**我們使用 nextjs.org 的數(shù)據(jù)分析了 Googlebot 與Next.js的交互， 混合使用了靜態(tài)預(yù)渲染、服務(wù)器端渲染和客戶端渲染。

2. 動(dòng)態(tài)內(nèi)容索引：我們檢查nextjs.org 上通過(guò) API 調(diào)用異步加載內(nèi)容的頁(yè)面。這使我們能夠確定 Googlebot 是否可以處理和索引初始 HTML 響應(yīng)中不存在的內(nèi)容。

3. **通過(guò) React 服務(wù)器組件 （RSC） 流式傳輸內(nèi)容：**與上述類似，nextjs.org 的大部分內(nèi)容都是使用 Next.js App Router 和 RSC 構(gòu)建的。我們可以看到 Googlebot 如何處理內(nèi)容并將其編入索引，這些內(nèi)容會(huì)逐步流式傳輸?shù)骄W(wǎng)頁(yè)上。

4. 渲染成功率：我們將服務(wù)器日志中 Googlebot 請(qǐng)求數(shù)量與收到的成功渲染信標(biāo)數(shù)量進(jìn)行了比較。這使我們能夠深入了解完全呈現(xiàn)的抓取頁(yè)面的百分比。

我們的發(fā)現(xiàn)

1. 在 nextjs.org 上分析的超過(guò) 100,000 個(gè) Googlebot 抓取中（不包括狀態(tài)代碼錯(cuò)誤和不可索引的網(wǎng)頁(yè)），100% 的 HTML 網(wǎng)頁(yè)進(jìn)行了整頁(yè)呈現(xiàn)，包括具有復(fù)雜 JS 交互的網(wǎng)頁(yè)。

2. 通過(guò) API 調(diào)用異步加載的所有內(nèi)容均已成功編入索引，這表明 Googlebot 能夠處理動(dòng)態(tài)加載的內(nèi)容。

3. Next.js 是一個(gè)基于 React 的框架，由 Googlebot 完全渲染，確認(rèn)了與現(xiàn)代 JavaScript 框架的兼容性。

4. 通過(guò) RSC 的流媒體內(nèi)容也完全呈現(xiàn)，確認(rèn)流媒體不會(huì)對(duì) SEO 產(chǎn)生不利影響。

5. Google 嘗試呈現(xiàn)它抓取的幾乎所有 HTML 頁(yè)面，而不僅僅是 JavaScript 密集頁(yè)面的一個(gè)子集。

誤區(qū) 2：“Google 以不同的方式對(duì)待 JavaScript 頁(yè)面”

一個(gè)常見的誤解是，谷歌對(duì)大量使用JavaScript的頁(yè)面有一個(gè)單獨(dú)的流程或標(biāo)準(zhǔn)。我們的研究，結(jié)合谷歌的官方聲明，揭穿了這個(gè)謠言。

測(cè)試

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

1. CSS @import 測(cè)試： 我們創(chuàng)建了一個(gè)沒(méi)有 JavaScript 的測(cè)試頁(yè)面，但其中包含一個(gè)@imports第二個(gè) CSS 文件的 CSS 文件（只有在渲染第一個(gè) CSS 文件時(shí)才會(huì)下載并顯示在服務(wù)器日志中）。通過(guò)將此行為與啟用了 JS 的分頁(yè)進(jìn)行比較，我們可以驗(yàn)證 Google 的渲染器在啟用 JS 和未啟用 JS 的情況下處理 CSS 的方式是否有所不同。

2. **狀態(tài)代碼和元標(biāo)記處理：**我們開發(fā)了一個(gè)帶有中間件的Next.js應(yīng)用程序，用于與 Google 一起測(cè)試各種 HTTP 狀態(tài)代碼。我們的分析重點(diǎn)是 Google 如何處理具有不同狀態(tài)代碼（200、304、3xx、4xx、5xx）和帶有 noindex 元標(biāo)記的頁(yè)面。這有助于我們理解在這些場(chǎng)景中是否會(huì)以不同的方式處理大量 JavaScript 的頁(yè)面。

3. JavaScript 復(fù)雜性分析：我們比較了 Google 在 nextjs.org 上不同程度的 JS 復(fù)雜度跨頁(yè)面的渲染行為。這包括具有最小 JS 的頁(yè)面、具有中等交互性的頁(yè)面以及具有大量客戶端渲染的高度動(dòng)態(tài)的頁(yè)面。我們還計(jì)算并比較了初始抓取和完成渲染之間的時(shí)間，以查看更復(fù)雜的 JS 是否會(huì)導(dǎo)致更長(zhǎng)的渲染隊(duì)列或處理時(shí)間。

我們的發(fā)現(xiàn)

1. 我們的 CSS @import測(cè)試證實(shí)，無(wú)論有沒(méi)有 JS，Google 都能成功呈現(xiàn)頁(yè)面。

2. 無(wú)論 JS 內(nèi)容如何，Google 都會(huì)呈現(xiàn)所有 200 狀態(tài) HTML 頁(yè)面。具有 304 狀態(tài)的頁(yè)面使用原始 200 狀態(tài)頁(yè)面的內(nèi)容呈現(xiàn)。不會(huì)呈現(xiàn)包含其他 3xx、4xx 和 5xx 錯(cuò)誤的頁(yè)面。

3. 無(wú)論 JS 內(nèi)容如何，初始 HTML 響應(yīng)中帶有 noindex 元標(biāo)記的頁(yè)面都不會(huì)呈現(xiàn)。客戶端刪除 noindex 標(biāo)簽 對(duì)于 SEO 目的*無(wú)效*;如果頁(yè)面在初始 HTML 響應(yīng)中包含 noindex 標(biāo)簽，則不會(huì)呈現(xiàn)該標(biāo)簽，并且不會(huì)執(zhí)行刪除該標(biāo)簽的 JavaScript。

4. 我們發(fā)現(xiàn) Google 在渲染具有不同 JS 復(fù)雜程度的頁(yè)面方面的成功率沒(méi)有顯著差異。在 nextjs.org 的規(guī)模下，我們還發(fā)現(xiàn) JavaScript 復(fù)雜性和渲染延遲之間沒(méi)有相關(guān)性。但是，在更大的站點(diǎn)上更復(fù)雜的 JS 可能會(huì)影響抓取效率。

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

許多 SEO 從業(yè)者認(rèn)為，由于渲染隊(duì)列，大量使用 JavaScript 的頁(yè)面在索引方面面臨嚴(yán)重的延遲。我們的研究為這一過(guò)程提供了更清晰的視角。

測(cè)試

為了解決渲染隊(duì)列和時(shí)間對(duì) SEO 的影響，我們調(diào)查了：

1. **渲染延遲：**我們研究了 Google 首次抓取頁(yè)面和完成呈現(xiàn)之間的時(shí)間差，使用了 nextjs.org 上超過(guò) 37,000 對(duì)匹配的服務(wù)器信標(biāo)對(duì)的數(shù)據(jù)。

2. **URL 類型：**我們分析了帶查詢字符串和不帶查詢字符串的 URL 的渲染時(shí)間，以及 nextjs.org 的不同部分（例如 /docs、/learn、/showcase）。

3. **頻率模式：**我們研究了 Google 重新呈現(xiàn)頁(yè)面的頻率，以及不同類型內(nèi)容的呈現(xiàn)頻率是否存在模式。

我們的發(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 個(gè)百分位數(shù)的頁(yè)面在初次抓取后的 4 秒內(nèi)呈現(xiàn)，這挑戰(zhàn)了長(zhǎng)“隊(duì)列”的概念。

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

我們還觀察到與 Google 呈現(xiàn)帶有查詢字符串的 URL 的速度相關(guān)的有趣模式 （？param=xyz）：

URL Type	50th Percentile	75th Percentile	90th Percentile
All URLs	10 seconds	26 seconds	~3 hours
URLs without Query String	10 seconds	22 seconds	~2.5 hours
URLs with Query String	13 seconds	31 minutes	~8.5 hours

這些數(shù)據(jù)表明，如果 URL 具有不影響內(nèi)容的查詢字符串，Google 會(huì)以不同的方式對(duì)待 URL。例如，在 nextjs.org 上，具有 ?ref= 參數(shù)的網(wǎng)頁(yè)的呈現(xiàn)延遲時(shí)間更長(zhǎng)，尤其是在較高的百分位數(shù)上。

此外，我們注意到，與更靜態(tài)的部分相比，經(jīng)常更新的部分（如 /docs）的中位數(shù)渲染時(shí)間更短。例如，盡管 /showcase 頁(yè)面經(jīng)常被鏈接，但呈現(xiàn)時(shí)間更長(zhǎng)，這表明 Google 可能會(huì)減慢對(duì)沒(méi)有顯著變化的頁(yè)面的重新呈現(xiàn)速度。

誤區(qū) 4：“JavaScript 密集型網(wǎng)站的頁(yè)面發(fā)現(xiàn)速度較慢”

SEO 社區(qū)的一個(gè)堅(jiān)持信念是，大量使用 JavaScript 的網(wǎng)站，尤其是那些依賴客戶端渲染 （CSR） 的網(wǎng)站，如單頁(yè)應(yīng)用程序 （SPA），會(huì)受到 Google 頁(yè)面發(fā)現(xiàn)速度較慢的影響。我們的研究在這里提供了新的見解。

測(cè)試

1. **分析了不同渲染場(chǎng)景下的鏈接發(fā)現(xiàn)：**我們比較了 Google 在 nextjs.org 上發(fā)現(xiàn)和抓取服務(wù)器呈現(xiàn)、靜態(tài)生成和客戶端呈現(xiàn)的網(wǎng)頁(yè)中鏈接的速度。

2. **已測(cè)試的未呈現(xiàn)的 JavaScript 有效負(fù)載：**我們?cè)?nextjs.org 的 /showcase 頁(yè)面添加了一個(gè)類似于 React 服務(wù)器組件 （RSC） 有效負(fù)載的 JSON 對(duì)象，其中包含指向以前未被發(fā)現(xiàn)的新頁(yè)面的鏈接。這使我們能夠測(cè)試 Google 是否可以在 JavaScript 數(shù)據(jù)中發(fā)現(xiàn)未呈現(xiàn)的鏈接。

3. **比較發(fā)現(xiàn)時(shí)間：**我們監(jiān)控了 Google 發(fā)現(xiàn)并抓取以不同方式鏈接的新網(wǎng)頁(yè)的速度：標(biāo)準(zhǔn) HTML 鏈接、客戶端呈現(xiàn)內(nèi)容中的鏈接以及未呈現(xiàn)的 JavaScript 負(fù)載中的鏈接。

我們發(fā)現(xiàn)

1. 無(wú)論采用何種呈現(xiàn)方法，Google 都能成功發(fā)現(xiàn)并抓取完全呈現(xiàn)網(wǎng)頁(yè)中的鏈接。

2. Google 可以在網(wǎng)頁(yè)上未呈現(xiàn)的 JavaScript 有效負(fù)載中發(fā)現(xiàn)鏈接，例如 React 服務(wù)器組件或類似結(jié)構(gòu)中的鏈接。

3. 在初始 HTML 和呈現(xiàn)的 HTML 中，Google 都會(huì)通過(guò)識(shí)別看起來(lái)像 URL 的字符串來(lái)處理內(nèi)容，并使用當(dāng)前主機(jī)和端口作為相對(duì) URL 的基礎(chǔ)。（Google 在我們的類似 RSC 的負(fù)載中沒(méi)有發(fā)現(xiàn)編碼的 URL（即 https%3A%2F%2Fwebsite.com），這表明其鏈接解析非常嚴(yán)格。

4. 鏈接的來(lái)源和格式（例如，在<a>或嵌入在 JSON 有效負(fù)載中）不會(huì)影響 Google 確定抓取的優(yōu)先級(jí)。無(wú)論在初始抓取過(guò)程中找到 URL 還是在呈現(xiàn)后找到 URL，抓取優(yōu)先級(jí)都保持一致。

5. 雖然 Google 成功地發(fā)現(xiàn)了 CSR 頁(yè)面中的鏈接，但確實(shí)需要首先呈現(xiàn)這些頁(yè)面。服務(wù)器呈現(xiàn)的頁(yè)面或部分預(yù)呈現(xiàn)的頁(yè)面在立即發(fā)現(xiàn)鏈接方面略有優(yōu)勢(shì)。

6. Google 區(qū)分了鏈接發(fā)現(xiàn)和鏈接價(jià)值評(píng)估。對(duì)鏈接對(duì)網(wǎng)站架構(gòu)和抓取優(yōu)先級(jí)的價(jià)值的評(píng)估發(fā)生在整頁(yè)呈現(xiàn)之后。

7. 擁有更新sitemap.xml可以顯著減少（如果不能消除）不同渲染模式之間的發(fā)現(xiàn)時(shí)間差異。

A. 總體影響和建議

我們的研究揭穿了關(guān)于谷歌處理大量JavaScript網(wǎng)站的幾個(gè)常見誤區(qū)。以下是關(guān)鍵要點(diǎn)和可操作的建議：

影響

1. JavaScript 兼容性：Google 可以有效地呈現(xiàn)和索引 JavaScript 內(nèi)容，包括復(fù)雜的 SPA、動(dòng)態(tài)加載的內(nèi)容和流式傳輸內(nèi)容。

2. **呈現(xiàn)奇偶校驗(yàn)：**與靜態(tài) HTML 頁(yè)面相比，Google 處理大量 JavaScript 頁(yè)面的方式?jīng)]有根本區(qū)別。所有頁(yè)面都會(huì)呈現(xiàn)。

3. **渲染隊(duì)列現(xiàn)實(shí)：**雖然存在渲染隊(duì)列，但其影響不如以前想象的那么重要。大多數(shù)頁(yè)面在幾分鐘內(nèi)呈現(xiàn)，而不是幾天或幾周。

4. **頁(yè)面發(fā)現(xiàn)：**以 JavaScript 為主的網(wǎng)站，包括 SPA，在 Google 的頁(yè)面發(fā)現(xiàn)方面并非天生就處于劣勢(shì)。

5. **內(nèi)容時(shí)間：**當(dāng)某些元素（如noindex標(biāo)簽）被添加到頁(yè)面中時(shí)是至關(guān)重要的，因?yàn)镚oogle可能不會(huì)處理客戶端的更改。

6. **鏈接價(jià)值評(píng)估：**Google 區(qū)分了鏈接發(fā)現(xiàn)和鏈接價(jià)值評(píng)估。后者發(fā)生在整頁(yè)呈現(xiàn)之后。

7. **渲染優(yōu)先級(jí)：**Google 的渲染過(guò)程并不是嚴(yán)格意義上的先進(jìn)先出。內(nèi)容新鮮度和更新頻率等因素對(duì)優(yōu)先級(jí)的影響比 JavaScript 的復(fù)雜性更大。

8. **渲染性能和抓取預(yù)算：**雖然 Google 可以有效地渲染 JS 密集的頁(yè)面，但與靜態(tài) HTML 相比，該過(guò)程對(duì)你和 Google 來(lái)說(shuō)都更加耗費(fèi)資源。對(duì)于大型網(wǎng)站（10,000+ 個(gè)獨(dú)特且經(jīng)常更改的頁(yè)面），這可能會(huì)影響網(wǎng)站的抓取預(yù)算。優(yōu)化應(yīng)用程序性能并最小化不必要的 JS 有助于加快渲染過(guò)程，提高抓取效率，并可能允許抓取、呈現(xiàn)和索引更多頁(yè)面。

建議

1. **擁抱 JavaScript：**自由利用 JavaScript 框架來(lái)增強(qiáng)用戶和開發(fā)者的體驗(yàn)，但要優(yōu)先考慮性能并遵守 Google 關(guān)于延遲加載的最佳做法。

2. **錯(cuò)誤處理：**在 React 應(yīng)用程序中實(shí)現(xiàn)錯(cuò)誤邊界，以防止由于單個(gè)組件錯(cuò)誤而導(dǎo)致的渲染失敗。

3. **關(guān)鍵的SEO元素。**對(duì)關(guān)鍵 SEO 標(biāo)簽和重要內(nèi)容使用服務(wù)器端渲染或靜態(tài)生成，以確保它們存在于初始 HTML 響應(yīng)中。

4. **資源管理：**確保用于渲染的關(guān)鍵資源（API、JavaScript 文件、CSS 文件）未被robots.txt阻止。

5. **內(nèi)容更新：**對(duì)于需要快速重新編制索引的內(nèi)容，請(qǐng)確保更改反映在服務(wù)器呈現(xiàn)的 HTML 中，而不僅僅是在客戶端 JavaScript 中?？紤]采用增量靜態(tài)再生等策略，以平衡內(nèi)容新鮮度與 SEO 和性能。

6. **內(nèi)部鏈接和URL結(jié)構(gòu)：**創(chuàng)建一個(gè)清晰、合乎邏輯的內(nèi)部鏈接結(jié)構(gòu)。將重要的導(dǎo)航鏈接實(shí)現(xiàn)為真實(shí)的 HTML 錨標(biāo)記 （<a href="...">） 而不是基于 JavaScript 的導(dǎo)航。這種方法有助于提高用戶導(dǎo)航和搜索引擎抓取效率，同時(shí)有可能減少渲染延遲。

7. 站點(diǎn)地圖：使用并定期更新站點(diǎn)地圖。對(duì)于大型網(wǎng)站或經(jīng)常更新的網(wǎng)站，你可以在 XML 站點(diǎn)地圖中使用該<lastmod>代碼來(lái)指導(dǎo) Google 的抓取和索引編制過(guò)程。請(qǐng)記住，僅在發(fā)生重大內(nèi)容更新時(shí)才<lastmod>更新 。

8. **監(jiān)測(cè)：**使用 Google Search Console 的網(wǎng)址檢查工具或富媒體搜索結(jié)果工具來(lái)驗(yàn)證 Googlebot 如何查看你的網(wǎng)頁(yè)。監(jiān)控抓取統(tǒng)計(jì)信息，確保你選擇的呈現(xiàn)策略不會(huì)導(dǎo)致意外問(wèn)題。

利用新信息向前邁進(jìn)

正如我們所探討的，當(dāng)涉及到 Google 的能力時(shí)，渲染策略之間存在一些差異：

Feature	Static Site Generation (SSG)	Incremental Static Regeneration (ISR)	Server-Side Rendering (SSR)	Client-Side Rendering (CSR)
抓取效率： Google 訪問(wèn)、呈現(xiàn)和檢索網(wǎng)頁(yè)的速度和效率如何。	Excellent	Excellent	Very Good	Poor
**發(fā)現(xiàn)：*查找要抓取的新網(wǎng)址的過(guò)程。	Excellent	Excellent	Excellent	Average
**渲染完整性（錯(cuò)誤、失敗等）：**Google 如何準(zhǔn)確、完整地加載和處理你的網(wǎng)頁(yè)而不會(huì)出錯(cuò)。	Robust	Robust	Robust	Might fail**
**渲染時(shí)間：**Google 完全呈現(xiàn)和處理網(wǎng)頁(yè)需要多長(zhǎng)時(shí)間。	Excellent	Excellent	Excellent	Poor
**鏈路結(jié)構(gòu)評(píng)估：**Google 如何評(píng)估鏈接以了解網(wǎng)站架構(gòu)和頁(yè)面的重要性。	After rendering	After rendering	After rendering	After rendering, links might be missing if rendering fails
**索引：**Google 存儲(chǔ)和整理你網(wǎng)站內(nèi)容的過(guò)程。	Robust	Robust	Robust	Might not be indexed if rendering fails

• 
  

• 擁有更新sitemap.xml可以顯著減少（如果不能消除）不同渲染模式之間的發(fā)現(xiàn)時(shí)間差異。

• ** 正如我們的研究所證明的那樣，在 Google 中呈現(xiàn)通常不會(huì)失敗;當(dāng)它出現(xiàn)時(shí)，通常是由于robots.txt或特定邊緣情況下的資源被阻塞。

這些細(xì)微的差異是存在的，但無(wú)論呈現(xiàn)策略如何，谷歌都會(huì)迅速發(fā)現(xiàn)你的網(wǎng)站并將其編入索引。專注于創(chuàng)建高性能的 Web 應(yīng)用程序，這些應(yīng)用程序使用戶受益更多，而不是擔(dān)心 Google 渲染過(guò)程的特殊便利。

畢竟，**頁(yè)面速度仍然是一個(gè)排名因素，**因?yàn)?Google 的頁(yè)面體驗(yàn)排名系統(tǒng)會(huì)根據(jù) Google 的 Core Web Vitals 指標(biāo)評(píng)估你網(wǎng)站的性能。

此外，頁(yè)面速度與良好的用戶體驗(yàn)息息相關(guān)——每節(jié)省 100 毫秒的加載時(shí)間，網(wǎng)站轉(zhuǎn)化率就會(huì)上升 8%。從你的頁(yè)面上跳出的用戶較少意味著 Google 將其視為更相關(guān)。高性能化合物;毫秒很重要。

更多資源

• Core Web Vitals 如何影響你的 SEO**：**全面概述了 Core Web Vitals （CWV） 如何影響 SEO，解釋了 Google 的頁(yè)面體驗(yàn)排名系統(tǒng)以及字段數(shù)據(jù)（用于排名）和實(shí)驗(yàn)室數(shù)據(jù)（Lighthouse 分?jǐn)?shù)）之間的區(qū)別。

• 如何選擇正確的渲染策略**：**指導(dǎo)開發(fā)者為Web應(yīng)用選擇最優(yōu)渲染策略，講解SSG、ISR、SSR、CSR等各種方法及其使用案例，以及使用Next.js實(shí)現(xiàn)注意事項(xiàng)。

• 前端云的用戶體驗(yàn)**：**解釋 Vercel 的前端云如何通過(guò)結(jié)合高級(jí)緩存策略、邊緣網(wǎng)絡(luò)功能和靈活的渲染選項(xiàng)來(lái)實(shí)現(xiàn)快速、個(gè)性化的 Web 體驗(yàn)，以優(yōu)化用戶體驗(yàn)和開發(fā)人員生產(chǎn)力。

作者：泯瀧
鏈接：https://juejin.cn/post/7402044460925124659
來(lái)源：稀土掘金
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請(qǐng)注明出處。