SEO如何處理內(nèi)容和鏈接

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

我也建議你使用像一個自然語言處理工具AlchemyAPI或MonkeyLearn 。 更妙的是，使用谷歌自己的自然語言處理API提取實體。 標(biāo)準(zhǔn)關(guān)鍵字研究與實體策略之間的區(qū)別在于，您的實體策略需要從現(xiàn)有內(nèi)容構(gòu)建。 因此，在識別實體時，您需要先進行關(guān)鍵字研究，然后通過實體提取工具運行這些著陸頁，以了解它們的排列方式。 您還需要通過相同的實體提取API運行競爭對手的目標(biāo)網(wǎng)頁，以確定要為這些關(guān)鍵字定位的實體。
TF * IDF
類似地，術(shù)語頻率/反文檔頻率或TF * IDF是一種自然語言處理技術(shù)，在池塘的這一側(cè)沒有太多討論。 事實上，主題建模算法一直的主題在過去SEO界備受激烈的辯論 。 關(guān)注的問題是主題建模工具傾向于推動我們回到關(guān)鍵字密度的黑暗時代，而不是考慮創(chuàng)建對用戶有用的內(nèi)容的想法。 然而，在許多歐洲國家，他們通過TF * IDF（或WDF * IDF-在文檔頻率/反向文檔頻率內(nèi)）發(fā)布作為一種關(guān)鍵技術(shù)，即使沒有鏈接也能提高有機可見性。

在德國的掛了一下后，去年，一些人能說服我， 我們再看一下TF * IDF是值得的。 所以，我們做了，然后我們開始工作到我們的內(nèi)容優(yōu)化過程。
在Searchmetrics 2014年的排名因素研究中，他們發(fā)現(xiàn)，雖然TF * IDF實際上與可見性有負(fù)相關(guān)，但相關(guān)和證明項具有強正相關(guān)。
通過圖像Searchmetrics
根據(jù)對這些因素的檢查，Searchmetrics發(fā)出呼吁，從2015年的分析中刪除TF * IDF，贊成證明條款和相關(guān)術(shù)語。 年復(fù)一年，這些類型的術(shù)語的正相關(guān)性雖然不高。
通過圖片Searchmetrics
在莫茲自己2015年的排名因素 ，我們發(fā)現(xiàn)，LDA和TF * IDF相關(guān)項目留在高頁面內(nèi)容的因素。
實際上，無論您查看什么模型，一般的想法是在副本中使用相關(guān)關(guān)鍵字，以便為主要目標(biāo)關(guān)鍵字排名更好，因為它的工作原理。
現(xiàn)在，我不能說我們孤立地研究了這個策略，但我可以說，我們使用TF * IDF優(yōu)化的頁面在排名上比沒有它的頁面有更大的跳躍。 雖然我們利用OnPage.org的TF * IDF的工具 ，我們不使用硬性數(shù)值規(guī)則遵循它。 相反，我們允許相關(guān)的關(guān)鍵字影響觀念，然后在它們有意義時使用它們。
至少，這種內(nèi)容的技術(shù)優(yōu)化順序需要重新審視。 當(dāng)你在它，你應(yīng)該考慮其他的戰(zhàn)術(shù)，賽勒斯•謝潑德叫出來 ，以獲得更多的里程從您的內(nèi)容營銷工作為好。
302s vs 301s - 認(rèn)真？
到后來，301對302重新定向的重新檢查在SEO回波室中恢復(fù)了。 我得到的感覺，網(wǎng)站管理員趨勢分析師在公眾的眼睛既喜歡關(guān)注或只是無聊，所以他們會發(fā)布模糊的tweets只是看看會發(fā)生什么。
對于那些喜歡做工作而不是等待Gary Illyes發(fā)短信的人，我得到的是一些數(shù)據(jù)要分享。
過了一段時間，我們與一家大型媒體組織合作。 作為與這些類型的組織的課程標(biāo)準(zhǔn)，他們的技術(shù)團隊抵制執(zhí)行我們的大多數(shù)建議。 然而，他們在內(nèi)部和外部有數(shù)百萬個鏈接，指向返回302響應(yīng)代碼的URL。
經(jīng)過許多會議，以及一個更加引人注目的商業(yè)案例，我們能夠說服他們做的一件大事是將302s切換到301s。 幾乎一夜之間，1-3級區(qū)域的排名有所增加。

