[ad_1]
不久前，我和我的高級網路排名同事想出了一個 HTML學習 基於從Google排名前20位的搜索結果中收集的大約800萬個索引頁，其中包含3000萬個關鍵字。
我們寫了關於 標記結果 以及排名前20的Google結果頁如何實現它們，然後進一步進行操作並獲得HTML 使用見解 在他們。
這與SEO有什麼關係？
HTML的編寫方式決定了用戶看到的內容以及搜索引擎如何解釋網頁。有效，格式正確的HTML頁面還可以減少搜索引擎可能對結構化數據，元數據，語言或編碼的誤解。
我們打算從一開始就做一次技術性SEO審核：HTML用法的細分以及結果與現代SEO技術和最佳實踐的關係。
在本文中，我們將解決Google可以理解的元標記，JSON-LD結構化數據，語言檢測，標題用法，社交鏈接和元分布，AMP等問題。
Google可以理解的元標記
當談到主要的搜索引擎作為流量來源時，可悲的是只有谷歌和其餘的人，最近Duckduckgo獲得了關注，Bing幾乎不存在。
因此，在本節中，我們將僅關注Google在 Search Console幫助中心。
餅圖顯示了Google可以理解的meta標籤總數，以下部分對此進行了詳細說明。
元描述是〜150個字元的摘要，總結了頁面的內容。當搜索的短語包含在描述中時，搜索引擎會在搜索結果中顯示元描述。
|
選擇器 |
計數 |
|---|---|
|
4,391,448 |
|
|
374,649 |
|
|
13,831 |
在極端情況下，我們發現了685,341個元內容少於30個字元的元和1,293,842個元內容文本超過160個字元的元。
</h3>
<p>從技術上講，標題不是meta標記，而是與meta name =「 description」結合使用。</p>
<p>當涉及SEO時，這是兩個最重要的HTML標籤之一。根據W3C，這也是必須的，這意味著缺少標題標籤的任何頁面均無效。</p>
<p>研究表明，如果您<a href="https://moz.com/learn/seo/title-tag" data-wpel-link="external" target="_self" rel="nofollow external noopener noreferrer"> 標題保持在60個字元以內</a> 那麼您可以期望您的標題可以在SERP中正確呈現。過去，有跡象表明Google的搜索結果標題長度有所延長，但這並不是永久性的變化。</p>
<p>考慮到以上所有內容，我們發現在全部6,263,396個標題中，有1,846,642個標題標籤似乎太長（超過60個字元），而1,985,020個標題的長度卻認為太短（少於30個字元）。</p>
<p><img decoding="async" alt="titles.png" src="https://wpjian.com/wp-content/uploads/2019/10/5d9ce8753cb0a0.97189359.png" width="624" height="280" data-image="t20qt2hyesi2" title="titles.png">餅狀圖顯示了標題標籤的長度分布，長度小於30個字元為31.7％，長度大於60個字元為約29.5％。</p>
<p>標題太短不應該成為問題-畢竟，這取決於網站業務，是主觀的。意義可以用更少的詞來表達，但這絕對是優化機會浪費的跡象。</p>
<table class="table-basic table-row-hover">
<thead>
<tr>
<th>
<p>選擇器</p>
</th>
<th>
<p>計數</p>
</th>
</tr>
</thead>
<tr>
<td><title>*
6,263,396
失蹤 標籤</td>
<td>
<p>1,285,738</p>
<p>
</td>
</tr>
</table>
<p>另一個有趣的事情是，在Google的第1-2頁上排名的網站中，有351,516個（約佔750萬個的5％）在其索引頁上使用相同的標題和h1文本。</p>
<p>另外，您知道嗎，使用HTML5，您只需要指定HTML5文檔類型和標題即可擁有完全有效的頁面？</p>
<p><!DOCTYPE html><br />
<title>紅色
這些元標記可以控制搜索引擎抓取和編製索引的行為。 robots元標記適用於所有搜索引擎，而「 googlebot」元標記特定於Google。」
— Google可以理解的元標記
選擇器
計數
1,577,202
139,458
帶有元漫遊器的HTML代碼段及其內容參數。
所以 機器人元指令 向搜索引擎提供有關如何對頁面內容進行爬網和編製索引的說明。拋開Googlebot元計數這一低點，我們好奇地看到了最頻繁的機器人蔘數，考慮到 誤解是您必須添加一個機器人元 在您的HTML頭部標記。這是前5名：
選擇器
計數
632822
180,226
115,128
111,777
83,639
「當用戶搜索您的網站時，Google搜索結果有時會顯示特定於您網站的搜索框，以及指向您網站的其他直接鏈接。此元標記告訴Google不要顯示附加鏈接搜索框。」
— Google可以理解的元標記
選擇器
計數
1,263
毫不奇怪，當網站出現在搜索結果中時，很少有網站選擇明確告訴Google不要顯示附加鏈接搜索框。
「此meta標籤告訴Google您不希望我們為該頁面提供翻譯。」- Google可以理解的元標記
在某些情況下，可能不希望將您的內容提供給更多的用戶。就像上面的Google支持答案中所說的那樣，此meta標籤告訴Google您不希望他們提供此頁面的翻譯。
選擇器
計數
7,569
「您可以在網站的頂級頁面上使用此標記來驗證Search Console的所有權。」
— Google可以理解的元標記
選擇器
計數
1,327,616
當我們討論這個主題時，您是否知道如果您是Google Analytics（分析）媒體資源的經過驗證的所有者，那麼Google現在將 自動驗證 Search Console中的那個網站？
「這定義了頁面的內容類型和字符集。」
— Google可以理解的元標記
這基本上是好的元標記之一。它定義頁面的內容類型和字符集。考慮到下表，我們注意到我們分析的索引頁中只有大約一半定義了元字符集。
選擇器
計數
3,909,788
「此元標記在一定時間後會將用戶發送到新的URL，有時被用作一種簡單的重定向形式。」
— Google可以理解的元標記
最好使用301重定向而不是元刷新來重定向您的網站，尤其是當我們假設 30倍重定向不會丟失PageRank 和W3C 建議不要使用此標籤。 Google也不是粉絲，建議您使用伺服器端301重定向。
選擇器
計數
7,167
從我們解析的總共750萬個索引頁中，我們發現了7167個使用上述重定向方法的頁。作者並不總是擁有對伺服器端技術的控制權，顯然他們使用此技術來啟用客戶端重定向。
也， 使用工人 是解決與傳統技術堆棧和平台局限性時遇到的問題的一種尖端替代方案。
「此標籤告訴瀏覽器如何在移動設備上呈現頁面。此標籤的存在向Google表示該頁面適合移動設備。」
— Google可以理解的元標記
選擇器
計數
4,992,791
從2019年7月1日開始，所有網站開始使用Google的索引 移動優先索引。 Lighthouse檢查文件頭中是否有meta name =「 viewport」標記，因此無論您使用的是哪種框架或CMS，此meta都應位於每個網頁上。
考慮到上述情況，我們可以預期在分析的750萬個索引頁面中，有超過4,992,791個網站的網站在其頭部使用了有效的meta name =「 viewport」。
設計適合移動設備的網站可確保您的網頁在所有設備上都能正常運行，因此請確保您的頁面 網頁適合移動設備 這裡。
「將頁面標記為包含成人內容，以表明該頁面已被安全搜索結果過濾。」
— Google可以理解的元標記
選擇器
計數
133,387
此標籤用於表示內容的成熟度等級。直到最近，它才被添加到Google可以理解的meta標籤中。看看Kate Morris的這篇文章， 如何標記成人內容。
JSON-LD結構化數據
結構化數據 是用於提供有關頁面信息和對頁面內容進行分類的標準化格式。結構化數據的格式可以是Microdata，RDFa和JSON-LD，所有這些都可以幫助Google了解您網站的內容並觸發頁面的特殊搜索結果功能。
與真棒交談時 丹舒爾，他提出了一個好主意，可以在搜索結果和「知識圖」中查找結構化數據，例如組織的徽標。
在本部分中，我們將僅使用JSON-LD（用於鏈接數據的JavaScript對象表示法）來收集結構化數據信息。這就是Google的建議 無論如何提供有關網頁含義的線索。
一些有用的信息：
- 在Google I / O 2019上宣布 結構化數據 測試工具將由 豐富的結果 測試工具。
- 現在，Googlebot使用 最新鉻 而不是舊的Chrome 42，這意味著您還可以通過結構化數據支持來減輕過去可能遇到的SEO問題。
-
傑森·巴納德（Jason Barnard） 在SMX London 2019上進行了有趣的演講 Google搜索排名如何工作 根據他的理論，我們可以依靠七個排名因素。結構化數據絕對是其中之一。
-
內置可見的Microdata，JSON-LD和Schema.org指南包含了有關在網站上使用結構化數據所需了解的所有信息。
- 這真棒 JSON-LD入門指南 通過 亞歷克西斯·桑德斯（Alexis Sanders）。
- 最後但並非最不重要的一點是，有很多文章，演示文稿和帖子可供正式使用 JSON用於鏈接數據 網站。
高級網路排名的HTML研究僅依賴於分析索引頁面。有趣的是，即使準則中未對此進行說明，但Google似乎並不關心索引頁上的結構化數據，如 堆棧溢出答案 由Gary Illyes於幾年前撰寫。但是，在JSON-LD結構上 Google可以理解的數據類型，我們發現了總共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」（網頁的「首選」版本）來實現。
選擇器
計數
3,183,575
meta name =「 keywords」
這不是新的 已經過時了 Google不再使用它。看起來好像 是大多數搜索引擎的垃圾郵件信號。
「儘管主要搜索引擎不使用元關鍵字進行排名，但它們對於諸如Solr之類的現場搜索引擎非常有用。」
— JP謝爾曼 關於為什麼這個過時的meta在當今仍然有用的原因。
選擇器
計數
2,577,850
256,220
14,127
標題
在750萬頁中，h1（59.6％）和h2（58.9％）是使用最多的28個元素之一。儘管如此，在收集所有標題後，我們發現h3是出現次數最多的標題-在找到的總標題70,428,376中，有29,565,562個h3。
隨機事實：
- h1-h6元素代表節標題的六個級別。這裡有 標題用法的完整統計信息，但我們也找到了23116個h7和7276個h8。這很有趣，因為很多 人們甚至不使用h6s 常常。
- 共有3,046,879個頁面缺少h1標籤，在其餘4,502,255頁中，h1的使用頻率為2.6，共有11,675,565個h1元素。
- 如上所示，雖然有6,263,396個頁面的有效標題，但只有4,502,255個頁面的內容正文中使用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屬性用於識別網路上文本內容的語言。這些信息有助於搜索引擎返回特定於語言的結果，屏幕閱讀器也可以使用這些信息來切換語言配置文件，以提供正確的口音和發音。」
— 萊妮·沃森
不久前，約翰·穆勒（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 Tag Manager使您可以更輕鬆地進行以下操作：
- 通過讓您定義標籤應觸發的時間和用戶操作的自定義規則，來管理這些混亂的標籤
- 隨時更改標籤，而無需實際更改網站的源代碼，由於發布周期緩慢，有時可能會令人頭疼
- 再次與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宣布此事後兩周更新了索引頁數據集。然後，使用Moz授權指標，我們篩選出使用至少rel =「 sponsored」或rel =「 ugc」對之一的頂級URL：
- https://www.seroundtable.com/
- https://letsencrypt.org/
- https://www.newsbomb.gr/
- https://thehackernews.com/
- https://www.ccn.com/
- https://www.chip.pl/
- https://www.gamereactor.se/
- https://www.tribes.co.uk/
安培
加速的移動頁面（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
說到鏈接，我們抓住了所有指向最受歡迎的社交網路的鏈接。
下表顯示了外部社交鏈接分布的餅圖。
選擇器
計數
6,180,313
5,214,768
1,148,828
1,019,970
顯然，仍有許多網站仍鏈接到其Google+個人資料，這可能是出於疏忽考慮 Google+關閉。
rel =上一個/下一個
Google表示，使用rel = prev / next不再是索引信號，正如今年早些時候宣布的那樣：
「在評估索引信號時，我們決定停用rel = prev / next。研究表明，用戶喜歡單頁內容，在可能的情況下盡量做到這一點，但對於Google搜索來說，多部分內容也可以。
— 由Google網站管理員發布
但是，如果對您來說很重要，Bing表示它將它們用作提示以發現頁面和了解網站結構。
「我們將這些標記（如大多數標記）用作頁面發現和網站結構理解的提示。此時，我們不會基於這些頁面將頁面合併在一起，也不會在排名模型中使用prev / next。」
— 弗雷德里克·杜布（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屬性值？
- 我們必須將多少其他元標記或屬性添加到網頁中，才能取悅搜索引擎？我們真的需要新宣布的 數據片段 HTML屬性？下一步是什麼， 數據允許摘要？
我們還希望解決其他問題，例如與排名密切相關的“第一位元組時間''（TTFB）值;我強烈推薦 HTTP檔案 為了那個原因。他們定期抓取Web上的熱門站點，並記錄有關幾乎所有內容的詳細信息。根據最新信息，他們已經分析了 4,565,694個獨特網站，具有完整的Lighthouse評分，並為整個數據集存儲了jQuery或WordPress等特定技術。巨大的道具 里克·維斯科米 他喜歡稱呼自己為「管家」，表現出色。
進行這項大規模研究很有趣。我們學到了很多東西，希望您發現上面的數字和我們一樣有趣。如果您特別想查看標籤或屬性，請在下面的評論中讓我知道。
再次檢查 完整的HTML學習結果 讓我知道你的想法！
6,263,396
這些元標記可以控制搜索引擎抓取和編製索引的行為。 robots元標記適用於所有搜索引擎，而「 googlebot」元標記特定於Google。」
— Google可以理解的元標記
|
選擇器 |
計數 |
|---|---|
|
1,577,202 |
|
|
139,458 |
帶有元漫遊器的HTML代碼段及其內容參數。
所以 機器人元指令 向搜索引擎提供有關如何對頁面內容進行爬網和編製索引的說明。拋開Googlebot元計數這一低點，我們好奇地看到了最頻繁的機器人蔘數，考慮到 誤解是您必須添加一個機器人元 在您的HTML頭部標記。這是前5名：
|
選擇器 |
計數 |
|---|---|
|
632822 |
|
|
180,226 |
|
|
115,128 |
|
|
111,777 |
|
|
83,639 |
「當用戶搜索您的網站時，Google搜索結果有時會顯示特定於您網站的搜索框，以及指向您網站的其他直接鏈接。此元標記告訴Google不要顯示附加鏈接搜索框。」
— Google可以理解的元標記
|
選擇器 |
計數 |
|---|---|
|
1,263
|
毫不奇怪，當網站出現在搜索結果中時，很少有網站選擇明確告訴Google不要顯示附加鏈接搜索框。
「此meta標籤告訴Google您不希望我們為該頁面提供翻譯。」- Google可以理解的元標記
在某些情況下，可能不希望將您的內容提供給更多的用戶。就像上面的Google支持答案中所說的那樣，此meta標籤告訴Google您不希望他們提供此頁面的翻譯。
|
選擇器 |
計數 |
|---|---|
|
7,569 |
「您可以在網站的頂級頁面上使用此標記來驗證Search Console的所有權。」
— Google可以理解的元標記
|
選擇器 |
計數 |
|---|---|
|
1,327,616 |
當我們討論這個主題時，您是否知道如果您是Google Analytics（分析）媒體資源的經過驗證的所有者，那麼Google現在將 自動驗證 Search Console中的那個網站？
「這定義了頁面的內容類型和字符集。」
— Google可以理解的元標記
這基本上是好的元標記之一。它定義頁面的內容類型和字符集。考慮到下表，我們注意到我們分析的索引頁中只有大約一半定義了元字符集。
|
選擇器 |
計數 |
|---|---|
|
3,909,788 |
「此元標記在一定時間後會將用戶發送到新的URL，有時被用作一種簡單的重定向形式。」
— Google可以理解的元標記
最好使用301重定向而不是元刷新來重定向您的網站，尤其是當我們假設 30倍重定向不會丟失PageRank 和W3C 建議不要使用此標籤。 Google也不是粉絲，建議您使用伺服器端301重定向。
|
選擇器 |
計數 |
|---|---|
|
7,167 |
從我們解析的總共750萬個索引頁中，我們發現了7167個使用上述重定向方法的頁。作者並不總是擁有對伺服器端技術的控制權，顯然他們使用此技術來啟用客戶端重定向。
也， 使用工人 是解決與傳統技術堆棧和平台局限性時遇到的問題的一種尖端替代方案。
「此標籤告訴瀏覽器如何在移動設備上呈現頁面。此標籤的存在向Google表示該頁面適合移動設備。」
— Google可以理解的元標記
|
選擇器 |
計數 |
|---|---|
|
4,992,791 |
從2019年7月1日開始，所有網站開始使用Google的索引 移動優先索引。 Lighthouse檢查文件頭中是否有meta name =「 viewport」標記，因此無論您使用的是哪種框架或CMS，此meta都應位於每個網頁上。
考慮到上述情況，我們可以預期在分析的750萬個索引頁面中，有超過4,992,791個網站的網站在其頭部使用了有效的meta name =「 viewport」。
設計適合移動設備的網站可確保您的網頁在所有設備上都能正常運行，因此請確保您的頁面 網頁適合移動設備 這裡。
「將頁面標記為包含成人內容，以表明該頁面已被安全搜索結果過濾。」
— Google可以理解的元標記
|
選擇器 |
計數 |
|---|---|
|
133,387 |
|
此標籤用於表示內容的成熟度等級。直到最近，它才被添加到Google可以理解的meta標籤中。看看Kate Morris的這篇文章， 如何標記成人內容。
JSON-LD結構化數據
結構化數據 是用於提供有關頁面信息和對頁面內容進行分類的標準化格式。結構化數據的格式可以是Microdata，RDFa和JSON-LD，所有這些都可以幫助Google了解您網站的內容並觸發頁面的特殊搜索結果功能。
與真棒交談時 丹舒爾，他提出了一個好主意，可以在搜索結果和「知識圖」中查找結構化數據，例如組織的徽標。
在本部分中，我們將僅使用JSON-LD（用於鏈接數據的JavaScript對象表示法）來收集結構化數據信息。這就是Google的建議 無論如何提供有關網頁含義的線索。
一些有用的信息：
- 在Google I / O 2019上宣布 結構化數據 測試工具將由 豐富的結果 測試工具。
- 現在，Googlebot使用 最新鉻 而不是舊的Chrome 42，這意味著您還可以通過結構化數據支持來減輕過去可能遇到的SEO問題。
- 傑森·巴納德（Jason Barnard） 在SMX London 2019上進行了有趣的演講 Google搜索排名如何工作 根據他的理論，我們可以依靠七個排名因素。結構化數據絕對是其中之一。
- 內置可見的Microdata，JSON-LD和Schema.org指南包含了有關在網站上使用結構化數據所需了解的所有信息。
- 這真棒 JSON-LD入門指南 通過 亞歷克西斯·桑德斯（Alexis Sanders）。
- 最後但並非最不重要的一點是，有很多文章，演示文稿和帖子可供正式使用 JSON用於鏈接數據 網站。
高級網路排名的HTML研究僅依賴於分析索引頁面。有趣的是，即使準則中未對此進行說明，但Google似乎並不關心索引頁上的結構化數據，如 堆棧溢出答案 由Gary Illyes於幾年前撰寫。但是，在JSON-LD結構上 Google可以理解的數據類型，我們發現了總共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」（網頁的「首選」版本）來實現。
|
選擇器 |
計數 |
|---|---|
|
3,183,575 |
meta name =「 keywords」
這不是新的 已經過時了 Google不再使用它。看起來好像 是大多數搜索引擎的垃圾郵件信號。
「儘管主要搜索引擎不使用元關鍵字進行排名，但它們對於諸如Solr之類的現場搜索引擎非常有用。」
— JP謝爾曼 關於為什麼這個過時的meta在當今仍然有用的原因。
|
選擇器 |
計數 |
|---|---|
|
2,577,850 |
|
|
256,220 |
|
|
14,127 |
標題
在750萬頁中，h1（59.6％）和h2（58.9％）是使用最多的28個元素之一。儘管如此，在收集所有標題後，我們發現h3是出現次數最多的標題-在找到的總標題70,428,376中，有29,565,562個h3。
隨機事實：
- h1-h6元素代表節標題的六個級別。這裡有 標題用法的完整統計信息，但我們也找到了23116個h7和7276個h8。這很有趣，因為很多 人們甚至不使用h6s 常常。
- 共有3,046,879個頁面缺少h1標籤，在其餘4,502,255頁中，h1的使用頻率為2.6，共有11,675,565個h1元素。
- 如上所示，雖然有6,263,396個頁面的有效標題，但只有4,502,255個頁面的內容正文中使用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屬性用於識別網路上文本內容的語言。這些信息有助於搜索引擎返回特定於語言的結果，屏幕閱讀器也可以使用這些信息來切換語言配置文件，以提供正確的口音和發音。」
— 萊妮·沃森
不久前，約翰·穆勒（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 Tag Manager使您可以更輕鬆地進行以下操作：
- 通過讓您定義標籤應觸發的時間和用戶操作的自定義規則，來管理這些混亂的標籤
- 隨時更改標籤，而無需實際更改網站的源代碼，由於發布周期緩慢，有時可能會令人頭疼
- 再次與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宣布此事後兩周更新了索引頁數據集。然後，使用Moz授權指標，我們篩選出使用至少rel =「 sponsored」或rel =「 ugc」對之一的頂級URL：
- https://www.seroundtable.com/
- https://letsencrypt.org/
- https://www.newsbomb.gr/
- https://thehackernews.com/
- https://www.ccn.com/
- https://www.chip.pl/
- https://www.gamereactor.se/
- https://www.tribes.co.uk/
安培
加速的移動頁面（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 |
說到鏈接，我們抓住了所有指向最受歡迎的社交網路的鏈接。
下表顯示了外部社交鏈接分布的餅圖。
|
選擇器 |
計數 |
|---|---|
|
6,180,313 |
|
|
5,214,768 |
|
|
1,148,828 |
|
|
1,019,970 |
顯然，仍有許多網站仍鏈接到其Google+個人資料，這可能是出於疏忽考慮 Google+關閉。
rel =上一個/下一個
Google表示，使用rel = prev / next不再是索引信號，正如今年早些時候宣布的那樣：
「在評估索引信號時，我們決定停用rel = prev / next。研究表明，用戶喜歡單頁內容，在可能的情況下盡量做到這一點，但對於Google搜索來說，多部分內容也可以。
— 由Google網站管理員發布
但是，如果對您來說很重要，Bing表示它將它們用作提示以發現頁面和了解網站結構。
「我們將這些標記（如大多數標記）用作頁面發現和網站結構理解的提示。此時，我們不會基於這些頁面將頁面合併在一起，也不會在排名模型中使用prev / next。」
— 弗雷德里克·杜布（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屬性值？
- 我們必須將多少其他元標記或屬性添加到網頁中，才能取悅搜索引擎？我們真的需要新宣布的 數據片段 HTML屬性？下一步是什麼， 數據允許摘要？
我們還希望解決其他問題，例如與排名密切相關的“第一位元組時間''（TTFB）值;我強烈推薦 HTTP檔案 為了那個原因。他們定期抓取Web上的熱門站點，並記錄有關幾乎所有內容的詳細信息。根據最新信息，他們已經分析了 4,565,694個獨特網站，具有完整的Lighthouse評分，並為整個數據集存儲了jQuery或WordPress等特定技術。巨大的道具 里克·維斯科米 他喜歡稱呼自己為「管家」，表現出色。
進行這項大規模研究很有趣。我們學到了很多東西，希望您發現上面的數字和我們一樣有趣。如果您特別想查看標籤或屬性，請在下面的評論中讓我知道。
再次檢查 完整的HTML學習結果 讓我知道你的想法！