如何為 SEO 審核 JavaScript

已發表: 2023-03-06

JavaScript 在網絡上無處不在。 由於 HTML 和 CSS 本質上是靜態的，因此 JavaScript 已被廣泛採用以在客戶端提供動態功能，這只是一種在瀏覽器中下載和運行的奇特說法。

語言的需求很高，無數的框架/庫和其他變體都在快速發展。 因此，這項技術經常超越搜索引擎支持，進而超越 SEO 領域的最佳實踐，這很常見——也許是不可避免的。 屏幕上的javascript 在審核 JavaScript 之前，您需要注意可能會發生的常見問題，並且您必須做出妥協才能滿足所有需求。

我們將 JavaScript 審核流程分解為五個關鍵領域，讓您確定：

  1. 網站是否嚴重依賴 JavaScript
  2. JavaScript 資產是否被適當地緩存/更新
  3. JavaScript 對網站性能有什麼影響
  4. 是否正確有效地獲取了 JavaScript 文件
  5. 情境 JavaScript 問題：無限滾動路由和重定向

但在我們深入研究之前……

網站結構快速 101

當前的網站由三種主要技術組成：

超文本標記語言 (HTML)

這是其他所有內容所依賴的結構，元素層次結構表示從通用容器到文本、鏈接、媒體和元數據的所有內容。

它簡單、健壯且注重語義，可支持廣泛的應用程序。

雖然瀏覽器會合理地格式化原始 HTML，但呈現更好地處理......

級聯樣式表 (CSS)

這是表示層，可以在其中以多種方式設置 HTML 的樣式和重新排列。

任何 HTML 元素都可以被定位、移動、著色、調整大小，甚至動畫。 實際上，這就是網站設計的實現。

然而，除了一些有限的功能外，它仍然是靜態的，讓我們……

JavaScript (JS)

這是動態層，可以主動操作 HTML 和 CSS 以響應用戶交互、時間或服務器更改等事件。 這極大地拓寬了在用戶體驗方面可以實現的目標。

當你訪問一個網站時，你的瀏覽器會下載 HTML 文件，然後讀取它，一個接一個地解釋和執行每一部分。 下載外部資產（CSS/JS/媒體/字體），並根據相關指令和說明將元素拼湊在一起。

這種將網站的構建塊組合在一起以產生最終結果的過程稱為渲染。 這與 SEO 高度相關，因為谷歌會做一些類似於瀏覽器的事情（有一些額外的分析步驟）並在排名時考慮到這一點。 實際上，谷歌試圖複製用戶的體驗。

Google 如何處理 JavaScript？

Google 將呈現 JavaScript。 換句話說，它將加載您的 JavaScript 資產以及 HTML 和 CSS，以更好地了解用戶將看到的內容，但有兩個基本考慮因素：

  1. Google 希望使用盡可能少的資源來抓取網站。
  2. 更多的 JavaScript 意味著需要更多的資源來呈現。

由於這些問題，Google 的網頁呈現服務旨在盡可能高效地工作，因此採用了以下策略：

  • Googlebot 將始終呈現它首次抓取的頁面。 此時它決定是否需要在未來呈現該頁面。 這將影響頁面在未來抓取時呈現的頻率。
  • 分析資源以識別對基本頁面內容沒有貢獻的任何內容。 可能無法獲取這些資源。
  • 資源被積極緩存以減少網絡請求，因此更新的資源最初可能會被忽略。
  • 在抓取過程中，狀態不會從一個頁面保留到下一個頁面（例如，不存儲 cookie，每個頁面都是一次“新鮮”訪問）。

這裡的要點是，總的來說，谷歌將花費更長的時間來索引通過 JavaScript 呈現的內容，並且有時可能會完全錯過一些東西。

那麼，有多少重要內容受到影響？ 當發生變化時，需要多長時間才能反映在 SERP 中？ 在整個審計過程中牢記這樣的問題。

JavaScript SEO 審核的五步指南

每個人都有自己獨特的方式來執行 JavaScript SEO 審核，但是如果您不確定從哪裡開始或者您認為您在當前流程中遺漏了一些步驟，請繼續閱讀。

1. 了解網站對 JavaScript 的依賴程度

