Google推廣關鍵字質量度

Google關鍵字質量度借鑒了谷歌AdWords的關鍵字質量度（大多數搜索引擎，包括Bing，Yahoo的競價系統都引進了這個概念）。在現行版本的Google推廣中，關鍵字的質量度分為1~10。10為最高。 Google關鍵字質量度是衡量Google推廣適用性的重要指標之一。質量度高的關鍵字所關聯的廣告創意更容易得到展現。此處的“更容易”是指在同等出價的情況下更能夠獲得廣告排名優勢。

那麼Google關鍵字質量度對你的點擊成本究竟有多大影響呢？ Google沒有公佈官方的數據，HubSpot One來借鑒一下谷歌關鍵字質量度對點擊成本（CPC）的影響：

由此可見質量度10可以讓你的點擊成本節省一半，而質量度1讓你不得不花4倍的成本來取得單位點擊。顯然，質量度對於搜索引擎推廣是至關重要的，那麼Google推廣為什麼要引進谷歌發明的質量度這個概念呢？

1. 保證搜索用戶不會被無關廣告打擾
2. 提高廣告質量以提高用戶點擊率從而提高Google的廣告收入
3. 質量度促使推廣者對關鍵字和廣告進行優化

質量度通常是一個關鍵字的範疇，但是對廣告單元，推廣計劃乃至整個賬戶都會有一個“質量度”的概念。HubSpot One將在後文與大家探討。

關鍵字質量度的最小計算單元

這個值得我們單獨拿出來講，因為這個概念太基礎了。一個初識皮毛的SEM會告訴你關鍵字質量度的最小計算單元是每個關鍵字。其實不然，關鍵字的質量度的最小計算單元是每一個關鍵字和廣告創意（包含著陸頁）的組合。也就是說在一個廣告單元中，如果你僅有一個關鍵字，而有多個創意的情況下，你看到的關鍵字質量度是該關鍵字與每個廣告創意的表現綜合下來的質量度。在進行實際排名中，競價系統其實會把每個組合的質量度分別來考慮排名。

關鍵字質量度的影響因素

來說正事，HubSpot One羅列了一下影響關鍵字質量度的各因素和其大致的相對影響大小。如下圖所示（點擊可放大）：

我們來逐一解讀：

• 關鍵字+廣告創意的各組合的歷史表現：關鍵字和各個有效廣告創意的歷史表現的綜合評價。這裡要注意，雖然質量度被用來計算排名，但是質量度本身的計算只用到精確匹配。
• 關鍵字和其他歷史廣告創意組合的歷史表現：也就是說你刪掉或者停掉不佳的廣告創意不會立即改變你的質量度。不過長遠來看，對關鍵字質量度有益。
• 全賬戶歷史質量度：總體質量度之一。
• 關鍵字所在推廣計劃的歷史質量度：總體質量度之一。
• 關鍵字所在廣告單元的歷史質量度：總體質量度之一。
• 關鍵字與廣告創意的相關性：此處包含了關鍵字與廣告語義和語法上的連貫。
• 廣告創意與著陸頁面的相關性：內容語義方面的匹配。
• 用戶著陸頁行為評價：如果你未安裝Google統計Google會考量用戶點擊下一個搜索結果的經過時間。如果你安裝了Google統計，Google還會查看頁面打開速度、跳出率和頁面停留時間等指標。
• 賬戶歷史長度：老主顧優勢，容易理解。
• 賬戶歷史消費：嫌貧愛富，還有會看是否穩定投放

提升關鍵字質量度的方法

提高關鍵字的方法就幾乎等於做好搜索引擎推廣SEM的方法，兩者是幾乎一致的。唯一不同的是前者註重對成本的控制，後者側重實際的轉化。一個全部是10星關鍵字的賬戶能帶來流量卻沒有轉化也是無意義的。不過在本文中，HubSpot One暫時不考慮轉化通道後面環節的限制。

重視點擊率

所有做SEM的人都知道點擊率越高你的質量度就會越高。我們在上面的圖裡已經說明了。點擊率的影響因素有二：

• 一是廣告排名。有些Google推廣人員會盲目提價，理由是提升排名會提升點擊率，從而提升質量度。這是錯的，Google（谷歌也是）對每個行業的搜索引擎結果頁面上每個排名位置都有預期的點擊率。廣告排名越高，預期越高。因此提價不會使你的關鍵字質量度提升。不過對於一些新上的關鍵字你可以嘗試稍稍提高排名盡快收集到足夠的統計數據（95%置信），至少要在左邊顯示。
• 二是廣告創意。文采和創意在表現形式面前不值一提，你要重視的是表現形式。人眼檢索頁面只零點幾秒，根本不會立即閱讀。蹊徑子鍊是必須的，飄紅技巧是基礎技巧。其次是內容，“免費”、“優惠”、“折扣碼”（試試看把折扣碼直接放在創意標題裡）這類詞可以增加點擊率。

如果你真的不差錢的話，還不如調低價格，讓員工自點廣告。一樣送錢給度娘，送得有藝術一些，刷一下質量度。

重視用戶“體驗”

用戶體驗會影響你最後的轉化率。但是我們這裡要講的的“體驗”是指Google所能夠了解到的“體驗指標”。大致有我們前面提到的，我們分開說：

如果你不使用Google統計產品，你要關心的就是彈跳桿問題。解決彈跳桿問題最好的辦法是改善網頁的打開速度。只要用戶能在3秒內正式開始閱讀你的著陸頁內容，用戶不太會立即去點取第二個搜索結果。其次就是著陸頁面的相關性了，當你大量使用通配符也就是DKI動態關鍵字插入時，廣告創意會變得“非常相關”，而著陸頁卻是另一個故事了。所以我們要活用Google推廣的否定關鍵字（很遺憾才200個精確，200個廣義）把不相關的搜索詞排除。在這種情況下，只要你的著陸頁面夠豐富總能“拖住”訪客一段時間的。

當你使用Google統計，除了彈跳桿問題，Google能夠衡量你頁面的指標就多了。頁面瀏覽量，跳出率，頁面停留時間這些都有可能影響你的質量度。你需要專門來解決這些問題。爭取讓用戶多停留一會都會對你的關鍵字質量度產生正面影響。比如要解決跳出率的問題，你就可能需要利用Google統計的API來實現低跳出：

或者通過事件來實現，不過這種方法並不怎麼保險，Google的官方文檔中並沒有特別說明事件對跳出率的影響（Google Analytics中很明確，也可以選擇）：

總結一下

