使用Search Console數據

我們已經將我們所有的搜索控制台數據存儲在Google的基於雲的數據分析工具BigQuery中一段時間,這使我能夠立即取出表格並查看所有已經丟棄的關鍵字。

有幾個關鍵字排列/主題受到特別嚴重打擊,我開始挖掘它們。將表中的所有數據放在一起的好處就是你可以做一些事情,比如繪製每個頁面的排名,這些頁面隨著時間的推移會為單個關鍵字排名。

這終於讓我有用了。

黃線是我想要排名的頁面,以及我見過的最好用戶結果頁面(即跳出率較低,每個會話頁數較多等):

另一個例子:再次,黃線表示應該正確排列的頁面。

在我發現的所有情況中,我的主要登錄頁面(以前排名一致)現在正被我寫在同一主題上的文章或用戶生成的內容所蠶食。

你確定這是Google更新嗎?
你永遠不可能100%確定,但我幾個月沒有對這個領域做任何改變,所以我不希望這是由於最近的變化或延遲的變化而引起的。該網站最近遷移到HTTPS,但在那段時間沒有看到流量波動。

目前,除了更新之外,我沒有其他任何東西可以將其歸因於此。

我如何解決這個問題?
理想的解決方案將是我所有的交通回來。但是,這比“我想要正確的頁面為正確的關鍵字排名”更具主觀性,所以相反,這就是我在這裡瞄準的內容。

當然,所有這些關鍵詞都是“嘗試”;我最近才開始做這些改變,如果任何改動都能奏效的話,陪審團仍然不在。

不索引用戶生成的內容
這一點似乎有點不費吹灰之力。無論如何,它們都帶來了令人難以置信的seo流量百分比,然後比用戶登陸適當的著陸頁時更糟糕。

我喜歡讓他們編入索引,因為他們偶爾會開始排名我自己從未試過的關鍵字想法,然後我可以遷移到目標網頁。但是,如果我要在我的主頁上遭受麻醉,那麼這是一個相對較低的事件,而且可能不值得再做。

更好地使用Schema.org“關於”屬性
我一直在等待一個引人入勝的地方,讓這個想法一炮而紅。

概括地說,您可以將它歸結為使用About屬性指向多個權威來源(如Wikidata,Wikipedia,Dbpedia等),以幫助Google更好地理解您的內容。

例如,您可以將以下JSON添加到關於唐納德特朗普就職典禮的文章中。