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