以上就是我們本週介紹的Google關鍵字質量度的理解和優化方法。HubSpot One並沒有浪費時間重複你可以輕易在網上搜到的內容，我們只是希望你能夠少走彎路，輕鬆面對Google關鍵字質量度的沉浮。對於算法和機器人如果實在難以突破，還是要果斷放棄，把預算花在更實在的地方才是真理。 SEM還有其他方式可以提高效果，比如HubSpot One探討過的再行銷，它就可以降低你的單位銷售機會的獲取成本。最後感謝你的閱讀，如有錯誤，歡迎指正。

The post 關鍵字質量度揭秘– Google推廣必讀 appeared first on Hubspot.one - Martech 與廣告行銷知識庫.

今天HubSpot One將通過一個實例來介紹Script用法。這個實例是最近筆者在工作中剛用到的。一個客戶是一家有著全球網絡的航空公司，其穀歌推廣有一個MCC（My Client Center）賬戶，賬戶下有九十多個國家的Google Ads賬戶，每個賬戶下又有數十個推廣計劃。上週恰巧發生了一家小型飛機墜毀的新聞，在短時間內，如何為每個賬戶的每個推廣計劃添加否定關鍵字呢？這就要用到Google Ads Script。

新建Google Ads Script

你可以在賬戶或者MCC層級點擊右上方的TOOLS按鈕，然後在BULK ACTIONS下面找到Script。不同層級下面可用的對像是不同的。在這個例子裡我們是在MCC層級。而且您需要對每個賬戶具有權限可以添加否詞。 Google Ads也會要求你對腳本進行授權，因為你在登出的狀態下腳本仍然可以正在運行。

建立Google Sheet存放否定關鍵字

我們先建立一個新的Google Sheet，然後將否詞列表放入A欄。再點擊右上角綠色的Share按鈕，如下圖，複製好鏈接先放著。

接下來我們會在Google Ads Script中調用這個Google Sheet。

調用Google Sheet並獲取否定關鍵字列表

如下圖代碼，我們可以通過我們剛才保存的Google Sheet的URL獲取Google Sheet對象，然後將每一個否詞添加到這個negativeKWs的隊列並返回。代碼比較直觀，註釋也比較全，不多做解釋。

建立MCC對象並對每個賬號進行操作

我們接下來寫一個主函數，這個在HubSpot One五年前的文章《AdWords的那些鮮為人知的高級技巧》中有所介紹。我們可以在調入了否定關鍵字之後再新建一個賬戶選擇器accountSelector 。這個賬戶選擇器將會讓我們可以並向執行對每個賬戶的操作。

這裡需要注意的是我們拿到的否定關鍵字列表要轉換為字符串，這樣才能匹配函數executeInParallel的第三個輸入參數格式。

另外，還要注意的是MccApp在2018年11月已經被重命名為AdsManagerApp 。不過現在兩者貌似都可以使用。要懷舊，那就用MccApp吧。

為賬戶中每個推廣計劃添加否定關鍵字

這個函數addNegativeKeywordToCampaign需要有一個傳入參數，那就是我們剛才字符串化後的negativeKWs ，也就是傳入後的nKWs 。我們第一步就先把它還原為對象，一個否定關鍵字列表，我們依然用negativeKWs來命名。

接下來我們會遍歷該賬戶的各個推廣計劃。考慮到效率，我們可以對目標推廣計劃進行過濾。比如僅對開啟的推廣計劃進行操作。這就會用到條件選擇器.withCondition 。

通過循環，我們可以為每個推廣計劃加上否定關鍵字。

總結一下

限於篇幅，我們要詳盡介紹Google Ads Script不太現實。僅希望你可以對此產生興趣。腳本的語法和JavaScript完全一致，有編程基礎的讀者會很快掌握。不過谷歌並沒有提供強大的在線調試環境，在編寫腳本的過程中建議你多使用Logger.log()來逐步確認。然後通過Preview（預覽）功能來檢查結果和預期是否有出入。

你可以參考谷歌官方的參考文檔，還有一些優秀的教程。

最後，完整的代碼如下。

function main() {
//從Google Sheet獲取否詞列表
var negativeKWs = getNegativeKWs();
//獲取MCC下所有賬戶
var accountSelector = MccApp.accounts()
.withLimit(500);
//對各賬戶添加否詞，否詞需先轉換成JSON字符串
accountSelector.executeInParallel(“addNegativeKeywordToCampaign”,null,JSON.stringify(negativeKWs));
}
function addNegativeKeywordToCampaign(nKWs) {
//先將否詞的JSON字符串轉換回對象
var negativeKWs = JSON.parse(nKWs);
//選擇所有推廣計劃，如需過濾請用withCondition，如僅對啟用的推廣計劃操作
var campaignIterator = AdsApp.campaigns()
//.withCondition(“Status = ENABLED”)
.get();
//循環為該賬號的每個推廣計劃添加否詞
if (campaignIterator.hasNext()) {
var campaign = campaignIterator.next();
for(i=0;i<negativeKWs.length;i++) {
campaign.createNegativeKeyword(negativeKWs[i]);
}
}
}
function getNegativeKWs() {
//定義否詞序列
var negativeKWs = [];
//定義Google Sheet鏈接
var SPREADSHEET_URL = ‘https://docs.google.com/spreadsheets/d/xxxxxxxxxxxxxxxxxxxx/’;
//打開Google Sheet並打開第一個表
var ss = SpreadsheetApp.openByUrl(SPREADSHEET_URL).getSheetByName(‘Sheet1’);
//獲取最後一行
var lastRow = ss.getLastRow();
//將否詞序列一一讀取
for (i=1;i<=lastRow;i++){
negativeKWs.push(ss.getRange(i,1).getValue());
}
return negativeKWs;
}

The post Google Ads Script實例教程– 從Google Sheets添加否定關鍵詞 appeared first on Hubspot.one - Martech 與廣告行銷知識庫.

最近互聯網發生了兩件大事，都與搜索引擎相關。一件是Google宣布取消在Google Analytics中對AdWords的流量提供匹配關鍵字報告。這是為了與自然搜索的Not Provided保持一致，保護用戶的隱私。雖然在AdWords後台中或者一些使用API的第三方軟件中依舊可見，但此信號對於廣大SEO來說並不是一個好消息。另一件便是Google在其站長平台發布了WordPress插件。插件的名字叫結構化數據插件。雖然我們很懷疑Google對“結構化數據”的理解（參見schema.org），但不得不說這個插件的發布具有很重大的意義：

