• 主頁
  • 文章
  • SEO
  • Googlebot 可以讀取 JavaScript – SEO 應該如何反應？

Googlebot 可以讀取 JavaScript – SEO 應該如何反應？

已發表: 2017-12-11

傳統上，搜索引擎只讀取和呈現網站的 HTML 代碼。 這意味著優化 HTML 代碼是 SEO 必須關注的。 如果 Googlebot 現在也能夠抓取和索引 JavaScript，這對搜索引擎優化意味著什麼？ 我們請了幾位行業專家來找出答案。

blog_cover_javascript-550x400

Googlebot 和 JavaScript：專家怎麼說

為了獲得有關 Googlebot 和 JavaScript 主題的一系列觀點，我們向專家詢問了以下問題：

  • 谷歌表示，Googlebot 可以抓取基於 JavaScript 的網站——您認為 SEO 面臨哪些挑戰和機遇？
  • 如果有人計劃重新啟動 JavaScript 網站，他們應該考慮哪些特定方面？
  • 您預計 Chrome 中的 Web 渲染更新會在效率和準確性方面發生哪些變化？

答案就在這裡。

馬丁陶伯

Marketing Factory GmbH 管理合夥人

馬丁陶伯-200x200 基於 JavaScript 的網站在用戶體驗方面提供了巨大的機會，因為它們使用起來更快、更具交互性。

然而，Googlebot 在解釋 JavaScript 方面仍然存在困難，這意味著開發必須非常乾淨，並且必須與 SEO 部門密切合作，才能避免不愉快的意外。

多米尼克·沃西克

董事總經理，信託代理人

wojcik_200x200 有機會現在您沒有兩個獨立的編程世界（例如轉義片段），讓您專注於乾淨的代碼和乾淨的 Web 環境。 只要開發人員考慮漸進式增強並相應地開發他們的網絡應用程序，谷歌應該能夠應付得很好。

然而，隱藏的挑戰也存在。 使用的是哪個框架？ 會有客戶端渲染還是可以實現服務器端渲染？ 甚至有可能實現同構 JavaScript 嗎？ JavaScript 是在內部實現還是在外部實現？ 作為 SEO，我們將不得不做大量的測試並嘗試不同的事情，以確保谷歌按照我們的意願索引和加權我們的頁面。

在重新啟動之前，應仔細決定要使用的框架。 應同時考慮可抓取性和性能。 理想情況下，如果正在使用客戶端渲染，則應創建一個測試環境，以便可以從外部測試當前開發。 也就是說，我強烈建議也使用服務器端渲染。 這會影響服務器性能，但應將風險降至最低。 最重要的是，您真的必須測試、測試和測試，使用 fetch & render 來查看 Googlebot 發現、索引和抓取的內容。

如果 Google 最終確實切換到了高於 V49 的 Chrome 版本，那麼我們可以將 headless Chrome 與 Rendertron 之類的東西結合使用來創建測試環境，讓我們模擬類似於 Googlebot 的設置。 這將有助於我們更好地了解 Google 可以如何解釋以及解釋什麼。 這將使我們 SEO 的事情變得更容易

巴托什·戈拉爾維茨

Elephate 聯合創始人兼 SEO 負責人

在 2017 年 11 月的 Searchmetrics 峰會上，來自 Elephate 的 Bartosz Goralwicz 談到了 Googlebot 和 JavaScript 之間的關係：

斯蒂芬·齊施

Trust Agents 創始人兼董事總經理

stephan-cyzsch-200

我們不希望 SEO（或代理機構）聽到人們說：“順便說一下，我們很快就會切換到 JavaScript。 在 SEO 方面我們有什麼需要考慮的嗎？ 不應該，應該有嗎？ 但是，如果您能在我們週一使用新網站之前快速瀏覽一下，那就太好了。” 這種情況將不可避免地以徹底的混亂告終。 Bartosz [在上面的視頻中] 對 JavaScript 和 SEO 主題進行了精彩的介紹。

除了詢問 Google 可以呈現什麼之外，SEO 還應該在重新啟動網站時查看機器人可以看到的內容，並確定與舊網站的不同之處。 我最近處理了一個網站，其中完整的內部鏈接系統在 JavaScript 重新啟動後被搞砸了，因為舊網站的鏈接邏輯沒有被繼承。 還有hreflang問題。 因此，必須使用所需的“SEO 功能”清單。 此外，您應該詢問 JavaScript 渲染對您的使用真正意味著什麼：他們使用什麼樣的硬件來訪問您的網站以及這將如何影響加載時間？ 有關此主題的更多信息，可以推薦 Addy Osmani 的這篇文章。

塞巴斯蒂安·阿德勒

