外一個研究團隊進行了一項HTML研究，該研究基于從Google排名前20位的搜索結果中收集的大約800萬個索引頁，其中包含3000萬個關鍵字

他們撰寫了有關標記結果的信息，以及排名前20的Google結果頁如何實現它們的內容，然后進行了進一步介紹，并獲得了有關它們的HTML 使用情況見解。

與SEO有什么關系？

HTML的編寫方式決定了用戶看到的內容以及搜索引擎如何解釋網頁。有效，格式正確的HTML頁面還可以減少搜索引擎可能對結構化數據，元數據，語言或編碼的誤解。

我們打算從一開始就做一次技術性SEO審核：HTML用法的細分以及結果與現代SEO技術和最佳實踐的關系。

在本文中，我們將解決Google可以理解的元標記，JSON-LD結構化數據，語言檢測，標題用法，社交鏈接和元分布，AMP等問題。

Google可以理解的元標記

當談到主要的搜索引擎作為流量來源時，可悲的是只有谷歌和其余的人，最近Duckduckgo獲得了關注，Bing幾乎不存在。

因此，在本部分中，我們將僅關注Google在Search Console幫助中心中列出的meta標簽。

餅圖顯示了Google可以理解的meta標簽總數，以下部分對此進行了詳細說明。

<meta name =“描述” content =“ ...”>

元描述是?150個字符的摘要，總結了頁面的內容。當搜索的短語包含在描述中時，搜索引擎會在搜索結果中顯示元描述。

選擇器 計數

<meta name =“ description” content =“ *”>4,391,448

<meta name =“描述” content =“”>374,649

<meta name =“ description”>13,831

在極端情況下，我們發現了685,341個元內容少于30個字符的元和1,293,842個元內容文本超過160個字符的元。

<標題>

從技術上講，標題不是meta標記，而是與meta name =“ description”結合使用。

當涉及SEO時，這是兩個最重要的HTML標簽之一。根據W3C，這也是必須的，這意味著缺少標題標簽的任何頁面均無效。

研究表明，如果您將標題保持在合理的60個字符以內，則可以期望在SERP中正確顯示標題。過去，有跡象表明Google的搜索結果標題長度有所延長，但這并不是永久性的變化。

考慮到以上所有情況，我們發現在全部6,263,396個標題中，有1,846,642個標題標簽似乎太長（超過60個字符），而1,985,020個標題的長度卻認為太短（少于30個字符）。

餅狀圖顯示了標題標簽的長度分布，長度小于30個字符為31.7％，長度大于60個字符為約29.5％。

標題太短不應該是問題，畢竟，這取決于網站業務，是主觀的。意義可以用更少的詞來表達，但這絕對是優化機會浪費的跡象。

選擇器 計數

<title> * </ title> 6,263,396

缺少<title>標簽 1,285,738

另一個有趣的事情是，在Google排名第1-2頁的網站中，有351,516個（約占750萬個的5％）在其索引頁上使用相同的標題和h1文本。

另外，您知道嗎，使用HTML5，您只需要指定HTML5文檔類型和標題即可擁有完全有效的頁面？

<！DOCTYPE html>
<title>紅色</ title>

<meta name =“ robots | googlebot”>

這些元標記可以控制搜索引擎抓取和編制索引的行為。機器人元標記適用于所有搜索引擎，而“ googlebot”元標記特定于Google。”
- Google可以理解的元標記

選擇器 計數

<meta name =“ robots” content =“ ...，...”> 1,577,202

<meta name =“ googlebot” content =“ ...，...”> 139,458

帶有元漫游器的HTML代碼段及其內容參數。

因此，漫游器元指令可向搜索引擎提供有關如何對頁面內容進行爬網和索引的說明。除了googlebot元數很少之外，我們很想知道最常見的robots參數，因為一個巨大的誤解是您必須在HTML的頭部添加robots meta標簽。這是前5名：

選擇器 計數

<meta name =“ robots” content =“ index，follow”> 632822

<meta name =“ robots” content =“ index”>180,226

<meta name =“ robots” content =“ noodp”>115,128

<meta name =“ robots” content =“ all”>111,777

<meta name =“ robots” content =“ nofollow”>83,639

<meta name =“ google” content =“ nositelinkssearchbox”>