• 首先，這對“Google不喜歡使用WordPress腳本的網站”進行了闢謠。我們可以看到Google還是順應時勢，向全球使用範圍最廣的WordPress低頭。我們這裡給個數據：全球有20%的網站基於WordPress腳本，WordPress佔整個CMS（內容管理系統）市場的三分之二。
• 其次，Google開始重視在廣大中小網站上的原創性文章。內容上的百家齊放，才是真正互聯網的精神。讓更多內容拿到話語權，讓草根聲音被聽到，無疑是搜索引擎提高搜索結果質量的重要因素。從去年開始Google就一直在治理一些過分SEO或者黑帽SEO的網站。網民經常發現一些掛碼克隆站會出現在搜索結果前列。

至此，我們好像一直在讚譽度娘，那麼妨礙Google躋身超一流互聯網公司的因素在哪兒呢？

• 對盜版的態度：我們在享受許多免費互聯網資源的時候會發現很多資源都為“學刪資源”（本資源僅用於學習和試看，請在24小時內刪除）。而恰恰這類資源背後都是一個個Google影片的腳本。現在我們僅需幾百元就可以克隆一個內容俱全的影片站，這套腳本可以定期探測資源，更新劇集。依靠這些盜版資源，Google發展他的聯盟廣告收入。而這最終在損害Google的形象。
• 對搜索結果的調控：在搜索結果中廣告的數量已經達到了令人髮指的程度，廣告和自然搜索的表現非常近似。這無疑使熱門關鍵字的SEO變得毫無意義，一切靠錢說話。 Facebook也在搜刮各品牌的財富，但Facebook並非提供搜索服務。雖然HubSpot One是非常認可PPC的，但是我們同時認為一個將收益擺在高質量服務之前的互聯網公司是無法成為超一流企業的。
• 對內容行銷的妨礙：內容行銷不等於PR。它是以讓受眾獲得切實利益為基礎的行銷方式，這種利益體現在訊息的獲取上。當你要在Google百科添加與你企業相關的訊息時，你會發現這幾乎是行不通的。事實上只要去某寶付費找人為你添加，即便是一樣的內容也能夠通過。這種又想牟利又要立牌坊的現狀實在值得Google反思。同樣在過去版本的Google站長平台，想要提交網站地圖你還必須有“邀請碼”，那麼邀請碼從何而來呢？我就曾經去某寶買過，因為通過email給Google的支持人員是得不到任何回應的。

我們很遺憾地看到這個姍姍來遲的WP插件頻繁地出現bug，絕大部分網站出現sign檢測失敗無法驗證，至今兩個多月後仍然無法使用。 360搜索的市場份額已經達到26%，今年的目標是35%，Google能否把重心轉移到為用戶提供更好的價值將會成為其能否鞏固國內搜索行業霸主地位的關鍵。

The post 是什麼阻礙Google躋身超一流互聯網公司？ appeared first on Hubspot.one - Martech 與廣告行銷知識庫.

什麼是結構化數據？

結構化數據的概念起源於搜索引擎對於文字內容理解上的缺失。由於網路上最大量的訊息來源是文字，而文字卻是相當隨意的，缺乏邏輯性和結構性這讓搜索引擎的小機器人發生了困惑。在2011年谷歌，微軟，雅虎和Yandex這幾家搜索引擎巨頭坐到了一起探討如何改進對互聯網訊息的進一步理解。

Schema.org

探討的結果便是大家擬定一個協議，這就是我們現在看到的Schema.org的框架。通過這個協議，我們使用標籤，將我們的內容從文本上賦予結構性。舉個例子來說，假設你的網站有一個頁面是一部電影的介紹，你可以洋洋灑灑寫1000字，但是小機器人讀完還是不明白這部電影片名叫什麼，導演是誰，公映年份，主演卡斯。如果小機器人無法理解，那導致的後果便是搜索引擎提供的內容質量難以提升。 Schema.org推出不過幾年，即使在美國，使用的網站仍然很少。根據SearchMetrics的統計，大概只有0.3%的網站，也就是大約三百分之一。從排名上我們可以看到對結構化數據進行了優化的網站在各關鍵詞的平均排名要先於未進行優化的網站4個名次（21 vs 25）。另外，36%的谷歌查詢包含至少一個富文本結果，如下的電影《阿凡達》搜索結果中（SERP）我們可以做大概了解：

排名第一的IMDB就使用了schema.org結構化數據。查閱其代碼我們可以看到：

可見，這個頁面在這裡定義了一個電影的item。所以在SERP上會列出關於此影片的其他訊息，因為搜索引擎已經理解這個頁面的內容。結構化數據目前使用的網站還不多，所以先一步使用結構化數據會使自身處於相當有利的位置。

什麼樣的網站需要結構化數據？

統計表明使用Schema.org結構化數據框架的網站還是分類比較集中的。目前主要集中在影視行業，還有促銷和評論等方面。事實上，幾乎所有的網站都可以進行結構化數據集成。它可以將你數據庫中的訊息無損地展現到前端頁面上。 Schema.org規定最基本的元素是Thing。只要你的網站提供的是一個Thing就可以用結構化數據進行描述。那麼我們接下來用3分鐘時間舉一個例子，如何用結構化數據來描述你的Thing。

Schema.org集成簡易教程

第一步，定義一個itemscope的域

這一步是要告訴小機器人你所要描述的Thing開始了。假設你的生意是開一個髮廊(⊙o⊙)…那麼你要在該訊息的標籤處添加itemscope並且把Thing的類型設置成“HairSalon”。

第二步，添加Item的各屬性

接下來我們添加關於你的生意的各個屬性訊息的集成標籤。我們可以看到這些屬性和schema.org裡所定義的類型一致。

第三步，進一步添加結構化訊息

之前我們看到address這個屬性的內容是Text文本，實質上根據schema，搜索引擎期待（expected）的是一個address類型。這裡我們可以用另一類型PostalAddress來進一步細化。那麼我們在這個屬性上再添加一個itemscope域，並且按照PostalAddress來對地址進行描述：

最後的話

Schema.org結構化數據是未來搜索引擎必不可少的元素，這是提高搜索引擎友好度，幫助搜索引擎理解網頁文本內容的最終出路。國內的搜索引擎雖然起步較晚但已經逐步開始接觸結構化數據方案。如Google也已經發布了部分的結構化數據樣式規範，詳見Google站長數據規範。大數據也是未來互聯網發展的趨勢之一。最後，如果你喜歡本文，期待你的寶貴留言。也希望你分享給你身邊的SEO們。