最初，重要的是要確定站點是否嚴重依賴 JavaScript，如果是，到什麼程度？ 這將有助於控制後續分析的深度。

這可以通過幾種方法實現：

  • JavaScript 會做什麼？
  • 通過 Chrome 在本地禁用 JavaScript
  • 手動簽入 Chrome
  • Wappalyzer
  • 尖叫的青蛙

JavaScript 會做什麼 (WWJSD)

Onely提供的一種工具，它通過顯示 HTML、元標記和鏈接的屏幕截圖（使用和不使用 JavaScript）提供 URL 的直接、並排比較。

javascript會做什麼頁面 仔細考慮您是要檢查移動設備還是桌面設備。 雖然移動優先原則通常適用，但 JavaScript 更傾向於作為桌面體驗的一部分使用。 但理想情況下，如果您有時間，請同時測試兩者！

分析 WWJSD 中 Javascript 使用的步驟：

  1. 訪問 WWJSD
  2. 選擇手機或桌面
  3. 輸入網址
  4. 提交表格

通過 Chrome 在本地禁用

Chrome 瀏覽器允許您就地禁用任何 JavaScript 並直接測試：

在 chrome 中禁用 javascript 使用 Chrome 分析 JavaScript 使用的步驟：

  1. 按 F12 打開 devtools 並選擇 Elements 選項卡（如果尚未打開）
  2. Cmd+Shift+P（或 Ctrl+Shift+P）
  3. 輸入“disable”並選擇*Disable JavaScript*
  4. 刷新頁面
  5. 不要忘記重新啟用

手動簽入 Chrome

有兩種方法可以在 Chrome 中檢查源 HTML，因為它們提供的結果略有不同。

查看源代碼將顯示最初收到的 HTML，而檢查源代碼會使動態更改生效——JavaScript 添加的任何內容都會一目了然。

查看來源： 查看資源 檢查來源： 檢查來源 這最適合用作檢查完整 JavaScript 框架的快速方法。 最初的源下載會更短，可能會丟失大部分內容，但檢查器會更完整。

嘗試在兩者中搜索一些您懷疑是動態加載的文本——內容或導航標題通常是最好的。

使用 Chrome 手動分析 JavaScript 使用的步驟：

 查看來源：

  1. 在瀏覽器視口中右鍵單擊
  2. 選擇查看源代碼

檢查來源：

  1. 按F12打開devtools
  2. 如果尚未打開，請選擇“元素”選項卡

Wappalyzer

這是一個提供網站背後技術堆棧細分的工具。 通常有相當多的信息，但我們專門尋找 JavaScript 框架：

wappalyzer 使用Wappalyzer分析JavaScript使用的步驟

  1. 安裝Wappalyzer Chrome 擴展程序
  2. 訪問您要檢查的站點
  3. 單擊 Wappalyzer 圖標並查看輸出

️ 請注意，僅僅因為此處未列出某些內容，並不能 100% 確認它未被使用！

Wappalyzer 依靠指紋來識別框架。 也就是說，找到該框架獨有的標識符和模式。

如果已採取任何措施來改變這些，Wappalyzer 將不會識別該框架。 還有其他方法可以確認這一點，這超出了本文檔的範圍。 問一個開發者。

尖叫的青蛙

這是對 JavaScript 可見性檢查的深入研究。 啟用JavaScript呈現後，Screaming Frog 可以提供 JavaScript 對已爬網網站的影響的全面細分，包括呈現的內容/鏈接覆蓋率和潛在問題。 尖叫的青蛙 使用 Screaming Frog 分析 Javascript 問題的步驟：

  1. 前往配置菜單
  2. 選擇*蜘蛛*
  3. 選擇渲染選項卡
  4. 從下拉列表中選擇 JavaScript
  5. （可選）減少 AJAX 超時並取消勾選以提高抓取性能（如果遇到困難）

2.使用強制緩存刷新

緩存是一個允許更有效地加載網站的過程。 當您最初訪問一個 URL 時，所需的所有資產都存儲在不同的地方，例如您的瀏覽器或託管服務器。 這意味著不是在每次訪問時從頭開始重建頁面，而是存儲頁面的最後一個已知版本以便更快地進行後續訪問。

