Vue.js 和 SEO：如何為搜索引擎和機器人優化響應式網站

反應式 JavaScript 框架（例如 React、Vue.js 和 Angular）最近風靡一時，難怪它們因其靈活性、模塊化和易於自動化測試而被越來越多的網站和應用程序使用。

這些框架允許人們在網站或應用程序上實現以前無法想像的新事物，但它們在 SEO 方面的表現如何？ 使用這些框架創建的頁面是否會被 Google 索引？ 由於使用這些框架，所有或大部分頁面呈現都是在 JavaScript 中完成的（並且機器人下載的 HTML 大多是空的），如果您希望您的網站被索引，它們似乎是不可行的搜索引擎，甚至通常被機器人解析。

在本文中，我將主要討論 Vue.js，因為它是我使用最多的框架，並且在主要項目的搜索引擎索引方面我有直接的經驗，但我可以假設大部分我將介紹的內容也適用於其他框架。

問題的一些背景

索引如何工作

為了讓您的網站被 Google 索引，它需要由 Googlebot（一種訪問您的網站並將頁面內容保存到其索引的自動索引軟件）在每個頁面中的鏈接之後進行抓取。 Googlebot 還會在網站中查找特殊的站點地圖 XML 文件，以查找可能無法從您的公共站點正確鏈接的頁面，並接收有關網站中頁面更改頻率和上次更改時間的額外信息。

一點點歷史

直到幾年前（2009 年之前），Google 還用於索引網站 HTML 的內容——不包括所有由 JavaScript 創建的內容。 眾所周知，重要的鏈接和內容不應該由 JavaScript 編寫，因為它不會被谷歌索引，這是常見的 SEO 知識，並且可能會對網站造成懲罰，因為谷歌可能會認為它是“虛假內容”，就好像網站的所有者正在嘗試一樣向用戶展示與向搜索引擎顯示的內容不同的內容，並試圖愚弄後者。

例如，詐騙者將大量對 SEO 友好的內容放在 HTML 中並將其隱藏在 JavaScript 中是非常常見的做法。 谷歌一直警告不要這種做法：

“向 Googlebot 提供與普通用戶看到的內容不同的內容被視為偽裝，並且違反了我們的網站管理員指南。”

你可能會因此受到懲罰。 在某些情況下，你可能會因為在服務器端向不同的用戶代理提供不同的內容而受到懲罰，而且在頁面加載後通過 JavaScript 切換內容也會受到懲罰。 我認為這向我們表明，Google 長期以來一直在為執行 JavaScript 的網站編制索引——至少是為了比較網站的最終 HTML（在 JavaScript 執行之後）和它為索引解析的原始 HTML。 但 Googlebot 並沒有一直執行 JavaScript，而且 Google 也沒有將 JavaScript 生成的內容用於索引目的。

然後，鑑於越來越多地使用 AJAX 在網站上傳遞動態內容，Google 提出了“AJAX 爬蟲方案”來幫助用戶索引基於 AJAX 的網站。 非常複雜； 它基本上要求網站生成包含 AJAX 內容的頁面呈現。 當谷歌請求時，服務器將提供一個頁面版本，其中包含所有（或大部分）內容，這些內容將由 HTML 頁面中包含的 JavaScript 動態生成——預先呈現為內容的HTML 快照。 讓服務器端解決方案提供（用於所有其他目的）意味著在客戶端生成的內容的過程，意味著那些想要擁有一個嚴重依賴於谷歌索引的 JavaScript 的網站的人必須經歷很多技術上的麻煩。

例如，如果 AJAX 讀取的內容來自外部 Web 服務，則必須在服務器端複製相同的 Web 服務調用，並在服務器端生成與客戶端生成的相同 HTML JavaScript——或者至少是一個非常相似的。 這非常複雜，因為在 Node.js 出現之前，它需要在兩種不同的編程語言中至少部分複制相同的渲染邏輯：前端的 JavaScript 和 PHP、Java、Python、Ruby 等。後端。 這被稱為“服務器端渲染”，它可能導致維護地獄：如果您對在前端渲染內容的方式進行了重要更改，則必須在後端複製這些更改。