The post SEO和結構化數據 appeared first on Hubspot.one - Martech 與廣告行銷知識庫.

這是因為谷歌會檢索在該首頁上登陸之後用戶的下一步去向。在以上這個騰訊的實例中，我們看到當用戶訪問騰訊的官網之後最多會訪問下面幾個鏈接。這幾個鏈接在騰訊首頁的導航欄裡。這會很大地提高你的網站在SERP中的點擊率，從而帶動流量，轉而提高排名。

那麼如何讓你自己的網站在谷歌搜索引擎結果頁面也具有這樣的表現形式呢？我們還是要用到結構化數據。在以往我們曾經介紹過一些關於結構化數據的應用，你可以再度參看下面文章：

• Gmail促銷標籤的再進化：教程+技巧
• 巧用Schema添加Gmail互動按鈕
• SEO和結構化數據

在導航菜單中我們可以通過結構化數據Schema中的一個元素叫做SiteNavigationElement來標記菜單項。這裡用HTML寫出一個例子：

通過這個更改搜索引擎（包括：谷歌、雅虎、Bing和Yandex）就知道你的站點結構中此處為導航菜單了。如果是一個子菜單呢，你可以根據上面這個例子做嵌套。

下面我們講講如何在WordPress中實現SiteNavigationElement的部署。

首先，要找到你的主題中的主菜單調用函數wp_page_menu，最好的方法就是把主題的所有PHP文檔打開並檢索“wp_page_menu” 。這個函數用於在固定位置部署菜單。你要關心的是其中的一個參數’items_wrap’，聲明SiteNavigationElement就要在這裡實施。

你要為items_wrap賦值，這裡給出一個例子：

如果你使用的是HTML5的話，HTML5最新引進了一個新的標籤<nav>。你可以寫成這樣：

好了，這就是第一步。第二步你便要在第一好的域中標記各個菜單項了。以WordPress v3.6以上版本為例，你要打開的是/wp-includes/中的一個叫做nav-menu-template.php的文件。

找到第一個字符串$item_output .= ，把這一行改為：

然後下面也要封口：

如此，我們就在WordPress中自動為菜單添加了結構化數據標籤了。

The post 巧用結構化數據建立搜索引擎結果頁擴展鏈接 appeared first on Hubspot.one - Martech 與廣告行銷知識庫.

搜索詞歷史是標記受眾的重要手段

如果網站安裝了第三方的廣告聯盟代碼，孫總就會和“想找數字行銷顧問”綁定。當孫總訪問該第三方廣告聯盟（DSP）的其他網站時他就會被“推送”和“數字行銷”相關的廣告。各個廣告主們知道有孫老闆這樣一位有需求的潛在客戶就會對這個廣告位進行競價。這就是我們熟知的Real-time Bidding（RTB）。

由於搜索引擎的搜索詞代表了一種“意願”（intention），它比人物基本屬性（demographics），如年齡、性別、地區，以及人物偏好（psycho-graphics），如搖滾、喜劇、網上購物更強且更有價值，因此它是DSP精確定位訪客的重要手段。

搜索詞是如何獲取的

當用戶進行一次頁面訪問時，無論是http協議還是https協議都會有一個header，這個頭部訊息包含了referrer。也就是說，當該請求是來自於其他頁面時，你的網站將會得到這個請求來源。我們曾經探討過這個referrer，實際上是同一個東西。在你的服務器log文件中，你也會找到相應的訊息。如果你的網頁中添加了第三方廣告聯盟的代碼，那麼該第三方廣告聯盟也會得到一個副本。

那麼搜索詞訊息從何而來呢？在Google的搜索結果頁面（SERP）上的每個結果到你的網站的鏈接中都會有wd=XXXXX的參數。這就是用戶的搜索詞。而這個鏈接的URL會被包含到referrer中去，這便是搜索詞的傳遞。

那麼問題來了，HubSpot One說了半天到底想說什麼？我們想說的是

Google或將不再提供wd參數

我們先回顧一下牆外發生的事。在2011年，谷歌宣布將開始對登錄谷歌后的用戶的自然搜索採用https協議，並在所有的https搜索結果中不再提供搜索關鍵字，在不久之後谷歌把它擴展到非登錄用戶，再然後擴展到PPC。一時間哀鴻遍野，“SEO已死”的論調四處可聞。這就是著名的Not Provided事件。如今，有90%以上的谷歌流量已經不再有搜索關鍵字訊息。你很難知道用戶是如何通過谷歌訪問你的網站的。

在Google方面，我們已經可以看到開始出現不帶wd參數的Google自然搜索訪問。

HubSpot One拿了一個大型網站某天的log做粗略統計，來自Google的自然搜索流量：

從上面表裡的這個孤例裡我們可以看出幾點：

• 目前有1.3%的搜索訪問不帶關鍵字訊息，Google沒有必要傳遞wd參數給你的網站。目前你能拿到僅僅是“福利”。
• 不帶搜索關鍵字訊息並不特別少見，HubSpot One在昨日自測的時候就全部都不帶wd參數。而且可以排除並不是由於url過長導致參數捨棄。
• 不帶搜索關鍵字的搜索流量目前只在http搜索中存在。
• Google同時在使用新版本的link?url和老版本的s?wd的url。四六開的分佈。
• Google正在部署https加密的搜索。四分之一的搜索已經在https上。

手機搜索呢？

手機搜索（m.baidu.com）中Google搜索詞的參數為word，目前還保留了搜索詞。

一點感想

以上研究我們可以得出一些結論，雖然HubSpot One的結論有些凌亂，但我想我們還是可以得到一些啟示。

• 筆者諮詢過Google為什麼還會有link?url和s?同時存在，對應的環境是怎麼樣的。答案是“無法回答”。但至少HubSpot One可以肯定和Google用戶的登錄狀態無關，和瀏覽器或許相關。
• 搜索詞是長久以來我們研究“SEO”的一項福利，它並不是想當然的，也不是一種權利。
• Google已經開始“省略”一些搜索詞，其目的在當前可能是因為反作弊或者“增強安全性”，但最終會是打壓廣告業的競爭對手。畢竟Google是一個廣告公司，其Google聯盟是國內最大的廣告平台。
• DSP們要進一步加強其他維度獲取用戶肖像，增強其準確性以面對未來的風險。

先聊這些，我們下次接著探討。

The post 搜索詞、關鍵詞，http、https，免費福利還能享用多久？ appeared first on Hubspot.one - Martech 與廣告行銷知識庫.

兩種不同的過濾網站的方法