更新 JavaScript 文件後，您不希望使用緩存的版本。 Google 還非常積極地進行緩存，因此這對於確保呈現您網站的最新版本尤為重要。

有幾種方法可以解決這個問題，例如為緩存文件添加過期日期，但通常最好的“按需”解決方案是使用強制緩存刷新。

原理很簡單：假設您有一個名為“main.js”的 JavaScript 文件，其中包含網站的大部分 JavaScript。 如果這個文件被緩存，谷歌將使用那個版本並忽略任何更新； 充其量，呈現的頁面將過時； 在最壞的情況下，它會被打破。

最佳做法是更改文件名以區別於以前的版本。 這通常需要某種版本號或通過對文件進行指紋識別來生成代碼。

為實現這一目標，有兩種策略：

  1. 幾個帶有“最後更新”時間戳的文件附加為 URL 變量。
  2. 文件名本身使用的唯一代碼——“filename.code.js”是一種常見的模式，如下所示：

更改文件名以避免緩存 要遵循的步驟：

  1. 按 F12 加載 Chrome devtools
  2. 轉到“網絡”選項卡
  3. 應用過濾器
    • 在 *Filter* 字段中，像這樣過濾主域：`domain:*.website.com`
    • 單擊 JS 過濾器以排除非 JS 文件
  4. 查看文件列表並評估——如果需要，尋求開發人員幫助

️ 雖然相關的 JavaScript 文件通常可以在主域中找到，但在某些情況下，它們可能託管在外部，例如在內容分發網絡 (CDN) 上。

根據上述示例，在 WP Engine 託管站點上，您可能需要過濾“*.wpenginepowered.com”而不是主域。 這裡沒有硬性規定——查看（未過濾的）JS 列表中的域並使用您的最佳判斷。 您可能會看到的示例是： 過濾“*.wpenginepowered.com”時的域列表示例 如果域列不可見，請右鍵單擊現有列標題並選擇域。

3.確定JS對網站性能有什麼影響

在網站性能方面，有幾件事需要注意。

處理時間

這與Core Web Vitals (CWV)相關，其中一些在下面的時間可視化中表示，它著眼於最大內容痛苦 (LCP)、累積佈局偏移 (CLS) 和首次輸入延遲 (FID) 等指標。

具體來說，您對摘要中的加載和腳本編寫時間感興趣。 如果這些過多，則可能是大型和/或低效腳本的標誌。

瀑布視圖還提供了每個 CWV 以及網站其他組件的影響的有用可視化。 CWV 的瀑佈景觀 腳步：

  1. 按 F12 打開 Chrome devtools
  2. 轉到“性能”標籤
  3. 單擊面板中的刷新按鈕
  4. 查看“摘要”選項卡（如果您想深入了解，請查看“自下而上”選項卡）

壓縮

這是一項簡單但重要的檢查； 它確保有效地提供文件。

正確配置的主機將壓縮網站資產，以便瀏覽器盡快下載它們。 網絡速度通常是網站加載時間最重要（和可變）的瓶頸。 CWV的加載時間 腳步：

  1. 按 F12 打開 Chrome devtools
  2. 轉到“網絡”選項卡
  3. 應用過濾器
  4. 在“過濾器”字段中，像這樣過濾主域：`domain:*.website.com`
  5. 單擊 JS 過濾器以排除非 JS 文件
  6. 查看“內容編碼”列的內容。 如果它顯示為“gzip”、“compress”、“deflate”或“br”，則表明正在應用壓縮。

️ 如果內容編碼列不可見：

  1. 右鍵單擊現有列
  2. 將鼠標懸停在“響應標題”上
  3. 點擊“內容編碼”
  4. 覆蓋範圍

功能豐富的資產框架（例如 Bootstrap、Foundation 或 Tailwind）的增加可以加快開發速度，但也可能導致大量 JavaScript 未實際使用。

此檢查有助於可視化每個文件中有多少實際未在當前 URL 上使用。