搜索引擎優化顧問，leap.de

配置文件-seb-200 即使爬取 JavaScript 的能力有所提高，Google 也會更喜歡純 HTML 內容，因為它佔用的資源更少。 問題不在於 Google 是否可以讀取和渲染 JS，而在於您是否可以並且想要將部分工作從 Google 手中拿走。 如果我的內容可以在沒有 JS 的情況下很好地閱讀、運行和加載，那對我來說還是更好的。

渲染能力始終取決於其背後的技術，正如 Bartosz 所說（尊重他在實驗和研究中付出的所有努力！），如果您要充分利用該技術，就必須充分了解它. 這裡的絕佳機會是通過以 HTML 形式提供重要內容並僅按預期使用 JS 來最大程度地降低風險：用於附加功能。 如果你完全致力於 JavaScript，最大的困難是發現錯誤。

重新啟動頁面時，請確保您想要排名的內容在沒有 JavaScript 的情況下工作。 這不僅包括主要內容，還包括導航元素。 停用 JS 後，許多頁面沒有菜單。 不包括每一個花哨的功能，而是詢問您的業務和目標受眾是否真的需要某個功能是有意義的。 如果某個功能不起作用，會有什麼影響？ 然後進行相關測試。

除了我不希望 Google 能很好地向網站管理員傳達網絡渲染更新這一事實之外，我預計將發生變化的主要事情將是對錯誤的敏感性。 Chrome 和框架開發得非常快，隨著新版本的推出，RWS 很可能會出現新的錯誤。

有些事情肯定會處理得更快或更乾淨。 但主要問題保持不變。 無法解釋錯誤纏身的代碼（從正在使用的引擎的角度來看）。 我們必須找出引擎如何解釋我們的代碼。 在開發過程中，這改變了我們必須用於調試的工具。 但是，如果您擁有最重要的資產作為快速加載 HTML（等）文件，那麼您不必擔心——您可以專注於適當的 SEO 工作。

比約恩·貝絲

Searchmetrics 專業服務總監

bjoern-in-circle2_200x200

我們必須區分抓取和索引。 Google 可以抓取 JavaScript，但它比抓取純 HTML 需要更多的資源。 對於在 Web 呈現服務 (WRS) 的幫助下呈現從爬蟲接收到的鏈接 (URL) 的索引器來說，問題更大，其方式類似於 Search Console 中的 Fetch & Render。 為此，Google 使用了自己的 Chrome 瀏覽器（版本 41）。 在瀏覽器的幫助下，它嘗試創建一個文檔對像模型 (DOM) 並以與在瀏覽器中顯示相同的方式解釋頁面。 這可能會導致問題，例如穀歌（如 Distilled 和 Bartosz Goralewicz 運行的測試所示）無法處理代碼中的問題，或者在渲染時出現其他大問題，因此谷歌在五秒後停止在頁面中渲染. 這在 Screaming Frog 進行的測試中得到了證明。

基本上，JavaScript 使抓取和索引變得更加複雜，並在兩者之間建立了一種非常低效的關係。 如果 SEO 對您很重要，您應該始終確保機器人可以盡可能快速有效地閱讀您的頁面。

在從基於 HTML 的網站重新啟動到基於 JavaScript 的框架或庫之前，您應該確保包含服務端渲染。 例如，React 自帶了自己的解決方案，稱為 renderToString。 這使用了一個獨立於瀏覽器的 DOM 接口，該接口在服務器上呈現 JavaScript，創建 DOM 並將其發送到機器人。 AngularJS 使用 Angular Universal。 這向客戶端證明了所有重要的預渲染 HTML。 然後，客戶端會根據需要獲取 JavaScript。 但是，您也可以在服務器上使用無頭 Chrome 並將預渲染的 HTML 發送到機器人。

最重要的是，我希望 Chrome 59 能夠提供更快、更高效的渲染，從而實現與純 HTML 相媲美的性能。 只有測試才能判斷這是否真的發生。

在泥濘中爬行：評估您網站的健康狀況

使用站點結構優化分析 HTML 和 JavaScript，包括現在使用 Searchmetrics 的 JavaScript 爬蟲！ 您的好處：

  • 爬取所有相關的 JavaScript 框架，包括 Angular 和 React
  • 通過技術問題的優先列表提高網站性能
  • 比較使用和不使用 JavaScript 爬取的爬取情況

閱讀有關我們的 JavaScript 抓取的更多信息

你覺得怎麼樣？

這就是這五位專家的想法，但是我們有更多的專家閱讀這個博客。 那麼你對 JavaScript 有什麼看法呢？ 您是否已經對您的網站進行了更改？ 您是否已經在測試中發現了一些有趣的東西？