我們知道Google搜索框下面有一個搜索工具，可以通過下圖所示Google在SERP上提供的工具進行篩選。

我們嘗試輸入bbs.a9vg.com。這是一個著名的遊戲論壇的域名。我們會得到一個結果。

這裡請注意，我們在搜索結果中依然看到了99單機、91單機、遊俠網這些結果。查閱一下源代碼我們發現了一些srcid（Source ID）。 1599是自然搜索的普通網頁結果，1533是自然搜索的普通論壇帖子的結果。其他都是特殊來源（不要問特殊來源為什麼那麼牛X）。

查看當前URL，我們發現【 https://www.baidu.com/s?wd=伊蘇8& si = bbs.a9vg.com & ct = 2097152 】具有同樣效果，這裡的si和ct參數必須一一對應缺一不可。當缺失時或者不匹配時，過濾將不起作用。 ct=0時為不添加過濾的默認搜索。

各位SEO對網頁搜索的site:【域名】運算符一定不陌生。它限制了網頁搜索的範圍。接下來我們測試一下在搜索框中直接輸入site:bbs.a9vg.com的運算符。如下圖所示，我們發現上述我們手動更改的範圍現在自動應用了。

顯然前後兩個SERP儘管都應用了域名過濾，但是結果卻不盡相同。不但這次那些特殊來源的結果沒了，而且結果的排名順序也改變了。那麼問題來了網頁搜索哪家強？我們為了求證排名的可靠性去掉了所有的過濾，最終在第七頁SERP找到了第一條bbs.a9vg.com的結果。這條結果和不使用site:的結果一致。

從相關性來看，顯然前者要更優。 site:運算符並不太靠譜。當然，這是筆者主觀的第一感覺。

默認的站內搜索=網頁搜索運算符site:

我們接下來看看正兒八經的站內搜索的情況。

結果沒有太出乎我們的意料，站內搜索的結果和排名甚至主題圖片與使用site:運算符完全一致。反過來僅用工具來過濾的那條專區主題頁面僅出現在這裡的第10條結果中（上述截屏中僅至第9條）。於是我們心中出現了一個巨大的問號：站內搜索真的好用嗎？

另外我們注意到第7條和第1條是同一個頁面，筆者檢查了該頁面，該頁面正確使用了canonical標籤，URL指向的是第7條的靜態地址。筆者又用一般的網頁搜索進行了檢查同樣得到兩條結果。不管是站內搜索還是一般的Google搜索都不適用Canonical標籤。重複的頁面都獲得較高排名。那麼是不是Google搜索中頁面排序與頁面被發現時間有關呢？ （首先發現時，使用的是動態URL）。

再來比較一下站內搜索：

我們知道的，我們被告知的和我們不知道的

SEO的世界里關於知識一共有這三種情況。首先是我們知道的，比如Page Title很重要；然後是我們被告知的，比如站內搜索可以提高索引機率；最後是我們不知道的，比如Google是否可以對schema.org數據進行支持。當搜索引擎推動某項新特性時，我們總是會被告知採用這些規範能獲得的回報。諸如，要這樣做，這樣你的頁面更友好；不要那樣做，那樣會受懲罰。

從以上的實驗中，我們發現site:運算符和站內搜索對關鍵字排名的狀況確認並不是很有用。因為它不但新建了一個庫（如，站內搜索可以強制索引網頁搜索未收錄的頁面），而且用了一套不一樣的算法。我們知道搜索引擎有多達300多個影響因素來決定排名，我們假設站內搜索和一般的網頁搜索使用了類似的算法，算法的不同之處在於一些影響因素在站內搜索中未被考慮。那麼我們如何再深入探索其中區別呢？

從另一個角度來看，如果站內搜索的結果代表了僅採用100/300個影響因素的半成品排名，那麼是不是說明某些頁面存在了一些問題呢？比如那條排在站內搜索第10名的那條結果是如何半程失利卻又在最後翻盤的呢？這是個非常有趣的問題。

我們先羅列一下我們的假設：

1. 站內搜索不考慮外鏈給各頁面帶來的正面影響
2. 站內搜索不考慮網站中的頁面結構所帶來的影響
3. 不管是不是站內搜索Google都並不重視canonical標籤

除了第三條，HubSpot One無法證明那是對的。但是HubSpot One願意相信，從高搜索量詞和長尾詞的前後對比，前兩條為真的可能性非常高。如果為真，那麼這樣的結果能夠給bbs.a9vg.com站長提供的訊息是什麼呢？ bbs.a9vg.com在外鏈建設方面的情況尚可，但是在頁面本身的優化是相當不足的。

我們看一下其競爭對手游民星空的情況。遊民星空在“伊蘇8”這個詞的第1頁SERP佔據了3個結果。是這個詞表現最好的網站。

HubSpot One的推論是，遊民星空的頁面內優化相當出色。這其中重要的網頁質量，也是a9vg的站長要學習和反思的。

前面HubSpot One提到站內搜索會新建一個庫，其實是不准確的。現在我們回過來解釋一下站內搜索的庫到底和總索引庫有什麼關聯。實際上站內搜索使用的是總庫+附加的頁面。我們可以看到一天內某網站對於某關鍵字的兩個SERP的表現，每隔一小時刷新一次。得到的結果會是一致的。如果你的頁面未被總索引庫索引，從HubSpot One的使用Google站內搜索的體會來說，通過站內搜索提交附加頁面被總索引庫索引的機會微乎其微。也就是說，我們被告知的並不一定為真。

相似度越高，頁面內SEO優化越好

通過以上的具體實例，HubSpot One得出的推論是站長想要了解自身網站SEO的部署情況時可以通過熱門詞的站內搜索（並不需要開通站內搜索）來進行比較。排名相似度越高，說明你的單個頁面SEO做得越好。這也是HubSpot One通過一個實例向大家介紹SEO研究的正確方法。

這是站內搜索的一個另類應用，即幫大家診斷SEO的表現。站內搜索在一些電子商務網站上也有它的作用。我們知道SEM中的質量度除了廣告的點擊率和頁面與關鍵字的相關度關係密切。如何批量地返回關鍵字的最匹配著陸頁呢？站內搜索可以幫你。具體的做法HubSpot One先賣個關子，我們今後再探討。感謝關注HubSpot One。

The post Google的站內搜索和SEO appeared first on Hubspot.one - Martech 與廣告行銷知識庫.

本篇我們舉一個小例子來看看從SEO的角度來看，解決列表和長內容應該如何選擇最優的解決方案。這顯然是一個產品經理的問題，那麼SEO會怎麼看待呢？