️ 請注意，一個頁面上未使用的 JavaScript 可能會在其他頁面上使用！這主要用於指導，表明優化的機會。 檢查未使用的 javascript 腳步：

  1. 按 F12 打開 Chrome devtools
  2. Cmd+Shift+P（或 Ctrl+Shift+P）
  3. 點擊“顯示覆蓋範圍”
  4. 單擊面板中的刷新按鈕
  5. 應用過濾器
    • 在 *Filter* 字段中，過濾主域。 這裡沒有通配符； 'website.com' 就可以了。
    • 從過濾器輸入旁邊的下拉列表中選擇 JavaScript

縮小

JavaScript 最初是以人類可讀的方式編寫的，具有易於推理的格式和術語。 計算機不關心這個——它們將整個文件解釋為一行代碼，並且不關心這些東西被稱為什麼，只要它們被一致地引用。

因此，最好將文件壓縮到盡可能小的尺寸。 這稱為縮小，是常見的做法，但偶爾也會遺漏。

發現差異是微不足道的： 縮小文件 ^ 縮小 = 好！ 不是縮小文件 ^ 未縮小 = 不好！

️ 這主要適用於生產中的站點。開發/測試中的站點往往具有未縮小的文件，以便更容易找到錯誤。

腳步：

  1. 按 F12 打開 Chrome devtools
  2. 轉到“網絡”選項卡
  3. 應用過濾器
    • 在“過濾器”字段中，像這樣過濾主域：domain:*.website.com
    • 單擊 JS 過濾器以排除非 JS 文件
  4. 檢查每個文件
    • 單擊文件名
    • 轉到出現的面板上的“響應”選項卡

捆綁

可以將多個 JavaScript 文件捆綁成更少的文件（或一個！）以減少網絡請求的數量。 從本質上講，從主域中提取的 JavaScript 文件越多，使用這種方法的可能性就越小。

大多數時候這並不是真正的破壞者，但是獨立的 JavaScript 文件的數量越多，通過捆綁它們可以節省的時間就越多。

請注意，WordPress 特別鼓勵在需要時由插件加載文件，這可能會導致某些頁面加載大量 JavaScript 文件而其他頁面加載很少。 所以這更像是一次機會練習。

腳步：

  1. 從縮小開始重複步驟 1-3
  2. 注意存在多少個文件——一到三個通常是一個好兆頭

4. 了解是否正確有效地獲取了 JavaScript 文件

有幾件事要看。

資源被 robots.txt 阻止

呈現網站時，Google 不會提取 robots.txt 中阻止的 JavaScript 文件，這可能會導致呈現損壞或數據丟失。

確保檢查 robots.txt 中沒有阻止任何 JavaScript。

腳本加載

當頁面上包含 JavaScript 文件時，加載順序很重要。

如果在面向用戶的內容之前檢索了太多文件，則用戶看到該站點之前的時間會更長，從而影響可用性並增加跳出率。 高效的腳本加載策略將有助於最大限度地減少站點的加載時間。

  • 直接方法： <script src=”file.js”>

直接方法將在那裡加載文件。 該文件從緩存中獲取、下載或檢索（這是當它出現在 devtools 的“網絡”選項卡中時），然後在瀏覽器繼續加載頁面之前解析和執行。

  • 異步方法： <script async src=”file.js”>

async 方法將異步獲取文件。 這意味著它將在後台開始下載/檢索文件並立即繼續加載頁面。 只有當頁面的其餘部分加載完成時，這些腳本才會運行。

  • 延遲方法： <script defer src=”file.js”>

defer 方法將像 async 方法一樣異步獲取文件，但它會在獲取文件後立即運行這些腳本，即使頁面尚未完成加載也是如此。

那麼，這些方法中哪種最好？

經典的 SEO 響應，這取決於。 理想情況下，任何可以異步/延遲的腳本都應該如此。 開發人員可以根據代碼的作用來確定哪個最合適，並且可能會被說服進一步分解腳本，以便以一種或另一種方式更有效地處理它們。

這兩種類型通常都可以放在 HTML 的主要 <head> 區域中，因為它們不會延遲內容加載。 通過直接方法加載有時是不可避免的，但通常應該發生在頁面內容的末尾，在結束 </body> 標記之前。 這可確保在加載/運行任何腳本之前已將主頁內容交付給用戶。 同樣，這並不總是可能的（或可取的），但需要注意。