避免重複邏輯的唯一替代方法是使用執行 JavaScript 的瀏覽器解析您自己的站點，並將最終結果保存到您的服務器，然後將這些結果提供給 Googlebot。 這有點類似於現在所謂的“預渲染”。

Google（使用其 AJAX 抓取方案）還保證您將避免處罰，因為在這種情況下，您向 Googlebot 和用戶提供不同的內容。 然而，自 2015 年以來，谷歌在一篇官方博客文章中反對這種做法，該文章告訴網站管理員以下內容：

“今天，只要您不阻止 Googlebot 抓取您的 JavaScript 或 CSS 文件，我們通常能夠像現代瀏覽器一樣呈現和理解您的網頁。”

這告訴我們的並不是 Googlebot 在索引網頁時突然獲得了執行 JavaScript 的能力，因為我們知道它已經這樣做了很長時間（至少是為了檢查虛假內容和詐騙）。 相反，它告訴我們 JavaScript 執行的結果將被索引並在 SERP 中使用。

這似乎意味著我們不必再擔心向 Google 提供服務器端呈現的 HTML。 但是，我們看到各種可用於 JavaScript 框架的服務器端渲染和預渲染工具，但似乎並非如此。 此外，在與大型項目的 SEO 機構打交道時，預渲染似乎被認為是強制性的。 怎麼會？

Google 如何實際索引使用前端框架創建的頁面？

本實驗

為了查看 Google 在使用前端框架創建的網站中實際索引的內容，我做了一個小實驗。 它並未涵蓋所有用例，但它至少是一種了解更多有關 Google 行為的方法。 我用 Vue.js 構建了一個小型網站，並且不同部分的文本呈現不同。

該網站的內容取自 Infinite Jest Wiki 中 David Foster Wallace 對 Infinite Jest一書的描述（謝謝大家！ ）。 整本書有幾篇介紹性文字，還有一個人物列表和他們的個人傳記：

• 靜態 HTML 中的一些文本，在 Vue.js 主容器之外；
• Vue.js 會立即呈現一些文本，因為它包含在應用程序代碼中已經存在的變量中：它們在組件的data對像中定義；
• #一些文本是Vue.js從data對像中渲染出來的，但是有300ms的延遲；
• 角色 bios 來自一組 rest API，我使用 Sandbox 特意構建了這些 API。 由於我假設 Google 會執行網站的代碼並在一段時間後停止以獲取頁面當前狀態的快照，因此我將每個 Web 服務設置為以增量延遲響應，第一個為 0 毫秒，第二個為 300 毫秒，第三個為 600 毫秒，依此類推，直到 2700 毫秒。

每個角色簡介都被縮短並包含一個指向子頁面的鏈接，該子頁面僅可通過 Vue.js 獲得（URL 由 Vue.js 使用歷史 API 生成），而不是服務器端（如果您調用直接頁面，你沒有得到服務器的響應），檢查那些是否也被索引了。 我假設這些不會被索引，因為它們不是呈現服務器端的正確鏈接，而且谷歌無法直接將用戶引導到這些鏈接。 但我只是想檢查一下。

我將這個小測試站點發佈到我的 Github 頁面並請求索引——看看。

結果

實驗結果（關於首頁）如下：

• 已經在靜態 HTML 內容中的內容被 Google 索引（這很明顯）；
• Vue實時生成的內容總是被谷歌索引；
• 由 Vue 生成，但在 300 毫秒後渲染的內容也會被索引；
• 來自 Web 服務的內容有一些延遲，可能會被編入索引，但並非總是如此。 我檢查了谷歌在不同時刻對頁面的索引，最後插入的內容（幾秒鐘後）有時會被索引，有時卻沒有。 快速呈現的內容在大多數情況下都會被編入索引，即使它來自對外部 Web 服務的異步調用。 這取決於 Google 對每個頁面和網站的渲染預算，這取決於其內部算法，並且可能會根據您網站的排名和 Googlebot 渲染隊列的當前狀態而有很大差異。 因此，您不能依賴來自外部 Web 服務的內容來獲取索引；
• 子頁面（因為它們不能作為直接鏈接訪問）未按預期編入索引。

這個實驗告訴我們什麼？ 基本上，即使來自外部網絡服務，Google 也會對動態生成的內容進行索引，但不能保證如果內容“到達太晚​​”就會被索引。 除了這個實驗，我在其他真實的生產網站上也有過類似的經歷。

