診斷JavaScript動力網(wǎng)站技術(shù)審查的優(yōu)先事項
撰稿人Maria Cieslak深入研究了JavaScript以及與之相關的一些混亂，并編寫了一份詳細的清單，您可以將其作為深入分析的起點。
在過去的20年中，Google的搜索引擎發(fā)生了很大變化。如果我們從整體上看技術(shù)和網(wǎng)絡開發(fā)，我們可以看到變化的步伐非常壯觀。
1998年的這個網(wǎng)站提供的信息豐富，診斷JavaScript動力網(wǎng)站技術(shù)審查的優(yōu)先事項，但不是非常有吸引力或易于使用：
現(xiàn)代網(wǎng)站不僅看起來好多了，而且還配備了強大的功能，例如推送通知，部分離線工作和眨眼之間加載。
但是如果我們想要準確，我們應該使用術(shù)語“應用程序”而不是“網(wǎng)站”，因為網(wǎng)站是互動的，動態(tài)的并且使用JavaScript構(gòu)建。
JavaScript作為游戲改變者
Google最長時間無法執(zhí)行JavaScript，但到2015年該公司在處理JavaScript方面邁出了巨大的一步。
需要強調(diào)的是，搜索引擎的發(fā)展速度遠遠低于網(wǎng)絡開發(fā)領域的發(fā)展速度，這可能是谷歌仍然是唯一可以執(zhí)行JavaScript的搜索引擎的原因。
一開始，當萬維網(wǎng)由僅由靜態(tài)超文本標記語言（HTML）構(gòu)成的網(wǎng)站構(gòu)建時，Google有一項簡單的任務來完成：
向服務器發(fā)出請求→獲取靜態(tài)HTML響應→為頁面編制索引
我知道這是對這個過程的超簡單描述，但是我想要展示處理網(wǎng)站與當今處理網(wǎng)站之間的差異。
當開發(fā)人員開始使用JavaScript（JS）在網(wǎng)站上添加交互性時，問題就出現(xiàn)了，然后當Javascript用于創(chuàng)建整個網(wǎng)站時，對JavaScript的依賴性變得更大時，問題就會加劇。
JavaScript應用程序和網(wǎng)站是Google的挑戰(zhàn)，因為在向服務器發(fā)送初始請求后，Googlebot會收到一個空的或幾乎為空的HTML文件。JS執(zhí)行后會添加內(nèi)容，圖片和鏈接。
Google通過嘗試渲染他們訪問的幾乎所有頁面來解決這個問題。所以現(xiàn)在，這個過程看起來或多或少像這樣：
向服務器發(fā)出請求→獲取靜態(tài)HTML響應→將其發(fā)送到索引器→渲染頁面→
索引并將提取的鏈接發(fā)送到Googlebot→Googlebot可以抓取下一頁。
由于JavaScript的執(zhí)行在抓取，渲染和索引過程中增加了很多低效率和延遲，因為：
- Googlebot的抓取速度變慢了。它沒有在JS網(wǎng)站的源代碼中看到超鏈接，所以它需要等待索引器呈現(xiàn)頁面，然后將提取的URL發(fā)回。
- 執(zhí)行JavaScript需要很多資源。甚至對于Google的數(shù)據(jù)中心來說，這也令人筋疲力盡。
盡管存在這些障礙，但我們需要為開發(fā)動態(tài)JS應用程序的繁榮做好準備，因為對React，Vue.js或Angular等開放源代碼框架的興趣持續(xù)高漲。越來越多的網(wǎng)站將使用JavaScript構(gòu)建。所以作為優(yōu)化，我們需要能夠發(fā)現(xiàn)使用它的網(wǎng)站上的問題。
正確的做法
在我們開始深入研究JavaScript以及與之相關的一些混亂之前，讓我們看看三個方面，這些方面將調(diào)整我們分析網(wǎng)站的方法：
A.問題的嚴重程度如何？
我們需要理解并明確界定使用JavaScript構(gòu)建的網(wǎng)站（應用程序），例如單頁應用程序（SPA）和JavaScript的部分依賴關系。以下是一些可能的場景以及如何說明使用SPA構(gòu)建的內(nèi)容以及部分依賴關系：
- 沒有JavaScript依賴關系。 訪問我們的網(wǎng)站并在瀏覽器中關閉JS - 沒有任何變化。
- 部分JS依賴關系。 訪問Angular.io網(wǎng)站并在瀏覽器中關閉JS - 主導航不起作用（但鏈接在文檔對象模型[DOM]中可用，稍后我將會討論）。
- 有意義的JS依賴關系。 訪問AutoZone并關閉JS - 主導航可能不起作用，并且鏈接可能在DOM中不可用。
- 完整的JS依賴關系。 訪問YouTube，關閉JS并注意所有內(nèi)容消失！
正如您可能猜到的那樣，如果您對JavaScript有部分依賴關系，則可以解決的問題更少。
B.網(wǎng)站建在哪里？
靜態(tài)HTML網(wǎng)站建立在您的服務器上。在Googlebot（以及用戶）發(fā)出初始請求后，它會收到一個靜態(tài)頁面作為響應。
動態(tài)Web應用程序（DWA）內(nèi)置在瀏覽器中，因此在初始請求后，我們會收到一個空的或幾乎空的HTML文件，并且使用JavaScript以異步方式加載內(nèi)容。縱觀全局，我們可以假設客戶端渲染是JS和優(yōu)化（優(yōu)化）問題時真正的惡棍。
C.谷歌有什么限制？
前段時間，Google透露了它如何渲染網(wǎng)站：共享網(wǎng)絡渲染服務（WRS）負責渲染頁面。在他們身后是一個基于Chrome 41的無頭瀏覽器，它于2015年推出，所以它有點過時了。Google使用三年前的瀏覽器對于呈現(xiàn)現(xiàn)代Web應用程序具有實際影響，因為它不支持現(xiàn)代應用程序使用的所有當前功能。
Google的工程師Eric Bidelman證實他們知道Google與JS的限制。根據(jù)非官方聲明，我們預計Chrome 41將在2018年底更新為更新版本。
要深入了解支持和不支持的內(nèi)容，請訪問Caniuse.com，并將Chrome 41與最新版本的Chrome進行比較。名單很長：
處理資源
超時是使JS和優(yōu)化難以匹配的下一件事。
JavaScript應用通常非常繁重，Google資源有限。想象一下，在JavaScript的情況下，Google需要渲染每個頁面才能看到內(nèi)容。下面的例子顯示了多重的JS執(zhí)行。
如果你有一個JS文件和一個大小相同的圖像文件，你會發(fā)現(xiàn)解析大約需要2秒，而執(zhí)行JavaScript大約需要1.5秒。
Google需要合理管理其處理資源，因為它需要處理大量的數(shù)據(jù)。萬維網(wǎng)由10億多個網(wǎng)站組成，并且每天都在增長。下面的圖表顯示，過去五年中，桌面版網(wǎng)頁的中值大小幾乎增加了100％。移動版網(wǎng)站的適當指標增加了250％！
JavaScript網(wǎng)站的自然結(jié)果是對這些網(wǎng)站的抓取，索引和最終排名的延遲。
準備和有用的資源
從事技術(shù)優(yōu)化的優(yōu)化們需要注意細節(jié)。在JavaScript網(wǎng)站的情況下，我們需要為需要解決的棘手問題做好準備，并且我們必須了解我們不能總是依靠共同的和眾所周知的規(guī)則。
Google知道優(yōu)化和開發(fā)者在理解搜索行為方面存在問題，他們正試圖幫助我們。以下是來自Google的一些資源，您應該遵循并檢查以幫助解決您可能遇到的任何JS問題：
- 網(wǎng)站趨勢分析師約翰穆勒。
- 網(wǎng)站管理員趨勢分析師Gary IIIyes
- 工程師Eric BideIman
- Google搜索論壇中的JavaScript網(wǎng)站。
- 視頻：與John Mueller合作的“ 現(xiàn)代網(wǎng)站的 優(yōu)化最佳實踐和要求 ”。
- 視頻片段：來自Google I / O 2018的“提供適合搜索的JavaScript網(wǎng)站”。
診斷JavaScript引發(fā)的網(wǎng)站問題
現(xiàn)在我們知道了Google的限制，讓我們嘗試在JavaScript網(wǎng)站上發(fā)現(xiàn)一些問題并尋找解決方法。
Google看到了什么？
三年前，谷歌宣布它能夠呈現(xiàn)和理解像現(xiàn)代瀏覽器這樣的網(wǎng)站。但是，如果我們查看關于呈現(xiàn)JS網(wǎng)站的文章和評論，您會注意到它們包含許多警示詞，如“可能”，“一般”和“并非總是”。
這應該強調(diào)一個事實，即雖然Google在JS執(zhí)行中越來越好，但它仍然有很大的改進空間。
源代碼與DOM
源代碼是Googlebot在進入頁面后看到的內(nèi)容。這是沒有將JS集成到代碼中的原始HTML。請注意一個重要的事實，即Googlebot不會呈現(xiàn)網(wǎng)頁。
Googlebot是一個抓取工具，所以它的工作是瀏覽頁面，從源代碼中提取元素并將它們發(fā)送給索引器。文檔對象模型（DOM）是網(wǎng)站的渲染版本，它意味著原始HTML被JavaScript改變了，結(jié)構(gòu)化和組織化。
“檢查元素”顯示文檔對象模型。渲染是通過Web Rendering服務完成的，該服務是Google Indexer的一部分。請牢記以下幾點：
- 抓取時將原始HTML考慮在內(nèi)。
- 索引時會考慮DOM。
JavaScript網(wǎng)站以兩種方式編入索引，這使得索引的整個過程完全不同：
- 第一波：Google僅提取元數(shù)據(jù)并根據(jù)此信息為網(wǎng)址編制索引。
- 第二次浪潮：如果Google有足夠的資源，它會呈現(xiàn)頁面以查看內(nèi)容。它可以重新編制頁面并加入這兩個數(shù)據(jù)源。
請記住，在第二次索引浪潮中，Google不會更新最初索引的元素（如果它們被JavaScript更改）。如果您使用JavaScript添加rel =“canonical”標記，Google不會收到它。
然而，最近John Mueller表示，如果Google在頁面呈現(xiàn)過程中陷入困境，則可能會使用原始HTML進行索引。
即使您看到特定的網(wǎng)址已編入索引，但并不表示索引器已發(fā)現(xiàn)該內(nèi)容。我知道這可能會讓人困惑，所以這里有一個小小的備忘單：
- 要查看發(fā)送到Googlebot的HTML，請轉(zhuǎn)到Google Search Console并使用提取和呈現(xiàn)工具。在這里你可以訪問原始的HTTP響應。
- 要查看頁面的渲染版本，還可以使用“提取和渲染”工具。
- 要查看桌面設備的WRS構(gòu)建的DOM ，請使用Rich Results Test。對于移動設備，請使用Moblie-Friendly測試。
谷歌正式確認，我們可以依靠這兩種方法來檢查谷歌“看到”網(wǎng)站的方式：
和
將源代碼與DOM進行比較
現(xiàn)在，該分析代碼和DOM了。
在第一步中，根據(jù)可索引性對它們進行比較，并檢查源代碼是否包含：
- 元機器人指令，如索引規(guī)則。
- Canonical標簽。
- Hreflang標簽。
- 元數(shù)據(jù)。
然后看看它們是否符合網(wǎng)站的渲染版本。
要發(fā)現(xiàn)差異，您可以使用Diff Checker這樣的工具，它可以比較兩個文件之間的文本差異。
使用Diff Checker，從Google Search Console獲取原始超文本傳輸協(xié)議（HTTP）響應，并將其與上面第3點提到的工具（豐富結(jié)果測試和移動友好測試）中的DOM進行比較。
JavaScript可能會修改某些元素，Google可能會遵循兩條不同的說明。
Googlebot不會滾動
在查看DOM時，還需要驗證依賴于單擊，滾動和填充表單等事件的元素。
JavaScript允許在用戶交互之后加載額外的內(nèi)容，鏈接和圖像。Googlebot不會滾動或點擊，因此如果某件事需要顯示某項操作，Google就不會發(fā)現(xiàn)該操作。
兩波索引及其后果
回到我之前提到的那兩個浪潮，Google承認只有在第一波索引中才會考慮到元數(shù)據(jù)。如果源代碼不包含機器人指令，hreflang或標準代碼，則可能不會被Google發(fā)現(xiàn)。
Google如何看待您的網(wǎng)站？
要查看Google如何查看網(wǎng)站的呈現(xiàn)版本，請轉(zhuǎn)到Google Search Console中的Google抓取方式工具，并提供您要檢查的網(wǎng)址并點擊抓取和呈現(xiàn)。
對于復雜或動態(tài)的網(wǎng)站，僅僅驗證網(wǎng)站的所有元素是否在他們的位置是不夠的。
谷歌正式表示Chrome 41支持獲取和渲染工具，因此最好下載并安裝該瀏覽器的完全版本。
一旦安裝在個人計算機（PC）上，您可以與網(wǎng)站進行一點點交互，導航到其他部分并檢查由JavaScript觸發(fā)的控制臺中的錯誤。Mobile-Friendly測試中的一項新功能還可以在JavaScript控制臺中查看JavaScript的錯誤。
我想提一些常見的和微不足道的錯誤來避免：
- 在診斷呈現(xiàn)富含JavaScript的網(wǎng)站問題時，切勿查看Google中的緩存。它沒有提供有意義的信息，因為緩存顯示由您的瀏覽器呈現(xiàn)的Googlebot看到的RAW HTML。JS網(wǎng)站的源代碼只包含幾行代碼，一些指向腳本的超鏈接; JavaScript執(zhí)行后加載真實內(nèi)容。
- 不要在robots.txt中阻止JavaScript資源; 它阻止了正確的渲染（我知道這很明顯，但它仍然會發(fā)生）。
內(nèi)部鏈接
內(nèi)部鏈接是使網(wǎng)站可抓取的唯一途徑。由于JavaScript網(wǎng)站的源代碼（一般而言）不包含鏈接，因此整個爬網(wǎng)過程被延遲。Googlebot需要等待Indexer呈現(xiàn)網(wǎng)頁并將發(fā)現(xiàn)的鏈接發(fā)回。
診斷JS網(wǎng)站的關鍵要素是檢查鏈接是否放置在DOM中。源代碼不必包含鏈接，但如果DOM沒有鏈接，鏈接將不會被發(fā)現(xiàn)。如果主導航是使用JavaScript構(gòu)建的，這可能會有很大的影響。
分析超級菜單時要小心。有時候，它們充滿了對于優(yōu)化并不總是有益的奇特功能。以下是John Mueller關于如何查看導航是否適用于Google的提示：
還要注意“加載更多”分頁和無限滾動。這些元素也很棘手。它們以平穩(wěn)的方式加載額外的內(nèi)容，但是它發(fā)生在與網(wǎng)站交互之后，這意味著我們不會在DOM中找到內(nèi)容。
在Google I / O會議上，Tom Greenway提到了兩個可接受的解決方案：您可以預先加載這些鏈接并通過CSS隱藏它們，或者您可以為后續(xù)頁面提供標準超鏈接，以便按鈕需要鏈接到單獨的URL序列中的下一個內(nèi)容。
下一個重要元素是嵌入內(nèi)部鏈接的方法。Googlebot只遵循標準的超鏈接，這意味著您需要在代碼中看到類似這樣的鏈接：（沒有間隔）
<a href =“http://www.domain.com”>文本< / a>
如果您看到OnClick鏈接，它們看起來像這樣并且不會被發(fā)現(xiàn)。
因此，在瀏覽源代碼和DOM時，請務必檢查以確保在內(nèi)部鏈接上使用正確的方法。
網(wǎng)址 - 干凈和獨特
獲取內(nèi)容索引的基本規(guī)則是為每條內(nèi)容提供干凈且唯一的URL。
很多時候，JS支持的網(wǎng)站在URL中使用hashtag。谷歌已經(jīng)明確表示，在大多數(shù)情況下，抓取工具不會發(fā)現(xiàn)這種類型的URL。
在分析網(wǎng)站時，請檢查以確保結(jié)構(gòu)不是通過以下網(wǎng)址構(gòu)建的：
Google網(wǎng)址中的＃號后面的所有內(nèi)容都將被剪切并忽略，因此內(nèi)容將不會被編入索引！
超時
沒有人喜歡渲染延遲，甚至谷歌。據(jù)說Google最多等待5秒鐘才能獲得并執(zhí)行JavaScript（請注意，5秒規(guī)則基于觀察結(jié)果，并未經(jīng)Google確認）。我認為Google必須限制執(zhí)行的最長時間，因為渲染是非常耗費資源的過程。
不幸的是，診斷超時問題并不容易。如果我們沒有足夠快地提供內(nèi)容，我們可能無法獲取索引的內(nèi)容。
在JavaScript網(wǎng)站的情況下，您需要等待一段時間才能加載其他元素，甚至整個部分。裝載機顯示將出現(xiàn)新的東西：
如果JavaScript按時執(zhí)行，則Web呈現(xiàn)服務可以正確呈現(xiàn)頁面，并且可以使用JavaScript為內(nèi)容加載索引。但是，如果我們查看搜索結(jié)果，則會看到加載器已編入索引。啊!
我們?nèi)绾伟l(fā)現(xiàn)這些問題？我們可以使用Screaming Frog等工具抓取網(wǎng)站，延遲時間設置為5秒。在渲染模式下，您可以看到渲染版本是否一切正常。
不要依賴于檢查提取和渲染工具中的延遲。它可以等待2分鐘的JavaScript，所以它比Google的Indexer更耐心。
John Mueller建議我們檢查一下Google是否能夠在移動友好測試中及時提供網(wǎng)頁，如果網(wǎng)站能夠正常工作，那么索引應該沒問題。
在分析網(wǎng)站的同時，看看網(wǎng)站是否實現(xiàn)了像加載程序那樣的人為延遲，這迫使等待內(nèi)容交付：
沒有理由設定類似的元素; 它在索引不可發(fā)現(xiàn)的內(nèi)容方面可能具有顯著的效果。
索引
如果內(nèi)容未被編入索引，您將無法獲得任何內(nèi)容。這是檢查和診斷最簡單的因素，也是最重要的！
使用site：domain.com命令
檢查索引的最有用的方法是眾所周知的查詢：
網(wǎng)站：域名“來自您網(wǎng)站的幾行內(nèi)容”
如果您搜索了一些內(nèi)容并在搜索結(jié)果中找到它，那太棒了！但是，如果你找不到它，卷起袖子開始工作。你需要找出為什么它沒有索引！
如果您想進行復雜的索引分析，則需要檢查域和不同部分中可用的不同類型頁面中的部分內(nèi)容。
延遲加載圖像
Google表示加載“懶惰”圖片可能存在問題：
如果您的圖片緩慢加載，請向您正在提供的圖片添加標記，以便在JavaScript關閉時顯示圖片。
讓Google可以發(fā)現(xiàn)懶惰內(nèi)容的第二個選項是結(jié)構(gòu)化數(shù)據(jù)：
包起來
不要將這篇文章用作JS網(wǎng)站的唯一核對清單。盡管這里有很多信息，但這還不夠。
本文旨在成為深入分析的起點。每個網(wǎng)站都是不同的，當你考慮獨特的框架和個人開發(fā)人員的創(chuàng)造力時，不可能僅僅通過檢查清單來結(jié)束審計。