“當用戶搜索您的網站時，Google搜索結果有時會顯示特定于您網站的搜索框，以及指向您網站的其他直接鏈接。此元標記告訴Google不要顯示附加鏈接搜索框。”
- Google可以理解的元標記

選擇器計數

<meta name =“ google” content =“ nositelinkssearchbox”>1,263

毫不奇怪，當網站出現在搜索結果中時，很少有網站選擇明確告訴Google不要顯示附加鏈接搜索框。

<meta name =“ google” content =“ notranslate”>

“此meta標簽告訴Google您不希望我們為該頁面提供翻譯。”- Google理解的meta標簽

在某些情況下，可能不希望將您的內容提供給更多的用戶。就像上面的Google支持答案中所說的那樣，此meta標簽告訴Google您不希望他們提供此頁面的翻譯。

選擇器 計數

<meta name =“ google” content =“ notranslate”> 7,569

<meta name =“ google-site-verification” content =“ ...”>

“您可以在網站的頂級頁面上使用此標簽來驗證Search Console的所有權。”
- Google可以理解的元標簽

選擇器 計數

<meta name =“ google-site-verification” content =“ ...”>1,327,616

當我們討論這個主題時，您是否知道如果您是Google Analytics（分析）媒體資源的經過驗證的所有者，那么Google現在會 在Search Console中自動驗證該網站嗎？

<meta charset =“ ...”>

“這定義了頁面的內容類型和字符集。”
- Google可以理解的元標記

這基本上是好的元標記之一。它定義頁面的內容類型和字符集。考慮到下表，我們注意到我們分析的索引頁中只有大約一半定義了元字符集。

選擇器 計數

<meta charset =“ ...”> 3,909,788

<meta http-equiv =“刷新” content =“ ...; url = ...”>

“此元標記會在一段時間后將用戶發送到新的URL，有時會用作一種簡單的重定向形式。”
- Google理解的元標記

最好使用301重定向而不是元刷新來重定向您的網站，尤其是當我們假設30倍重定向不會丟失PageRank 且W3C 建議不要使用此標記時。Google也不是粉絲，建議您使用服務器端301重定向。

選擇器 計數

<meta http-equiv =“刷新” content =“ ...; url = ...”>7,167

從我們解析的總共750萬個索引頁中，我們發現了7167個使用上述重定向方法的頁。作者并不總是擁有對服務器端技術的控制權，顯然他們使用此技術來啟用客戶端重定向。

此外，使用Workers是一種最先進的替代方案，目的是為了克服使用傳統技術堆棧和平臺限制時遇到的問題。

<meta name =“ viewport” content =“ ...”>

“此標簽告訴瀏覽器如何在移動設備上呈現頁面。此標簽的存在向Google表示該頁面適合移動設備。”
- Google可以理解的元標簽

選擇器 計數

<meta name =“ viewport” content =“ ...”> 4,992,791

從2019年7月1日開始，所有網站開始使用Google的移動優先索引編制索引。Lighthouse檢查文件頭中是否有meta name =“ viewport”標記，因此無論您使用的是哪種框架或CMS，此meta都應位于每個網頁上。

考慮到上述情況，我們可以預期在分析的750萬個索引頁面中，有超過4,992,791個網站的網站在其頭部使用了有效的meta name =“ viewport”。

設計適合移動設備的網站可確保您的頁面在所有設備上都能正常運行，因此請確保 此處的網頁適合移動設備。

<meta name =“ rating” content =“ ...” />

“將網頁標記為包含成人內容，以表示該網頁已被安全搜索結果過濾。”
- Google可以理解的元標記

選擇器 計數

<meta name =“ rating” content =“ ...” />133,387

此標簽用于表示內容的成熟度等級。直到最近，它才被添加到Google可以理解的meta標簽中。請查看Kate Morris撰寫的有關如何標記成人內容的文章。

JSON-LD結構化數據

結構化數據是一種標準化格式，用于提供有關頁面的信息并分類頁面內容。結構化數據的格式可以是Microdata，RDFa和JSON-LD，所有這些都可以幫助Google了解您網站的內容并觸發頁面的特殊搜索結果功能。

在與出色的Dan Shure交談時，他提出了一個好主意，可以在搜索結果和“知識圖”中查找結構化數據，例如組織的徽標。

