SEO如何處理內容和鏈接
在過去幾年里，SEO一直在做的大部分工作已經轉化為更多內容的創建，以實現更多的鏈接。 我不知道，加入任何圍繞如何討論縮放內容或建立更多的聯系是價值在這一點，但我懷疑有現有的鏈接和內容是不是頂級的頭腦讓許多人一些機會。
Google首先查看實體,實體是Google在其系統中表示專有名詞以區分人，地點和事物，并告知他們對自然語言的理解。 在這一點上，我要求人們舉手，如果他們有一個實體戰略。 在這一點上我已經說了十幾次，只有兩個人舉手。
比爾•斯拉夫斯基是這個主題的最重要的思想領袖，所以我會推遲他的智慧，鼓勵你閱讀：

我也建議你使用像一個自然語言處理工具AlchemyAPI或MonkeyLearn 。 更妙的是，使用谷歌自己的自然語言處理API提取實體。 標準關鍵字研究與實體策略之間的區別在于，您的實體策略需要從現有內容構建。 因此，在識別實體時，您需要先進行關鍵字研究，然后通過實體提取工具運行這些著陸頁，以了解它們的排列方式。 您還需要通過相同的實體提取API運行競爭對手的目標網頁，以確定要為這些關鍵字定位的實體。
TF * IDF
類似地，術語頻率/反文檔頻率或TF * IDF是一種自然語言處理技術，在池塘的這一側沒有太多討論。 事實上，主題建模算法一直的主題在過去SEO界備受激烈的辯論 。 關注的問題是主題建模工具傾向于推動我們回到關鍵字密度的黑暗時代，而不是考慮創建對用戶有用的內容的想法。 然而，在許多歐洲國家，他們通過TF * IDF（或WDF * IDF-在文檔頻率/反向文檔頻率內）發布作為一種關鍵技術，即使沒有鏈接也能提高有機可見性。
 
在德國的掛了一下后，去年，一些人能說服我， 我們再看一下TF * IDF是值得的。 所以，我們做了，然后我們開始工作到我們的內容優化過程。
在Searchmetrics 2014年的排名因素研究中，他們發現，雖然TF * IDF實際上與可見性有負相關，但相關和證明項具有強正相關。
 
通過圖像Searchmetrics
根據對這些因素的檢查，Searchmetrics發出呼吁，從2015年的分析中刪除TF * IDF，贊成證明條款和相關術語。 年復一年，這些類型的術語的正相關性雖然不高。
 
通過圖片Searchmetrics
 
在莫茲自己2015年的排名因素 ，我們發現，LDA和TF * IDF相關項目留在最高頁面內容的因素。
 
實際上，無論您查看什么模型，一般的想法是在副本中使用相關關鍵字，以便為主要目標關鍵字排名更好，因為它的工作原理。
現在，我不能說我們孤立地研究了這個策略，但我可以說，我們使用TF * IDF優化的頁面在排名上比沒有它的頁面有更大的跳躍。 雖然我們利用OnPage.org的TF * IDF的工具 ，我們不使用硬性數值規則遵循它。 相反，我們允許相關的關鍵字影響觀念，然后在它們有意義時使用它們。
至少，這種內容的技術優化順序需要重新審視。 當你在它，你應該考慮其他的戰術，賽勒斯•謝潑德叫出來 ，以獲得更多的里程從您的內容營銷工作為好。
302s vs 301s - 認真？
到后來，301對302重新定向的重新檢查在SEO回波室中恢復了。 我得到的感覺，網站管理員趨勢分析師在公眾的眼睛既喜歡關注或只是無聊，所以他們會發布模糊的tweets只是看看會發生什么。
對于那些喜歡做工作而不是等待Gary Illyes發短信的人，我得到的是一些數據要分享。
過了一段時間，我們與一家大型媒體組織合作。 作為與這些類型的組織的課程標準，他們的技術團隊抵制執行我們的大多數建議。 然而，他們在內部和外部有數百萬個鏈接，指向返回302響應代碼的URL。
經過許多會議，以及一個更加引人注目的商業案例，我們能夠說服他們做的一件大事是將302s切換到301s。 幾乎一夜之間，1-3級區域的排名有所增加。
 
盡管季節性，有機搜索的流量也有一個跳躍。
重申，這一點上的唯一重大變化是302到301開關。 它導致幾個月有機搜索訪問月份。 當然，這是一年前，但直到有人可以告訴我同樣的事情或沒有交通損失，當你從301轉換到302，沒有討論我們有。
內部鏈接，技術方法
在PageRank模型下，鏈接公平通過網站的流是一個非常重要的組成部分來檢查是一個公理。 遺憾的是，這么多與客戶的討論僅僅是對外部鏈接，而不是如何更好地最大化網站已經擁有環節股權。
有很多工具，把這個概念帶到最前列。 例如， Searchmetrics計算和可視化鏈接股權整個網站的流量。 這給你一個感覺，你可以建立內部鏈接，使其他頁面更強。
 
