信最近很多小伙伴在逛Dribbble時候，發現最近流行一波新的設計風格，和以往不同的是，這次趨勢又回到之前擬物化了，但它與純擬物化還是有區別的，現在它有一個流行詞語叫“新擬態”，今天就和大家分享下國外一位設計師對這個趨勢的看法！

譯文如下：

一、擬態化是什么？

雖然UI以各種擬態化的形式存在（例如，您的桌面OS垃圾桶），現在這種風格的趨勢更加明顯。正如卡米爾·法拉納（Kamil Falana）指出的那樣，從無生命的“表達”到現實主義的過渡開始出現。

不久前，我們還觀察到，這種變化開始在我們身邊發生，蘋果（iOS13系統）就是一個很好的例子。向最小化設計和輕擬物化發展，最終帶來了無紋理3D視覺感官。受到了大家的喜歡，來看一張高清圖。

Apple Pencil

二、擬物化風格的回歸，會更好嗎？

如下圖設計風格，在dribbble上獲得認可度比較高！

Dribbble用戶alexplyuto的作品獲得了四千多次贊，并帶動了這一趨勢。

這種設計引發了一波設計潮流趨勢，盡管其中的有部分并沒有實際意義（可滑動的后退箭頭？），但這使我們對UI 再次產生濃厚的興趣！

備注：可看出目前扁平化設計過于雷同，用戶審美疲勞。偶爾出現新設計趨勢風格，反而更個給各位設計師們帶來新鮮感！

三、新風格的特征點

由于按鈕的視覺表現看著變化不大（因為小了一些，不直觀），因此我們將重點放在實際的卡片概念上，以使這種視覺表現更能直觀感受出來。

擬態化卡片（左圖）、現代材料卡片（右圖）

如現代材料（升級版）卡片，通常是在畫布中以浮層的形式出現，厚度更加明顯。陰影既可以增加深度，也可以在很多情況下定義形狀本身，因為陰影通常是無邊界的。

擬態化卡片從背景中突出。它是由與背景顏色完全相同的卡片制成的凸起形狀。當我們從側面看時，它不會浮起來。

通過調節兩個陰影，一個陰影為負值，另一個陰影為正值，很容易實現此效果。但是要使其正常顯示，我們的背景不能是全黑或全白。它至少需要一點色調，以便可見“深色”和“淺色”陰影。您可以使用任何色調作為背景，以便根據您的選擇將其變暖或變冷。但是必須能看到深色或者淺色投影。

這是例子，根據您的喜好進行調整：

四、優缺點

這種風格的主要好處是“新鮮”（至少持續很長時間）。它為界面帶來了“新感覺”，并使其脫穎而出。它也可以與其他樣式混合使用，這樣就避免很呆板整個畫面變成這種柔軟凸起的效果。

到目前為止，有一些問題需要解決。我們發現了兩個主要問題：

1. 可見性
2. 易用性

1. 可見性

圖形與背景對比度的主要問題是，當它們都是相同的顏色時，就沒有可測量的對比度；客觀上存在陰影，因此我們可以近似并嘗試測量其外部的第一個像素。

在上面的示例中，我們得出了這些對比度值：

如您所見，現代材料卡片和新擬態化卡片的對比度都非常低。并且卡片本身并不用于主要的操作控件上（只是一個背景），只要我們保持按鈕突出并具有足夠高的對比度，就可以了。

兩者之間的差異很小，如果我們想為卡片使用更好的對比度，我們就必須這樣做：

而且由于幾乎沒有人會嘗試使用如此強烈的陰影，這意味著其余UI元素必須可訪問。這種假設得出的結論是，如果我們通過版式，相近度和與重要元素的對比來進行正確的層次劃分，那么這些卡片/凸起的塑料卡片并不那么重要。

尚未對此進行測試（我將嘗試找到時間做這件事），但現在我們假設下面元素的兩個“版本”均為“確定”。即使有些人看不到陰影，也有足夠的對比度讓他們看到圖標并“使用它”。

2. 易用性

盡管“按鈕”看起來像按鈕，但是如果圖標本身與背景形成鮮明對比，它將仍然有效。因此，這里要記住的主要事情是，如果要使用這種樣式，請以足夠高的對比度保留所有重要元素。

畢竟，大多數“現代材料”卡片視圖也不會通過陰影來做對比。

五、僅僅是卡片嗎？

但是，如果我們決定將組件用作按鈕而不是卡片，則會出現可訪問性的主要問題。

我們可以像下面的示例一樣輕松創建帶有內部陰影的按下狀態。

對比度測試

這里的問題實際上很大。

此按下狀態的對比度太小，不足以表示差異。是否可以通過改變的其余部分來表達按鈕的狀態，這里有一些想法，例如使用輪廓和填充圖標，下劃線或甚至用顏色填充按下狀態。

嘗試各種想法，但狀態必須立即被識別。