盡管季節(jié)性，有機搜索的流量也有一個跳躍。
重申，這一點上的唯一重大變化是302到301開關(guān)。 它導(dǎo)致幾個月有機搜索訪問月份。 當(dāng)然，這是一年前，但直到有人可以告訴我同樣的事情或沒有交通損失，當(dāng)你從301轉(zhuǎn)換到302，沒有討論我們有。
內(nèi)部鏈接，技術(shù)方法
在PageRank模型下，鏈接公平通過網(wǎng)站的流是一個非常重要的組成部分來檢查是一個公理。 遺憾的是，這么多與客戶的討論僅僅是對外部鏈接，而不是如何更好地大化網(wǎng)站已經(jīng)擁有環(huán)節(jié)股權(quán)。
有很多工具，把這個概念帶到最前列。 例如， Searchmetrics計算和可視化鏈接股權(quán)整個網(wǎng)站的流量。 這給你一個感覺，你可以建立內(nèi)部鏈接，使其他頁面更強。
此外，保羅•夏皮羅放在一起在一個引人注目的職位，你如何計算出一個內(nèi)部版本的PageRank免費使用統(tǒng)計計算軟件- [R 。
這兩種方法都對提供更多內(nèi)容的可見性非常有價值，并且非常落入什么技術(shù)SEO可以提供。
結(jié)構(gòu)化數(shù)據(jù)是有機搜索的未來
流行的一線是Google正在尋求成為網(wǎng)絡(luò)的表示層。 我說， 幫他們做到這一點！
有很多關(guān)于Google如何使用我們的內(nèi)容，并試圖把我們自己的網(wǎng)站從圖片。 隨著業(yè)界從網(wǎng)站上看到的交通便利，它成為了功能的代碼段，很明顯，在許多情況下，您在Google獲取您的內(nèi)容比在他們沒有更多的價值。
使用移動設(shè)備上的Vocal Search設(shè)備和即將推出的Google首頁，用戶只能收到一個答案。 也就是說，Google正在構(gòu)建的星際迷航計算機不會讀取每個結(jié)果 - 只有一個。 這些答案是由燃料豐富的卡和特色片段，它們又被結(jié)構(gòu)化數(shù)據(jù)推動。
在更新允許JSON-LD的規(guī)范時，Google實際上已經(jīng)使我們對結(jié)構(gòu)化數(shù)據(jù)有很大的幫助。 在此之前，Schema.org是對代碼進行非常繁瑣和具體的更改，而沒有投資回報的問題。 現(xiàn)在結(jié)構(gòu)化數(shù)據(jù)為SERP的許多組件提供了能力，并且可以很容易地放置在文檔的

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

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

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

我已經(jīng)談到了REL-的prerender過去在我的一篇關(guān)于我如何與一行代碼，改善了我們的網(wǎng)站的速度68.35％ 。

有許多注意事項都帶有rel-prerender，但最重要的一個是，你只能一次指定一個頁面，并且只能在所有Chrome線程中指定一個rel-prerender。 在我的文章中，我將討論如何利用Google Analytics（分析）API對用戶下一步可能訪問的網(wǎng)址進行好猜測。

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

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

其中一個總是使SEO有趣的事情，其思想領(lǐng)袖如此引人注目的是，我們測試，學(xué)習(xí)和分享了那么多的知識。 看來，測試和學(xué)習(xí)的文化被淹沒在內(nèi)容洪水。 也許許多類型的人都消失了，因為他們知道和喜愛的策略被谷歌的動物園動物吞噬。 也許我們不斷侵蝕的數(shù)據(jù)使得越來越難得出有力的結(jié)論。

網(wǎng)站名稱：SEO如何處理內(nèi)容和鏈接
鏈接地址：http://muchs.cn/news23/20573.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供自適應(yīng)網(wǎng)站、網(wǎng)站建設(shè)、做網(wǎng)站、網(wǎng)站設(shè)計、企業(yè)網(wǎng)站制作、動態(tài)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)