此外，保羅•夏皮羅放在一起在一個引人注目的職位，你如何計算出一個內部版本的PageRank免費使用統計計算軟件- [R 。
 
這兩種方法都對提供更多內容的可見性非常有價值，并且非常落入什么技術SEO可以提供。
結構化數據是有機搜索的未來
流行的一線是Google正在尋求成為網絡的表示層。 我說， 幫他們做到這一點！
有很多關于Google如何使用我們的內容，并試圖把我們自己的網站從圖片。 隨著業界從網站上看到的交通便利，它成為了功能的代碼段，很明顯，在許多情況下，您在Google獲取您的內容比在他們沒有更多的價值。
使用移動設備上的Vocal Search設備和即將推出的Google首頁，用戶只能收到一個答案。 也就是說，Google正在構建的星際迷航計算機不會讀取每個結果 - 只有一個。 這些答案是由燃料豐富的卡和特色片段，它們又被結構化數據推動。
 
在更新允許JSON-LD的規范時，Google實際上已經使我們對結構化數據有很大的幫助。 在此之前，Schema.org是對代碼進行非常繁瑣和具體的更改，而沒有投資回報的問題。 現在結構化數據為SERP的許多組件提供了能力，并且可以很容易地放置在文檔的

。 現在是重新考慮實施額外的標記時間。 Builtvisible指南結構化數據仍然是黃金標準。
網頁速度仍然是Google的癡迷
Google對網頁速度有非常積極的期望，特別是對于移動上下文。 他們希望在一秒鐘內載入首屏內容。 然而，那800毫秒的時間是你的控制。
 
通過圖像谷歌
根據你可以直接影響，作為一個SEO，你有200毫秒，使內容出現在屏幕上。 在頁面上可以做很多事情，以影響事物負載優化頁面的臨界呈現路徑的速度。
 
通過圖像Nianpeng李
要理解這個概念，首先我們需要一點一點，以了解瀏覽器如何構造一個網頁。
瀏覽器使用您在地址欄中指定的統一資源定位符（URL），并對域名執行DNS查找。
一旦套接字打開并且協商了一個連接，它就會向服務器詢問您請求的頁面的HTML。
瀏覽器開始將HTML解析成文檔對象模型，直到遇到CSS，然后開始將CSS解析為CSS對象模型。
如果在任何時候它運行到JavaScript，它將暫停DOM和/或CSSOM結構，直到JavaScript完成執行，除非它是異步的。
一旦所有這些完成，瀏覽器構造渲染樹，然后構建頁面的布局，最后頁面的元素被繪制。

 
在Chrome DevTools的時間軸部分中，您可以看到各個操作發生的時間以及它們對加載時間的影響。 在頂部的時間軸中，您將始終將可視化視為黃色，因為JavaScript執行占用頁面構建的任何部分的最多時間。 JavaScript導致頁面構造停止，直到腳本執行完成。 這被稱為“渲染阻塞”JavaScript。
 
這個字詞可能聽起來很熟悉，因為您在PageSpeed Insights中搜索了解如何進行改進的問題，而“消除渲染阻塞JavaScript”是一個常見的問題。 該工具主要用于支持關鍵渲染路徑的優化。 許多建議涉及靜態地調整資源大小，使用異步腳本和指定圖像維度等問題。
 
此外，外部資源顯著影響頁面加載時間。 例如，我總是看到Chartbeat的庫需要3秒或更長的時間才能解決DNS。 在考慮如何更快地加載網頁時，這些都是需要審核的。
如果你很了解加速移動頁（AMP）規范，很多我剛才強調聽起來你很熟悉。
 
基本上，AMP存在，因為Google認為公眾對編碼不好。 所以他們制作了HTML的一個子集，并在其后面投入了一個全局CDN，使您的網頁達到1秒的標記。 就我個人而言，我對AMP非常反感，但是我們很多人預計在今年年初，Google已經超越了媒體垂直和SERP中的所有類型的頁面。 該路線圖表明，有很多更到來 ，所以這絕對是值得我們深入探討，并期待利用。
使用預瀏覽指令加快速度
為了支持網站速度提升，大多數瀏覽器在瀏覽預資源的提示。這些提示，可以指定到該文件將在頁面以后需要的瀏覽器，因此，盡管瀏覽器的組成部分是閑置的，它可以下載或連接到那些資源。 Chrome特別考慮在可能時自動執行這些操作，并且可能完全忽略您的規范。 然而，這些指令的操作與rel-canonical標簽非常相似 - 你更可能從中獲得價值。
 
通過圖像谷歌
相對-PRECONNECT -本指令的 讓您解決DNS，啟動TCP握手，并在您需要之前協商客戶端和服務器之間的TLS隧道。 當你不這樣做時，這些事情對于每個資源一個接一個地發生，而不是同時發生。 如下圖所示，在某些情況下，你可以剃須近半秒，只是這樣做。 或
相對預取 -該指令允許你下載一個資源，這將在未來需要的頁面。 例如，如果您想拉下一頁的樣式表或下載下一頁的HTML，您可以將其指定為
 

    
REL-的prerender -不與上述Prerender.io混淆，REL-的prerender是一個指令，它可以讓你在不可見的選項卡中加載整個頁面及其所有資源。 一旦用戶點擊鏈接轉到該網址，該網頁就會立即顯示。 如果用戶改為點擊您未指定為關聯預先渲染器的鏈接，則預渲染頁面將從內存中刪除。 您指定rel-prerender如下：
 

我已經談到了REL-的prerender過去在我的一篇關于我如何與一行代碼，改善了我們的網站的速度68.35％ 。
 
有許多注意事項都帶有rel-prerender，但最重要的一個是，你只能一次指定一個頁面，并且只能在所有Chrome線程中指定一個rel-prerender。 在我的文章中，我將討論如何利用Google Analytics（分析）API對用戶下一步可能訪問的網址進行最佳猜測。

如果您使用的分析套件不是Google Analytics（分析），或者您的網頁上有廣告，則會錯誤地將預渲染匹配數計為該網頁的實際觀看次數。 什么，你會想要做的就是包裝，你不想火，直到頁面實際上是針對任何JavaScript的網頁瀏覽權限API 。 實際上，只有當網頁實際可見時，您才會啟用分析或展示廣告。
 

最后，請記住，rel-prerender不適用于Firefox，iOS Safari，Opera Mini或Android的瀏覽器。 不知道為什么他們沒有被邀請參加預派對，但我不會建議使用它在移動設備上。
 
相對-預緊和rel-子資源 -千篇一律如上，REL-預緊和rel-子資源讓你需要它們之前在同一頁面內加載的東西。 Rel-subresource是特定于Chrome的，而rel-preload適用于Chrome，Android和Opera。
最后，請記住，Chrome是足夠復雜的，以嘗試所有這些事情。 你的資源提示幫助他們發展100％的置信水平來對他們采取行動。 Chrome會根據您在地址欄中輸入的內容進行一系列預測，并會跟蹤是否進行了正確的預測，以確定要為您預先連接和預呈現的內容。 退房鉻：//預測看到Chrome瀏覽器已根據您的行為預測什么。
 
通過圖像谷歌
SEO從哪里來？
作為一個強大的SEO需要一系列的技能，對一個人來說很難在一個偉大的。 例如，具有強大技術技能的SEO可能發現難以執行有效的推廣，反之亦然。 自然地，SEO已經以這種方式在頁面和頁面之間分層。 然而，技術技能要求在過去幾年中持續顯著增長。
有一些技能，總是給技術SEO一個不公平的優勢，如網絡和軟件開發技能，甚至統計建模技能。 也許是時候正式進一步分層技術SEO從傳統的內容驅動的頁面優化，因為所需的技能更多的是Web開發人員和網絡管理員，而不是通常被認為是SEO（至少在這個在游戲中的階段）。 作為一個行業，我們應該考慮一個SEO工程師的作用，因為一些組織已經有。
至少，SEO工程師需要掌握以下所有內容才能真正利用這些技術機會：
文檔對象型 1 - Web瀏覽器的積木的理解是理解基礎如何，我們的前端開發人員如何操縱網絡作為他們建造它。
關鍵渲染路徑 -一個瀏覽器如何構建一個頁面，什么進入頁面的渲染將隨著速度提升，谷歌正在更加積極地幫助需要的理解。
結構化數據和標記 -被提出的如何被指定的元數據來影響谷歌如何理解信息的理解。
網頁速度 -編碼其余的理解和網絡組件的影響頁面加載時間是自然的下一步讓網頁加速。 當然，這是一個比SEO更大的事情，因為它影響一般的用戶體驗。
日志文件分析 -的搜索引擎如何遍歷網站，他們認為重要和方便的東西理解是必需的，尤其是與新的前端技術的出現。
搜索引擎優化的JavaScript框架 -利用為前端開發流行的框架之一的影響，以及需要多，為什么，以及何時可能需要HTML快照設備以及如何實現它們的詳細了解的理解是至關重要的。 就在幾天前，賈斯汀•布里格斯收集大部分的知識對這個話題在一個地方，并打破它歸結為它的組件。 我鼓勵你看看。
鉻DevTools -在搜索引擎優化工具包，Chrome網絡瀏覽器本身的大部分有力的工具之一的理解。 Chrome DevTools的功能以及一些第三方插件彌補了SEO工具目前無法分析的許多問題的差距。 SEO工程師需要能夠快速構建一些東西，以獲得我們行業以前沒有處理的問題的答案。
Acclerated移動頁和 Facebook的即時頁面 -如果AMP路線圖是任何跡象顯示，Facebook的即時頁面是一個類似的規范，我懷疑這將是他們難以繼續獨占存在。
HTTP / 2 -如何該協議將極大地改變網頁的速度和HTTP 1.1遷移/的搜索引擎優化的意義的理解。
讓我們再次使SEO偉大
 
其中一個總是使SEO有趣的事情，其思想領袖如此引人注目的是，我們測試，學習和分享了那么多的知識。 看來，測試和學習的文化被淹沒在內容洪水。 也許許多類型的人都消失了，因為他們知道和喜愛的策略被谷歌的動物園動物吞噬。 也許我們不斷侵蝕的數據使得越來越難得出有力的結論。

移動商務應用實例設計
Web與MTV在潘多拉的新品