在本部分中，我們將僅使用JSON-LD（用于鏈接數據的JavaScript對象表示法）來收集結構化數據信息。無論如何，這是Google建議的有關網頁含義的線索。

一些有用的信息：

• 在Google I / O 2019上，宣布結構化數據測試工具將由功能豐富的結果測試工具取代 。
• 現在，Googlebot使用最新的Chromium而不是舊的Chrome 42對網頁進行索引，這意味著您還可以通過結構化數據支持來減輕過去可能遇到的SEO問題。
• 杰森·巴納德（Jason Barnard）在2019年SMX倫敦會議上就Google搜索排名的工作方式進行了有趣的演講，根據他的理論，我們可以依靠七個排名因素; 結構化數據絕對是其中之一。
• 關于微數據，JSON-LD和Schema.org的Builtvisible指南包含您需要了解的有關在網站上使用結構化數據的所有信息。
• 這是Alexis Sanders 撰寫的給初學者的JSON-LD很棒指南。
• 最后但并非最不重要的一點是，在Linking Data網站的官方JSON上有很多文章，演示文稿和帖子可供參考。

高級網絡排名的HTML研究僅依賴于分析索引頁面。有趣的是，即使指南中未對此進行說明，但Google似乎并不關心索引頁上的結構化數據，正如幾年前Gary Illyes 在Stack Overflow回答中所說的那樣。但是，在Google理解的 JSON-LD結構化數據類型上，我們發現了總共2,727,045個功能：

餅圖顯示了Google可以理解的結構化數據類型，其中“附加鏈接”搜索框為49.7％（最高值）。

結構化數據功能 計數

文章 35,961

面包屑 30,306

書 143

輪播 13,884

公司聯系方式 41,588

課程 676

評論家評論 2,740

數據集 28

雇主總評分 7

事件 18,385

事實檢查 7

常見問題頁面 16

如何 8

招聘啟事 355

現場直播 232

當地的商業 200,974

商標 442,324

媒體 1,274

占用 0

產品 16,090

問答頁面 20

食譜 434

評論片段 72,732

網站連結搜尋框 1,354,754

社會概況 478,099

軟件應用 780

可以說 516

訂閱和付費內容 363

視頻 14,349

rel =規范

rel = canonical元素（通常稱為“規范鏈接”）是一種HTML元素，可幫助網站管理員防止重復的內容問題。它通過指定“規范URL”（網頁的“首選”版本）來實現。

選擇器 計數

<link rel = canonical href =“ *”> 3,183,575

meta name =“ keywords”

<meta name =“ keywords”>已過時并且Google不再使用它已經不是什么新鮮事了。對于大多數搜索引擎來說，<meta name =“ keywords”>似乎也是垃圾郵件信號。

“盡管主要搜索引擎不使用元關鍵字進行排名，但是它們對于像Solr這樣的現場搜索引擎非常有用。”
- JP Sherman解釋了為什么如今這種過時的元數據仍然有用。

選擇器 計數

 <meta name =“ keywords” content =“ *”> 2,577,850

<meta name =“ keywords” content =“”> 256,220

<meta name =“ keywords”> 14,127

標題

在750萬頁中，h1（59.6％）和h2（58.9％）是使用最多的28個元素之一。盡管如此，收集所有的標題后，我們發現，H3是出場最多的標題- 29565562 3H公司出70428376個總標題的發現。

隨機事實：

• 在H1-H6元素表示六個層次部分的標題的。下面是對標題使用完整統計，但我們發現的23116 h7s和7,276 H8S了。這很有趣，因為很多人甚至都不經常使用h6。
• 有3,046,879個頁面缺少h1標簽，而在其余4,502,255頁中，h1的使用頻率為2.6，共有11,675,565個h1元素。
• 雖然有6263396個網頁與一個有效的標題，如上面看到的，只有其中的4502255使用的是H1的內體的內容。

缺少alt標簽

分析這組數據后，這個永恒的SEO和可訪問性問題似乎仍然很常見。在總共669,591,743張圖像中，幾乎90％缺少alt屬性或將其與空白值一起使用。

餅狀圖顯示了img標簽的alt屬性分布，其中缺失的alt占主導地位-在我們發現的約6.7億張圖像中，占81.7％。