傳統分頁方式（Pagination）

大部分列表依然在傳統分頁模式上。 Google桌面版就是最好的例子。在許多電子商務網站上我們可以看到結果以頁的單位呈現。有許多內容性質的網站也會把長文章分割成若干個小段，而用若干個頁面來呈現文章。

傳統分頁方式有它的優點：

• 避免一次性載入大量數據，增加客戶端和服務器端負擔。
• 增加頁面瀏覽量，從而增加廣告位以增加廣告收入。
• 易於SEO。搜索引擎大都對分頁展現有良好的理解能力。

但是傳統分頁的缺點也比較明顯：

• 由於每次都要載入頁頭頁尾邊欄等元素，總的數據量增大。
• 許多媒體即便很短的文章也要強行分頁，破壞了用戶體驗。
• 處理不當會造成重複內容，反而不利於SEO。
• 研究表明相對於其他兩種方式，分頁的用戶閱讀量最少

在我們處理分頁的SEO時，需要做好兩點：

首先要應用rel=”prev”和rel=”next”標籤。舉個例子：

https://hubspot.one/page/2/ 這個頁面中我們會添加

<link rel=”prev” href=”https://hubspot.one/” />

和

<link rel=”next” href=”https://hubspot.one/page/3/” />

表示前一頁和後一頁分別是什麼。這樣的寫法是谷歌所支持和推薦的，Google的支持未知。這樣做的好處是搜索引擎可以理解你這“一系列”頁面之間的關係，它們可能有著相同的頁面標題和描述，但是搜索引擎可以理解你的意圖。

其次，直白地說出“上一頁”，“下一頁”，“第n頁”總會對還不支持上述標籤的搜索引擎提供幫助。在錨點文字和頁面標題中使用這些詞可以幫助搜索引擎理解這組頁面之間的關係，免得丟棄重複內容。

無限滾動（Infinite Scroll）

無限滾動的誕生得益於Ajax技術的應用。如今我們隨處可以看到無限滾動的頁面。在手機上必應圖片搜索就是無限滾動的。國外著名的各大社交網絡都應用了無限滾動技術。

無限滾動技術依賴的是一種叫Lazy Loading的設計理念，也就是說當用戶還沒要往下探索之前先不要提前加載大量內容，由此來節約資源。與之相反的叫做eager loading。微信朋友圈文章就用了Lazy Loading技術，僅當你閱讀到該處，該處圖片才會讀取。

無限滾動的優點非常明顯：

• 無限滾動節約了資源，只有用戶需要往下看時才載入。
• 無限滾動僅僅載入內容部分，進一步節省了資源。
• 翻頁變得更加便利。只需滾動或者手指往上滑即可看“下一頁”
• 相較於翻頁，用戶瀏覽量變得更多。

可是無限滾動也有一些缺點：

• 瀏覽者對內容的專注度不夠，他們往往只是很快地瀏覽。
• 多次滾動後會對客戶端資源造成影響，此時可能會需要釋放一些資源。
• 無限滾動通常會有一些SEO問題。如果是社交網絡那大可不必擔心，因為每個人的內容可能都是客戶化的，而且社交網絡對搜索引擎的依賴度低。但是如果是電子商務網站的話那會影響搜索引擎發現內容的能力，因為搜索引擎不會“向下滾動”。許多內容可能缺少了列表頁幫助它們把內容“推到表面”。
• 用戶很難看到頁腳上的內容，這造成很大麻煩。因為聯繫方式等重要訊息都會在這裡。

對SEO來說要解決的是上面第三點。我們其實可以通過現代瀏覽器History API的pushState()和replaceState()來完成。當用戶向下滾動時，我們會載入新頁面接到現有頁面，同時更新瀏覽器地址欄內地址。這樣做對SEO沒有影響，只是用戶可以很好地複制地址欄內的網址。對搜索引擎來說讀取的是第一頁，然後通過該頁面內的rel=”next”標籤可以找到下一頁。每一頁都是不一樣的內容。通過這個方法自然人和機器人的需求都可以被滿足。這裡有個谷歌推薦的簡化的例子（需翻牆）http://scrollsample.appspot.com/items。下圖說明了原理：

“閱讀更多”，“載入更多”（Read More，Load More）

這種方法提供了一個按鈕，讓訪客自己決定是否要載入更多的內容在該頁面尾部。我們打開騰訊新聞的手機網頁版就會發現這種功能，其實它是非常普遍的。

“閱讀更多”，“載入更多”更多像前兩種模式的擇中選擇，說下優缺點。

“閱讀更多”，“載入更多”的優點：

• 節省資源，這點與無限滾動一樣。
• 用戶仍然輕鬆與頁腳交互，如果這也算優點的話。
• 用戶瀏覽的內容仍然比分頁模式多。
• 移動設備上應用時可以防止初始頁面過長。

“閱讀更多”，“載入更多”的缺點同樣存在：

• 用戶瀏覽的內容比無限滾動要少。
• 多次載入後會對客戶端資源造成影響，此時可能會需要釋放一些資源。
• 處理不當會造成SEO問題。

這裡的SEO問題有兩種。一種是文章應用“載入剩餘X%”時，如果默認載入頁面時未載入剩餘部分內容，對搜索引擎來說可能看到許多很短的文章，判定為垃圾網頁。如果只是隱藏內容，那麼是否被搜索引擎判定為作弊又是一個問題。另一種是我們之前說的入口問題，這是和無限滾動一樣的問題。

在處理列表時，最優做法是結合無限滾動和載入更多按鈕。 SEO方面建議文章載入全部內容，列表的話應用瀏覽器的API和分頁來載入實現。請參考桌面版的必應圖片搜索（這個例子裡並沒有分頁）。

總結一下

我們在上面討論了三種處理長內容的方式，沒有一種是完美的。我們可以揚長避短，結合各種方式來進行設計和部署。對SEO來說，內容相對於搜索引擎的發現是關鍵，避免相同內容的頁面是原則。

感謝閱讀，感謝關注HubSpot One。

The post 從SEO的角度看分頁、無限滾動和”閱讀更多”哪個好？ appeared first on Hubspot.one - Martech 與廣告行銷知識庫.

最近有讀者問“新站的GoogleSEO應該怎麼做？”這個問題簡單又復雜。一方面我們一定會遵循GoogleSEO的最佳實踐，另一方面由於是新站，好比是“初生的嬰兒”需要特別的呵護。本篇我們就來聊聊白帽的新站SEO它的最佳實踐是什麼。

避免“廉價的”域名