六、開發

開發實現其實它比我們認為的在CSS中實現“軟陰影”外觀要容易。我們尚未研究Swift和Kotlin，但我認為這不應該成為問題。

https://neumorphism.io/#55b9f3（實現新擬態效果CSS代碼）

七、其他影響

剛才說的形狀只是一方面。這種設計新樣式還帶有更多的按鈕和圖標。通常情況下，我們只需要回到“過去的美好時光”并使用位圖。這似乎是一種回歸，不必擔心-這是沒有必要的。

您可以輕松地將可開發的設計與這些卡片形狀組合在一起（新擬態卡片），從而獲得很好的效果。

作者練習的稿子（還未發布，還在設計中）

八、我們真的需要這些嗎？

盡管這一新趨勢影響了許多設計師，但對比以前使用的卡片組件可訪問性問題相比，它的問題并不那么嚴重。

所以去瘋狂的順應這一趨勢，并對其進行調整以使其成為您的趨勢。UI設計師的工作就是需要不斷來回挑戰自我，探索最新潮流，以符合產品審美。如果沒有這種不斷的探索的精神，所有產品將再次看起來相同，同質化嚴重。

但也要記住，每個新趨勢都帶有不可抗拒性因素，如果要使用，必須精心的設計探索， 驗證后才拿去面對用戶。

九、個人感悟

本篇文章，作者通過對新擬態設計趨勢分析，在文中提及“新擬態”和以前材料卡片的區別，同時證實了新擬態風格優勢！但也存在一定的弊端！如何去權衡與設計的把控，需要設計師們多去研究探索！

就我個人而言，我認為目前新擬態設計風格，其實更適合像車機那種偏實體硬件的HMI設計又或者智能硬件平臺，智能櫥窗，智能鏡等，但是如果在移動端去使用，那么需要去適當做簡化。如何去簡化以適應新趨勢，這需要不斷去嘗試。

最后作者也說了新擬態設計風格，需要注意的是對比度問題，需要將該效果應用到合適的位置，如果是操作組件上，那么它的反饋態和常態都需要有明顯的對比。

這一趨勢如果要盛行起來，需要大廠來引領，比如今年蘋果會出現的IOS14或者Google材料3.0到來。扁平化是蘋果帶來的，材料設計師google帶來的。

如今新擬態才初出茅廬，還未被廣泛使用，需要有先驅者引領。畢竟國內的環境大家都不敢冒險去嘗試運用到線上！

原文：https://uxdesign.cc/neumorphism-in-user-interfaces-b47cef3bf3a6

作者：Michal Malewicz

編譯作者：Tony，微信公眾號：功夫UX，人人都是產品經理專欄作家。百度設計師。很樂意幫助年輕設計師成長，簡歷指導，每周分享最有價值的設計經驗，擅長產品體驗設計。

本文由@Tony 翻譯發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議

T之家 7 月 11 日消息，微軟公司在 7 月補丁星期二發布的 Windows 10、Windows 11 系統累積更新中，修復了追蹤編號為 CVE-2024-38112 的零日漏洞。

該零日漏洞由 Check Point Research 的安全專家李海飛（Haifei Li，音譯）于 2023 年 1 月發現，是一個高度嚴重的 MHTML 欺騙問題，有證據表明有黑客在過去 18 個月里，利用該漏洞發起惡意攻擊，可以繞過 Windows 10、Windows 11 系統的安全功能。

該專家發現網絡攻擊者通過分發 Windows Internet 快捷方式文件（.url），以欺騙 PDF 等看起來合法的文件，用戶一旦點開這些文件，就會下載并啟動 HTA 以安裝密碼竊取惡意軟件。

Internet 快捷方式文件只是一個文本文件，其中包含各種配置設置，如顯示什么圖標、雙擊時打開什么鏈接等信息。保存為 .url 文件并雙擊后，Windows 將在默認網絡瀏覽器中打開配置的 URL。

不過攻擊者發現可以通過在 URL 指令中使用 mhtml: URI 處理程序，來強制 Internet Explorer 打開指定的 URL，如下圖所示：

IT之家注：MHTML 是一種 "聚合 HTML 文檔的 MIME 封裝" 文件，是 Internet Explorer 中引入的一種技術，可將包括圖像在內的整個網頁封裝成一個單一的檔案。

攻擊者使用 mhtml: URI 啟動 URL 后，Windows 會自動在 Internet Explorer 中啟動 URL，而不是默認瀏覽器。

漏洞研究人員 Will Dormann 稱，在 Internet Explorer 中打開網頁會給攻擊者帶來額外的好處，下載惡意文件時安全警告較少。

盡管微軟早在兩年前就宣布停止支持該瀏覽器，并以 Edge 代替其所有實用功能，但這款過時的瀏覽器仍可被惡意調用和利用。

外一個研究團隊進行了一項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 高級程序員）