選擇器 計數

img 669,591,743

img alt =“ *” 79,953,034

img alt =“” 42,815,769

img w / missing alt 546,822,940

語言檢測

根據規范，用戶代理可以使用通過lang屬性指定的語言信息以各種方式控制渲染。

我們在此處感興趣的部分是有關“輔助搜索引擎”的。

“ HTML lang屬性用于識別網絡上文本內容的語言。這些信息有助于搜索引擎返回特定于語言的結果，屏幕閱讀器也可以使用這些信息來切換語言配置文件，以提供正確的口音和發音。”
- LéonieWatson

不久前，約翰·穆勒（John Mueller）說Google忽略了HTML lang屬性，而是建議使用鏈接hreflang。Google Search Console文檔指出，Google使用hreflang標記將用戶的語言偏好與頁面的正確變體進行匹配。

條形圖顯示750萬個索引頁中有65％使用html元素上的lang屬性，同時21.6％至少使用鏈接hreflang。

在我們可以查看的750萬個索引頁中，有4,903,665個使用html元素上的lang屬性。大約是65％！

關于hreflang屬性，這表明存在一個多語言網站，我們發現大約有1,631,602個頁面—這意味著大約21.6％的索引頁面至少使用 鏈接rel =“ alternate” href =“ *” hreflang =“ *”元素。

Google跟蹤代碼管理器

從一開始，Google Analytics（分析）的主要任務就是生成有關您的網站的報告和統計信息。但是，如果要將某些頁面分組在一起以查看人們如何瀏覽該渠道，則需要一個唯一的Google Analytics（分析）標簽。這就是事情變得復雜的地方。

Google跟蹤代碼管理器使您更輕松地進行以下操作：

• 通過讓您定義標簽應觸發的時間和用戶操作的自定義規則，來管理這些混亂的標簽
• 隨時更改標簽，而無需實際更改網站的源代碼，由于發布周期緩慢，有時可能會令人頭疼
• 再次與GTM一起使用其他分析/營銷工具，而無需觸及網站的源代碼

我們搜索了* googletagmanager.com / gtm.js參考資料，發現大約有345,979個頁面正在使用Google跟蹤代碼管理器。

rel =“ nofollow”

“ Nofollow”為網站管理員提供了一種告訴搜索引擎“不遵循此頁面上的鏈接”或“不遵循此特定鏈接”的方法。

Google不遵循這些鏈接，并且同樣不轉讓權益。考慮到這一點，我們對rel =“ nofollow”數字感到好奇。我們在750萬個索引頁面中找到了總共12,828,286個rel =“ nofollow”鏈接，計算得出的平均每頁為1.69 rel =“ nofollow”。

上個月，Google宣布了兩個新的鏈接屬性值，用于標記鏈接的nofollow屬性：rel =“ sponsored”和rel =“ ugc”。我建議您閱讀Cyrus Shepard 關于Google的nofollow，贊助商和ugc鏈接如何影響SEO的文章，了解Google更改nofollow的原因，nofollow鏈接的排名影響等等。

賽勒斯·謝潑德（Cyrus Shepard）的文章中的表格顯示了Google的nofollow，Sponsored和UGC鏈接屬性如何影響SEO。

我們走得更遠，查找了這些新的鏈接屬性值，找到了278 rel =“ sponsored”和123 rel =“ ugc”。為了確保我們擁有與這些查詢相關的數據，我們專門在Google宣布此事后兩周更新了索引頁數據集。

加速移動網頁（AMP）是Google的一項舉措，旨在加快移動網絡的速度。許多發布者正在使其內容與AMP格式并行可用。

為了讓Google和其他平臺了解這一點，您需要將AMP和非AMP頁面鏈接在一起。

在我們瀏覽的數百萬個頁面中，我們發現只有24,807個非AMP頁面使用rel = amphtml引用其AMP版本。

社會的

我們想知道當今網站的可共享性或社交性，因此知道Josh Buchea列出了一個很棒的列表，其中包含 所有可能出現在您網頁頂部的內容，我們從中提取了社交部分，并獲得了以下數字：

Facebook開放圖

條形圖顯示了Facebook Open Graph元標記的分布，在下表中進行了詳細說明。

選擇器 計數

元屬性=“ fb：app_id” content =“ *”277,406