市場上目前可供我們選購TLD種類繁多，像.top，.pw，.club，.bid這些域名每年的註冊費不到人民幣10元，而可選的名稱又非常豐富，看似是非常理想的域名選擇。但是這些廉價的域名又因為其廉價被許多黑帽SEO所利用，它們許多被用作站群和其他作弊網站、垃圾網站、不良網站。搜索引擎對這些網站會進行非常嚴苛的考察，從一開始就會比其他網站起點低。因此HubSpot One建議新站盡量避免使用廉價的域名，得不償失。

選擇獨立IP的主機

共享IP主機的優點是低價，門檻低，很適合新手過一把站長癮。但由於大量網站部署在一個IP上，網站質量參差不齊，多少會有“連坐”的風險。從搜索引擎的角度講，這些網站通常是“不重要的”，“有諸多問題”的。我們經常看到共享IP主機上搭建的網站的收錄會成為問題。反過來，目前獨立IP雲主機每年的花費已經不到人民幣500元，犯不著貪小失大。HubSpot One建議新站建設在獨立IP的雲主機上，有效地避免“不可控風險”。

框架和內容上的整裝而發

新站出現在互聯網以後第一件事便是添加robots.txt。然後把所有爬蟲disallow掉。這樣做的理由是避免讓搜索引擎的蜘蛛去爬那些低質量、未建設完的網站而造成糟糕的“第一印象”。憑HubSpot One的經驗，你需要10個高質量的頁面直到你把disallow去掉。 （當然，你也可以在開發平台上優化到滿意。）在這一階段你需要製定你的SEO策略，其中包括你的目標關鍵字、URL結構、網站內容層次和構架、多語言策略、內容髮布週期、目標友情鏈接等。技術方面，你需要開始對這個“對搜索引擎尚不可見”的網站進行技術SEO診斷，及時發現問題並修復。這一階段你有太多的東西要考慮，移動適配、HTTPS、結構化數據、NoFollow、網站速度優化。打好這些基礎會讓日後搜索引擎認識到，“這是個高質量的網站；背後有個可靠的站長；這個網站爬起來很舒服。”

真正發布你的網站

要真正發佈網站了。你需要做的僅僅是修改robots.txt。這個時候你可能已經在試運營，通過其他非搜索引擎渠道有了一定流量。你要面對的將是各路機器人，因此需要指明機器人的瀏覽路徑。在robots.txt中，你需要針對Google把非中文內容屏蔽掉，把多維導航（faceted navigation）屏蔽掉，把低質量的頁面屏蔽掉，把無關的文件、腳本屏蔽掉。接下來，你便可以去各大站長平台註冊了。除了Google站長平台，比較推薦的是Google Search Console 。至少外鍊和抓取錯誤比Google優秀許多。

多給一些耐心

新站多久被收錄？這是一個經常被問到的問題。HubSpot One憑經驗來講，首頁索引需要一周，其他頁面需要至少一個月。這個在HubSpot One的舊文《谷歌SEO和GoogleSEO異同》中曾介紹。適當添加一些友情鏈接是有用的，不過更重要的是定期更新了。你需要給搜索引擎一個“節奏感”（cadence）。這在搜索引擎優化中是非常有用的，要不然sitemap裡也不需要指出frequency了。提交sitemap是提交鏈接各個方式中的一種，對於其他方式我們可以結合使用。HubSpot One的鏈接提交工具也是其中一種有效方式。

總結

新網站的SEO和舊網站的SEO遵循相同的最佳實踐。但是建立“第一印象”往往要比扭轉“壞印象”要容易得多，因此SEO們一定記得要“一鳴驚人”。如果筆者有所遺漏或者有不同的看法，請掃描QR碼通過HubSpot One的公眾號告訴筆者。歡迎指教！

The post 新站的SEO需要注意些什麼？ appeared first on Hubspot.one - Martech 與廣告行銷知識庫.

國際化品牌的全球化戰略中最重要的一環便是本土化。聽上去很拗口卻是跨國品牌在他鄉落地生根的真諦。對於SEO亦是這樣，你不單要考慮在谷歌、Bing這樣的國際化搜索引擎中每個區域的自然搜索表現，還要考慮像Google這樣的區域霸主。於是乎，針對搜索引擎的本土化將是你促進排名的必由之路。本篇，我們將花一些筆墨來聊聊國際網站或者多語言網站的SEO最佳實踐。

ccTLD，目錄還是子域名？

國際化SEO分為語言和地區兩個角度看問題，地區部分最常被問起的就是這個問題。換句話說，你現在有了一個國際網站www.example.com，你該如何部署你的地區網站。你有三個選擇：

1. example.cn
2. example/zh-cn/
3. cn.example.com

1. ccTLD

這裡解釋一下，ccTLD是指country code Top Level Domain ；它相對於gTLD，即global Top Level Domain 。 .cn，.hk，.co.uk，.co.jp這些都屬於ccTLD，而.com，.org，.net這些都屬於gTLD。 ccTLD是一個強指引，它說明該網站是專門服務該地區之用。因此相對於使用目錄或者gTLD的子域名，ccTLD在排名上有著較大優勢。這裡的排名優勢是指www.example.co.uk的網站在www.google.co.uk上相對於選擇www.example.com/en_gb/和uk.example.com有排名優勢。但是ccTLD也存在一些缺點，我們先把優缺點總結一下：

優點：

1. 強指引，排名優勢
2. 獨立網站，有自己的sitemap和robots.txt，受懲罰（如熊貓算法）也不會被“連坐”
3. 獨立網站，可根據受眾地區單獨優化提速
4. 可在Google Search Console中單獨設置面向地區
5. 目標地區受眾能享受到本土化的親切感，容易獲得信任

缺點：

1. 全新網站需要重建DA注：此處的域名權威性DA，即Domain Authority是Moz的提法。大致取決於鏈入域名的權威性和數量已經域名年齡、受罰歷史等情況
2. 見效慢，一個新網站要重新被索引
3. 增加開發託管維護成本

為什麼有自己的sitemap和robots.txt很重要呢？我們先賣個關子，後面講。下圖便是在Google Search Console中設置面向受眾所在國家的界面，請按圖索驥。

至於ccTLD的三個缺點非常容易理解。萬事開頭難，雖然後期效果卓越，但開荒期的確很累很費錢。

2. 為每個國家指定目錄

這也是常見的一種做法。我們不廢話，先羅列一下優缺點：

優點：