競爭性搜索引擎優化

好的，所以內容被索引了，但這個實驗沒有告訴我們的是：內容會被競爭排名嗎？ 與動態生成的網站相比，Google 會更喜歡具有靜態內容的網站嗎？ 這不是一個容易回答的問題。

根據我的經驗，我可以看出動態生成的內容可以在 SERPS 中排名靠前。 我在一家大型汽車公司的新車型網站上工作，推出了一個具有新三級域的新網站。 該網站完全是用 Vue.js 生成的——除了<title>標籤和meta描述之外，靜態 HTML 中的內容很少。

該網站在發布後的頭幾天開始對次要搜索進行排名，SERP 中的文本片段報告了直接來自動態內容的單詞。

在三個月內，它在與該車型相關的大多數搜索中排名第一——這相對容易，因為它託管在屬於汽車製造商的官方域上，並且該域與知名網站有大量鏈接。

但考慮到我們不得不面對負責該項目的 SEO 公司的強烈反對，我認為結果仍然是顯著的。

由於項目的最後期限緊迫且缺乏時間，我們打算在不進行預渲染的情況下發布該網站。

動畫文本

谷歌沒有索引的是大量動畫文本。 我與之合作的一家公司 Rabbit Hole Consulting 的網站包含大量文本動畫，這些動畫是在用戶滾動時執行的，並且需要將文本分成多個不同標籤的塊。

網站主頁中的主要文本不適用於搜索引擎索引，因為它們沒有針對 SEO 進行優化。 它們不是由技術語言製成的，也不使用關鍵字：它們只是為了陪伴用戶進行關於公司的概念之旅。 當用戶進入主頁的各個部分時，文本會動態插入。

網站這些部分中的任何文本都不會被谷歌索引。 為了讓 Google 在 SERP 中顯示一些有意義的內容，我們在聯繫表單下方的頁腳中添加了一些靜態文本，這些內容確實作為 SERP 中頁面內容的一部分顯示。

頁腳中的文本被編入索引並顯示在 SERP 中，即使用戶不會立即看到它，除非他們滾動到頁面底部並單擊“問題”按鈕打開聯繫表單。 這證實了我的觀點，即內容確實會被索引，即使它沒有立即顯示給用戶，只要它很快呈現到 HTML - 而不是按需呈現或在長時間延遲後呈現。

預渲染呢？

那麼，為什麼要對預渲染大驚小怪——無論是在服務器端還是在項目編譯時完成？ 真的有必要嗎？ 雖然一些框架，比如 Nuxt，讓它更容易執行，但它仍然不是野餐，所以選擇是否設置它並不是一個輕鬆的選擇。

我認為這不是強制性的。 如果您希望被 Google 索引的許多內容來自外部 Web 服務，並且在呈現時無法立即使用，並且可能（在某些不幸的情況下）根本不可用，這當然是一項要求，例如，web 服務停機。 如果在 Googlebot 訪問期間您的某些內容到達太慢，則可能無法將其編入索引。 如果 Googlebot 恰好在您對 Web 服務執行維護的時刻為您的頁面編制索引，它可能根本不會索引任何動態內容。

此外，我沒有證據證明靜態內容和動態生成的內容之間的排名差異。 這可能需要另一個實驗。 我認為很有可能，如果內容來自外部網絡服務並且沒有立即加載，它可能會影響谷歌對您網站性能的看法，這是排名的一個非常重要的因素。

推薦閱讀：移動網頁設計如何影響本地搜索（以及如何處理）

其他注意事項

兼容性

直到最近，Googlebot 還使用了一個相當老的 Chromium 版本（Google Chrome 所基於的開源項目），即版本 41。這意味著 Google 無法正確呈現一些最近的 JavaScript 或 CSS 功能（例如 IntersectionObserver、 ES6 語法，等等）。

谷歌最近宣布，它現在正在 Googlebot 中運行最新版本的 Chromium（在撰寫本文時為 74），並且該版本將定期更新。 Google 運行 Chromium 41 的事實可能對那些決定無視與 IE11 和其他舊瀏覽器的兼容性的網站產生重大影響。

您可以在此處查看 Chromium 41 和 Chromium 74 對功能支持的比較，但是，如果您的網站已經在填充缺失的功能以保持與舊瀏覽器的兼容性，那麼應該沒有問題。