查看第三方腳本的影響

網站通常會出於各種目的引入第三方腳本，最常見的包括分析和廣告資源。 癥結在於，這些通常會加載自己的額外腳本，而這些腳本又可以加載更多。 這在原則上可以通過 devtools 網絡數據進行審查，但全貌可能很難掌握。

幸運的是，有一個方便的工具可以直觀地映射出依賴關係，以深入了解正在加載的內容以及從何處加載： 顯示依賴關係的工具 此處的目標是確定正在加載的內容並發現減少冗餘、不再使用或通常不適用的第三方腳本數量的機會。

腳步：

  1. 訪問網頁測試
  2. 確保選擇“站點性能”測試
  3. 輸入網址並點擊“開始測試”
  4. 在結果摘要頁面上，找到“查看”下拉菜單
  5. 選擇“請求地圖”

5.注意情境JavaScript問題

JS 框架

毫無疑問，您會遇到一個或多個流行的 JavaScript 框架——React、Vue 和 Angular 是突出的例子。

這些通常依賴 JavaScript 在瀏覽器中部分或全部構建網站，而不是下載已經構建的頁面。

雖然這在性能和維護方面可能是有益的，但它也會給 SEO 帶來麻煩，最典型的抱怨是這意味著谷歌需要做更多的工作才能完全呈現每個頁面。 這會延遲指數化——有時會大大延遲。 SEO 社區中的許多人認為這意味著“JavaScript = 壞”，並且會阻止使用框架。 這可以說是把嬰兒連同洗澡水一起倒掉的案例。

一個非常可行的替代方案是使用像Prerender這樣的服務。 這將為搜索引擎抓取工具呈現和緩存您的網站，以便當他們訪問您的網站時，他們會看到它的最新和完整表示，確保快速索引。

無限滾動

Infinite scroll 往往很卡，不像 pagination 那樣可靠，但是有正確和錯誤的方法。

檢查任何可能具有分頁功能的 URL，例如博客和類別，並查找分頁。 如果改為使用無限滾動，請在滾動瀏覽每批結果時監視 URL 欄——當您滾動瀏覽時，URL 是否會更新以反映“頁面”？

如果是這樣，這對谷歌來說已經足夠好了，應該被正確抓取。

如果沒有，這應該由開發人員修復。

理想情況下，URL 更新應該以一種“乾淨”的方式實現，例如 ?page=2 或 /page/2。 有一些方法可以使用哈希（如#page-2）來完成，但谷歌目前不會抓取它。

路由

如果正在使用 JavaScript 框架（例如 React、Vue、Angular），請檢查Wappalyzer 。 您可能會看到幾個網址：

  • https://www.website.com/pretty/standard/route
  • https://www.website.com/#/wait/what/is/this
  • https://www.website.com/#!/again/what

第二個和第三個示例中的哈希可以由 JavaScript 框架生成。 瀏覽沒問題，但 Google 無法正確抓取它們。

因此，如果您在其他看起來“正確”的 URL 段之前發現 #（或它的某些變體），則值得建議更改為無哈希 URL 格式。

重定向

通常應避免 JavaScript 重定向。 儘管它們會被搜索引擎識別，但它們需要渲染才能工作，因此對於 SEO 來說不是最佳選擇。

您可以通過在啟用 JavaScript 呈現的情況下運行 Screaming Frog 爬網並查看 JS 選項卡/過濾器下的 JS 重定向來檢查這些。

可能存在某些特定的 JS 驅動功能需要 JS 重定向的情況。 只要這些是例外而不是規則，就可以了。

結論

Javascript 可能會給 SEO 帶來問題，但可以通過仔細理解和審核關鍵的潛在問題領域來最大程度地減少這些問題：

1) 網站對 JavaScript 的依賴程度

2) JavaScript 資產是否被適當地緩存/更新

3）JavaScript對網站性能有什麼影響

4) 是否正確有效地獲取了 JavaScript 文件

5) 情境 JavaScript 問題，例如無限滾動路由和重定向

如果您對 JavaScript 審核或 SEO 有任何疑問，請隨時與我們聯繫- 我們很樂意與您交談。