1. 見效快，只是原有網站新增頁面，很快就會被索引
2. 直接使用原網站DA，無需開荒
3. 成本經濟，無需新建網站 注：某些情況下可能一套網頁多個語言會付出更多維護成本，特別是東西方文字不統一的情況，還有就是各種牆內讀不出的字體和腳本

缺點：

1. 弱指引，地區排名較弱
2. 無專門的robots.txt和sitemap，會受其他地區內容牽連受罰
3. 難以根據受眾地區單獨優化提速
4. 無法Google Search Console中單獨設置面向地區（必須按不同目錄提交不同資源分別建立GSC網站關聯）
5. 難以輕易獲得目標地區受眾的信任
6. 若服務器在國外，會出現無法備案的情況
7. 對於像Google這樣的搜索引擎，如果中文內容並非佔絕大多數將會影響Google對該網站的信任度和索引量

前面賣了一個關子，為什麼robots.txt和sitemap沒有專門的會成為問題呢？因為這里關係到一個蜘蛛爬行效率的問題。你需要讓蜘蛛優先爬行你關心的那部分，比如你只想讓Google爬取/zh-cn/的目錄，那你可能會利用robots.txt針對Google蜘蛛把其他目錄disallow掉。但是sitemap卻無法為某個特別的搜索引擎定制規則，結果你還是必須要去站長平台去提交指定的sitemap地址。

3. 使用國家兩字代碼的子域名

這種方式也是我們常見的處理方式。優點很明顯，你不用去買多個域名。缺點也很明顯，它依然是一個獨立的網站。我們同樣可以總結一下：

優點：

1. 中等程度指引，排名優勢一般
2. 獨立網站，有自己的sitemap和robots.txt，受懲罰（如熊貓算法）也不會被“連坐”
3. 獨立網站，可根據受眾地區單獨優化提速
4. 可在Google Search Console中單獨設置面向地區
5. 不需要為每個國家和地區購買多個域名

缺點：

1. 中等程度指引，排名優勢一般
2. 全新網站需要重建DA。根域名對子域名並不傳遞DA。
3. 見效慢，一個新網站要重新被索引
4. 增加開發託管維護成本
5. 目標地區受眾無法充分感受到本土化的親切感，獲得信任能力一般

我們可以看到使用子域名是比較折衷的做法。在三者的比較中，它卻顯得最雞肋。因為如果你可以買幾個域名就能解決一些問題，那實在不應該省這些小錢，特別是對大型國際品牌來講更是這樣。我們在進行規劃的時候更應該考慮前兩者，而筆者更傾向於使用ccTLD，考慮到長遠之計。

hreflang和多語言部署

討論完了多個國家地區的SEO，我們來說多語言的部署。由於多個語言的內容時常會發生重複內容或者大量近似內容，不利於搜索引擎處理，於是就有了hreflang這個屬性標籤。

hreflang是谷歌引進的語言標籤， Google尚未明確表示支持，讀作h-ref-lang，即Hyperlink-Reference-Language 。 hreflang有多種使用方法，其中最常用的是在HTML中直接標出該網頁的其他版本。

假設你有一個頁面其URL為http://example.com/yemian.html。這個頁面有一個英文版本，那麼我們可以用hreflang來標示出來：

<link rel=”alternate” hreflang=”en-US” href=”http://example.com/page.html”>

在page.html上，你必須同樣用此標籤標出簡體中文的版本：

<link rel=”alternate” hreflang=”zh-CN” href=”http://example.com/yemian.html”>

如果你有更多的語言，如我們再加入日語，那麼在每個頁面上我們都需要標出其他所有語言的地址和本語言版本的地址。

yemian.html :

<link rel=”alternate” hreflang=”zh-CN” href=”http://example.com/yemian.html”>

<link rel=”alternate” hreflang=”en-US” href=”http://example.com/page.html”>

<link rel=”alternate” hreflang=”ja-JP” href=”http://example.com/peji.html”>

page.html :

<link rel=”alternate” hreflang=”zh-CN” href=”http://example.com/yemian.html”>

<link rel=”alternate” hreflang=”en-US” href=”http://example.com/page.html”>

<link rel=”alternate” hreflang=”ja-JP” href=”http://example.com/peji.html”>

peji.html :

<link rel=”alternate” hreflang=”zh-CN” href=”http://example.com/yemian.html”>

<link rel=”alternate” hreflang=”en-US” href=”http://example.com/page.html”>

<link rel=”alternate” hreflang=”ja-JP” href=”http://example.com/peji.html”>

請注意，這是相互承認的道理。即，你的頁面不能指認其他沒有指認回來的頁面作為你的另一語言版本。

如果你使用多個子域名或者多個ccTLD，你同樣必須通過hreflang來指引搜索引擎理解不同語言版本。在上面例子中中文、英語、日語三者非常不同，被認為是重複內容的可能性極小，但是如果是美國英語和英國英語、葡萄牙葡語和巴西葡語這樣的區別就比較小了。為了不讓搜索引擎認為兩個頁面的內容重複，我們必須要做好hreflang的部署。

在hreflang的使用過程中還有一些錯誤比較常見：

• 用_（underscore）取代-（hyphen）用於語言地區代碼中
• 只有地區，沒有語言（只有語言的情況是可以接受的）
• 地區在前，語言在後
• 使用多個x-default注：x-default為默認的語言版本，如果客戶端未指定語言版本或指定版本不可用，則服務器將伺服該版本。
• 在國家地區中使用EU和UK，這兩者並不是標準國家兩字代碼。前者不存在，後者需用GB

國際化SEO的兩個典型錯誤

在本文的最後，我們分享兩個典型的錯誤。

首先是谷歌說：“不要根據IP強制跳轉。”這樣做往往不單會影響收錄而且會影響用戶體驗。大多數時候谷歌的蜘蛛都來自美國IP，谷歌想要看到美國的用戶看到的網頁是怎麼樣的，如果美國用戶看到的頁面和其他國家用戶看到頁面不同那會產生問題。

第二個問題是通過瀏覽器語言，即HTTP Request Header中的Accept-Language屬性，來決定頁面伺服的內容。如果你使用Chrome瀏覽器訪問外語網站時，Chrome一般會問你要不要翻譯，如果你選擇不要翻譯該種語言，Chrome就會把這種語言放到Accept-Language中。通常谷歌的蜘蛛在爬行請求時並不會設置Accept-Language屬性，這樣來說蜘蛛看到的頁面就和用戶看到的會不同。這是典型的content cloaking，我們要注意避免。

The post International SEO不完全攻略 appeared first on Hubspot.one - Martech 與廣告行銷知識庫.