始終使用 polyfill ，因為您永遠不知道哪個瀏覽器缺少對您認為司空見慣的功能的支持。 例如，Safari 直到 2019 年 3 月發布的 12.1 版才支持像 IntersectionObserver 這樣的主要且非常有用的新功能。

JavaScript 錯誤

如果您依靠 Googlebot 執行 JavaScript 來呈現重要內容，則必須不惜一切代價避免可能阻止內容呈現的主要 JavaScript 錯誤。 雖然機器人可能會解析和索引並非完全有效的 HTML（儘管在任何站點上總是最好有有效的 HTML！），但如果存在阻止加載某些內容的 JavaScript 錯誤，那麼 Google 將無法索引那個內容。

在任何情況下，如果您依賴 JavaScript 向最終用戶呈現重要內容，那麼您很可能已經進行了大量的單元測試來檢查任何類型的阻塞錯誤。 但是請記住，Javascript 錯誤可能來自不可預測的情況，例如，在 API 響應錯誤處理不當的情況下。

最好有一些實時錯誤檢查軟件（例如 Sentry 或 LogRocket），它會提醒您在單元或手動測試期間可能未選擇的任何邊緣情況錯誤。 這增加了依靠 JavaScript 獲取 SEO 內容的複雜性。

其他搜索引擎

其他搜索引擎在動態內容方面的表現不如穀歌。 Bing 似乎根本沒有索引動態內容，DuckDuckGo 或百度也沒有。 可能這些搜索引擎缺乏谷歌所擁有的資源和計算能力。

使用無頭瀏覽器解析頁面並執行幾秒鐘的 JavaScript 來解析呈現的內容肯定比僅僅讀取純 HTML 更耗費資源。 或者這些搜索引擎可能出於其他原因選擇不掃描動態內容。 不管是什麼原因，如果您的項目需要支持這些搜索引擎中的任何一個，您需要設置預渲染。

注意：要獲取有關其他搜索引擎渲染能力的更多信息，您可以查看 Bartosz Goralewicz 的這篇文章。 它有點舊，但根據我的經驗，它仍然有效。

其他機器人

請記住，您的網站也會被其他機器人訪問。 最重要的例子是 Twitter、Facebook 和其他社交媒體機器人，它們需要獲取有關您的頁面的元信息，以便在用戶鏈接頁面時顯示頁面的預覽。 這些機器人不會索引動態內容，只會顯示它們在靜態 HTML 中找到的元信息。 這導致我們進入下一個考慮。

子頁面

如果您的網站是所謂的“單頁網站”，並且所有相關內容都位於一個主 HTML 中，那麼您可以毫無問題地將該內容編入 Google 索引。 但是，如果您需要 Google 索引並顯示網站上的任何二級頁面，您仍然需要為每個二級頁面創建靜態 HTML — 即使您依賴 JavaScript 框架檢查當前 URL 並提供相關內容以放置在那個頁面中。 在這種情況下，我的建議是創建至少提供正確title標籤和元描述/信息的服務器端（或靜態）頁面。

結論

我在研究這篇文章時得出的結論如下：

1. 如果您只針對 Google，則不必使用預渲染來讓您的網站完全編入索引，但是：
2. 對於需要編制索引的內容，您不應依賴第三方 Web 服務，尤其是在他們沒有快速回复的情況下。
3. 您通過 Vue.js 渲染立即插入 HTML的內容確實會被編入索引，但您不應使用動畫文本或在用戶操作（如滾動等）後插入 DOM 中的文本。
4. 確保您測試 JavaScript 錯誤，因為它們可能導致整個頁面/部分沒有被索引，或者您的網站根本沒有被索引。
5. 如果您的網站有多個頁面，您仍然需要一些邏輯來創建頁面，這些頁面雖然依賴與主頁相同的前端呈現系統，但可以被 Google 索引為單獨的 URL。
6. 如果您需要在不同頁面之間為社交媒體提供不同的描述和預覽圖像，您也需要在服務器端或通過為每個 URL 編譯靜態頁面來解決這個問題。
7. 如果您需要您的網站在Google 以外的搜索引擎上運行，您肯定需要進行某種預渲染。