元屬性=“ og：url”內容=“ *”2,909,878

元屬性=“ og：type” content =“ *”2,660,215

元屬性=“ og：title” content =“ *”3,050,462

元屬性=“ og：image” content =“ *”2,603,057

元屬性=“ og：image：alt” content =“ *”54,513

元屬性=“ og：description” content =“ *”1,384,658

元屬性=“ og：site_name” content =“ *”2,618,713

元屬性=“ og：locale” content =“ *”1,384,658

元屬性=“ article：author” content =“ *”14,289

Twitter卡

條形圖顯示了Twitter Card meta標簽的分布，在下表中有詳細說明。

選擇器 計數

元名稱=“ twitter：card” content =“ *” 1,535,733

元名稱=“ twitter：site” content =“ *” 512,907

元名稱=“ twitter：creator” content =“ *”283,533

元名稱=“ twitter：url” content =“ *”265,478

元名稱=“ twitter：title” content =“ *”716,577

元名稱=“ twitter：description” content =“ *”1,145,413

元名稱=“ twitter：image” content =“ *”716,577

元名稱=“ twitter：image：alt” content =“ *”30,339

說到鏈接，我們抓住了所有指向最受歡迎的社交網絡的鏈接。

下表顯示了外部社交鏈接分布的餅圖。

選擇器 計數

<a href*="facebook.com">6,180,313

<a href*="twitter.com">5,214,768

<a href*="linkedin.com">1,148,828

<a href*="plus.google.com">1,019,970

顯然，仍有許多網站仍鏈接到其Google+個人資料，考慮到最近Google+的關閉，這可能是一個疏忽。

rel =上一個/下一個

根據Google的說法，使用rel = prev / next不再是索引信號，正如今年早些時候宣布的那樣：

“在評估索引信號時，我們決定停用rel = prev / next。研究表明，用戶喜歡單頁內容，在可能的情況下盡量做到這一點，但對于Google搜索來說，多部分內容也可以。”
- Google網站管理員發布的推文

但是，如果對您來說很重要，Bing表示它將它們用作提示以發現頁面和了解網站結構。

“我們將這些標記（如大多數標記）用作頁面發現和網站結構理解的提示。此時，我們不會基于這些頁面將頁面合并在一起，也不會在排名模型中使用prev / next。”
- Bing的FrédéricDubut

不過，這是我們在查看數百萬個索引頁面時發現的使用情況統計信息：

選擇器 計數

<link rel =“ prev” href =“ *”20,160

<link rel =“ next” href =“ *”242,387

大概就這樣吧！

通過使用大約800萬個索引頁面中的數據了解平均網頁的外觀，可以使我們更清楚地了解趨勢，并幫助我們直觀地了解SEO現代和新興技術中HTML的常見用法。但這可能是一個永無止境的傳奇-盡管有大量的數字和統計數據需要探索，但仍有許多問題需要回答：

• 我們知道現在如何在野外使用結構化數據。它將如何發展，將足夠考慮多少結構化數據？
• 我們是否應該期望AMP使用量將來會增加？
• rel =“ sponsored”和rel =“ ugc”將如何改變我們每天編寫HTML的方式？在編碼外部鏈接時，除了target =“ _ blank”和rel =“ noopener”組合之外，我們現在必須考慮rel =“ sponsored”和rel =“ ugc”組合也是如此。
• 我們是否會學會始終為具有裝飾目的的圖像添加alt屬性值？
• 我們必須將多少其他元標記或屬性添加到網頁中，才能取悅搜索引擎？我們真的需要新發布的data-nosnippet HTML屬性嗎？接下來是data-allowsnippet嗎？

我們還希望解決其他問題，例如“第一字節時間”（TTFB）值，該值與排名高度相關。我強烈建議為此使用HTTP存檔。他們定期抓取Web上的熱門站點，并記錄有關幾乎所有內容的詳細信息。根據最新信息，他們已經分析了4,565,694個獨特的網站，這些 網站具有完整的Lighthouse評分，并且為整個數據集存儲了諸如jQuery或WordPress之類的特定技術。Rick Viscomi的巨大道具，他喜歡稱呼自己為“管家”，做得非常出色。

（文： Catalin Rosu 前端開發工程師 Advanced Web Rank 高級程序員）