Posted:
原文:Update on the Autocomplete API
作者: Peter Chiu,  Autocomplete team

Google 搜尋提供的自動完成服務會在使用者輸入搜尋字詞的當下,嘗試預測查詢字詞。多年來,許多開發人員使用非官方和未發佈的 API,將自動完成的結果與自己的服務進行整合,而且完全不加以限制。後來,發現自動完成 API 的開發人員整合了自動完成服務,而且讓這項服務獨立於 Google 搜尋之外。

開發人員社群會透過未發佈的 API,對特定 Google 服務進行反向工程,而且多次獲得驚人的成果。舉例來說,我們看到創意十足的工程師將地圖資料和其他資料來源加以結合,創造出絕佳的功用,因此我們在幾個月之後,決定將 Google Maps API 列為正式受支援的 API。我們目前支援超過 80 個 API,可供開發人員用來將 Google 服務整合至個人的應用程式。
不過,在某些情況下,使用不支援且未發佈的 API,也可能導致該 API 停止提供服務。這個情況就是其中一例。

我們建立自動完成功能是為了讓搜尋功能更加完善,從未想過這項功能會用於與預測使用者搜尋查詢完全無關的用途。長久下來我們瞭解到一件事,雖然我們想像得到將自動完成資料資訊提供運用在與搜尋結果無關的用途上,可能會帶來些許價值,但總體來說,我們自動完成功能的內容原本就是為了與網路搜尋結果配合使用,而且已針對這項用途進行最佳化,因此將這項功能應用在網路搜尋之外的情況並無法為使用者提供實質助益。

為了讓搜尋中的自動完成功能維持完整性,我們將於2015年8月10日起,限制未經授權的人士存取尚未發佈的自動完成 API。我們想確保使用者能受惠於自動完成功能的原始設計功用,也就是與搜尋緊密結合的服務。我們相信這樣才能使這兩項服務提供最佳使用體驗。

對於仍想在個人網站上使用自動完成服務的發佈者和開發人員,我們有個替代方案。Google 自訂搜尋引擎可讓網站繼續使用搜尋功能中的自動完成功能。這項異動不會影響到任何已使用 Google CSE 的合作夥伴。至於其他使用者,如果您想在2015年8月10日後繼續使用自動完成功能,請參閱我們 CSE 申請網頁中的說明。

Posted:
原文:Google+: A case study on App Download Interstitials
作者:David Morell, Software Engineer, Google+

許多行動網站會利用應用程式插頁廣告進行宣傳,鼓勵使用者下載自家的原生行動應用程式。有的原生應用程式不僅能提供更豐富的使用體驗,就連目前難以透過瀏覽器執行的一些裝置功能,也都能為其所用。因此,很多應用程式擁有者都認為,他們應該多多鼓勵使用者安裝自家線上資源或服務的原生應用程式。不過目前我們還不清楚如何拿捏宣傳應用程式的力度,而整頁的插頁廣告實際上也可能妨礙使用者取得需要的內容。

我們決定以 Google+ 行動網路平台做為觀察對象,進一步檢視插頁廣告的使用效果。在我們進行內部使用體驗調查後,發現使用者對插頁廣告的觀感不佳,而 Jennifer Gove 去年在 IO 大會上的精彩演講也強調了這一點。

雖然我們憑直覺認為應該移除插頁廣告,但我們更相信數字會說話這個不變的道理,於是我們開始研究插頁廣告對使用者的影響。分析結果顯示:
  • *9% 造訪插頁廣告頁面的使用者按下了 [取得應用程式] 按鈕 (請注意,這之中包含已安裝應      用程式的人,以及其後並未在應用程式商店下載應用程式的人)。
  • *69% 造訪插頁廣告頁面的使用者直接離開了頁面。他們既沒有前往應用程式商店,也沒有      繼續瀏覽我們的行動網站。
儘管對任何廣告活動來說,9% 聽來是很不錯的點閱率,但是我們更重視的數字其實是那些因為插頁廣告造成負面體驗而放棄探索我們產品的使用者人數。得到這樣的數據後,我們在 2014 年 7 月決定進行一項實驗,看看移除插頁廣告對產品的實際使用情形有何影響。我們參考行動版網站搜尋引擎最佳化指南中避免常見錯誤一節的建議,加入了 Smart App Banner,以干擾性較低的方式繼續宣傳原生應用程式,而實驗結果著實令人驚艷:
  • *我們行動網站上的單日活躍使用者增加了 17%。
  • *Google+ iOS 原生應用程式的安裝次數幾乎沒有受到影響 (減少 2%;大部分 Android 裝置      均內建 Google+,所以此處不列出 Android 裝置的安裝次數資料)。
基於以上結果,我們決定讓插頁廣告永遠退出歷史舞台。我們認為能讓產品的使用人數增加,代表這樣的改變對產品絕對只有好處。希望將這個經驗與您分享後,您可以重新考慮是否繼續使用插頁廣告來宣傳應用程式。歡迎您和我們一起排除障礙,創造更方便實用的行動網路環境!

Posted:
原文:Google's handling of new top level domains
作者: John Mueller,Webmaster Trends Analyst

由於新的一般頂層網域 (gTLD) 越來越多,在此我們為您提供進一步的說明,協助您瞭解 Google 搜尋服務如何處理這些頂層網域。據我們所知,使用者對於 Google 處理 .guru、.how 或 .BRAND 等等新型一般頂層網域 (TLD) 的方式有許多疑問及誤解,以下是一些常見問題:
問:新的 gTLD 會對搜尋服務造成什麼影響?Google 會修改搜尋演算法以偏重這些 TLD 嗎?這些 TLD 對搜尋結果的實際影響力為何?
答:整體而言,我們的系統處理這些新 gTLD 的方式和處理其他 gTLD (例如 .com 與 .org) 的方式並無不同。TLD 中的關鍵字不會對搜尋結果產生任何正面或負面影響。
問:IDN TLD (例如 .みんな) 的情況又是如何呢?Googlebot 會檢索這類 TLD 並且建立索引,來支援搜尋功能嗎?
答:是的。我們使用這些 TLD 的方式與其他 TLD 無異 (確認的方法十分簡單,只要使用 [site:みんな] 這類查詢就可以了)。Google 處理 Punycode 版本主機名稱的方式和處理未編碼版本的方式相同,因此您無需個別重新導向或加以標準化。至於網址的其他部分,使用非 ASCII 字元時,請務必使用 UTF-8 處理路徑和網址的查詢字串。
問:.BRAND TLD 在搜尋結果中的加權比重會與 .com 有任何差異嗎?
答:沒有差異。我們處理這些 TLD 的方式和處理其他 gTLD 的方式相同。這些 TLD 必須具備同樣的地理定位設定和組態;而我們在檢索這些網址、建立索引或進行排名時,都不會為這些 TLD 提供更多加權或改變任何處理方式。

問:Google 如何處理新的區域 TLD 或城市 TLD (例如 .london 或 .bayern)?
答:即使某些 TLD 明顯為區域專屬的 TLD,我們依然會以處理 gTLD 的方式來處理這類 TLD。我們在處理地區性 TLD (例如 .eu 和 .asia) 時也採取同樣的做法。日後可能會有些許例外情況,這取決於實務上的使用情形。如需進一步瞭解多地區和多語言版本的網站,以及如何在 Search Console 指定相關的地理區域,請前往說明中心參閱相關文章。

問:真正的 ccTLD (國家/地區代碼頂層網域) 情況又是如何呢?使用者在這些國家/地區中進行搜尋時,Google 會因為本地網域而偏重 ccTLD (例如 .uk、.ae 等) 嗎
答:依據預設,多數的 ccTLD (包括例外情況) 都會導致 Google 使用這些 ccTLD 來為網站指定地理區域;也就是說,這些 ccTLD 能夠讓我們得知該網站可能與特定國家/地區的關聯性更高。再次提醒您,如需進一步瞭解多地區和多語言版本的網站,請前往說明中心參閱相關文章。

問:我為了達成搜尋引擎最佳化 (SEO) 的目標,將網域從 .com 遷移至新的 TLD,Google 會提供任何相關支援嗎?我該如何在遷移網站的同時確保搜尋排名或紀錄不會因此受到任何影響?
答:我們的說明中心提供了各種網站遷移說明文件供您參考。我們會按照處理其他網站遷移作業的方式來處理這類網站遷移。也就是說,搜尋服務需要一段時間來處理網域異動 (除了搜尋之外,使用者也會希望原本的電子郵件地址能夠再使用一段時間),因此一般而言,建議您最好選擇能夠符合長期所需的網域。

希望上述的說明有助您進一步瞭解我們如何處理新的頂層網域。如有任何問題,歡迎在此提出,或是前往說明論壇提問。

Posted:
原文:App deep linking with goo.gl
作者:Fabian Schlup, 工程師

即日起,無論您的內容是在 Android 應用程式中、 iOS 應用程式中還是網站中,您都可以將 goo.gl 短連結設為單獨的連結並套用到自己所有的內容。 按照必要的步驟針對 Android 和 iOS 將應用程式編入索引後, goo.gl 網址就會將已安裝您的應用程式的使用者直接導向應用程式中的適當頁面,並將其他使用者導向您的網站。這樣一來,您的應用程式使用者就會有更多機會再次與您的應用程式互動。

這樣功能既適用於新的短網址,也適用於以前的網址。因此,連結到您內容的全部現有 goo.gl 短連結也會將使用者導向您的應用程式。



分享「因平台制宜」的連結

如要充分發揮這項功能的作用,您也可以將 URL Shortener API 整合到應用程式的分享流程中,這樣使用者分享的連結就會將訪客自動重新導向您的跨平台原生應用程式。此外,其他人也可以在自己的網站和應用程式中嵌入透過深層連結直接連到您應用程式的連結。

以 Google 地圖為例,有了全新的跨平台 goo.gl 連結,透過地圖的分享按鈕所產生的連結就能為每個人提供最理想的分享方式。開啟後,該連結會自動偵測使用者的作業平台並檢查他們是否安裝了 Google 地圖。如果使用者安裝了 Google 地圖,短連結就會直接在 Android 或 iOS 裝置上的 Google 地圖應用程式中開啟相關內容。如果使用者未安裝該應用程式或者透過桌機瀏覽,短連結就會開啟 Google 地圖網站上的相關網頁。

您不妨來試一下!測試前別忘了在手機上安裝 Google 地圖應用程式:http://goo.gl/maps/xlWFj

設定方式 

如何透過 goo.gl 設定應用程式深層連結:

  1. 參閱 g.co/AppIndexing,完成相關必要步驟,將 Android 和 iOS 應用程式編入Google 搜尋索引。請注意,凡是 iOS 開發人員都可以使用 goo.gl 深層連結,這與目前透過 Google 搜尋提供的深層連結不同。完成此步驟後,現有的 goo.gl 短連結就會透過深層連結將使用者導向您的應用程式。
  2. 您可以視需要將 URL Shortener API 整合到應用程式的分享流程、您的電子郵件廣告活動等項目中,透過程式產生會以深層連結形式直接連回您應用程式的連結。



希望您喜歡這個新功能,並且擁有愉快的跨平台分享體驗!

Posted:
原文:Surfacing content from iOS apps in Google Search
作者:Eli Wald, 產品經理

最近我們一直致力於協助使用者在 Google 搜尋結果中尋找 Android 應用程式中的相關內容,即日起,「應用程式索引」功能也可以運用在 iOS 應用程式上,也就是說,Android 和 iOS 的使用者都可以直接透過 Google 搜尋開啟行動應用程式內容。

在未來幾天內,首批已經編入索引中的應用程式連結將陸續顯示在 Google App 以及 Chrome 的搜尋結果中,全球的已登入使用者皆可透過 iOS 裝置看見:


如何將您的 iOS 應用程式編入索引

雖然即將推出的 iOS 應用程式索引功能只有為數不多的合作夥伴參與測試,但我們正持續努力,希望能盡快開放這項技術給更多應用程式開發人員。與此同時,您可以按照下列步驟搶先體驗 iOS 應用程式索引功能:
1. 在您的 iOS 應用程式中新增深層連結支援功能。 
2. 確保使用者只要點擊一次就可以返回搜尋結果
3. 在您的網站上提供深層連結註解
4. 如果您對此感興趣,請與我們聯絡。請注意,將您的意願告知我們,並不保證您的應用程式深層連結一定會顯示在 iOS 搜尋結果中。


如果您會參加本週的 Google I/O 大會,可以注意一下「將您的應用程式編入 Google 索引」這場演講,以便進一步瞭解「應用程式索引」功能。您也可以在 g.co/AppIndexing 找到有關 iOS 應用程式索引的詳細說明文件。如果您有其他任何問題,請參閱網站管理員說明論壇

Posted:
作者:Hillel Maoz, Engineering Lead, Search Console Team (favorite app: Flipboard) and Mariya Moeva, Webmaster Trends Analyst (favorite app: Spotify)

對於已編入索引的應用程式內容,如果您能夠追蹤這些內容在搜尋結果中的所在位置和對應的查詢、瞭解哪些應用程式頁面最受歡迎,以及哪些頁面含有錯誤內容,是不是很棒呢?正因為我們也有相同的感受,所以在最近改名的 Search Console 中,我們加入了新的報表功能,希望有助您瞭解 Google 如何解讀您的應用程式內容,以及 Google 如何在搜尋結果中顯示您的應用程式內容。我們的目標是讓所有關心自家內容搜尋表現的使用者,無論採用何種內容格式,都能在 Search Console 找到最全面的資訊。因此,如果您是應用程式的擁有者或開發人員,那麼 Search Console 將是您獲得搜尋統計資料的新選擇。

將您的應用程式加入 Search Console
只要開啟 Search Console,然後輸入您的應用程式名稱 (例如 android-app://com.example) 就行了。當然,我們只會將資料提供給已獲得授權的應用程式擁有者;有鑑於此,您必須登入自己的 Google Play 帳戶,讓 Search Console 知道您有權存取相關的應用程式。如果您在 Google Play 中並沒有相關應用程式的存取權,可以請應用程式擁有者在 Search Console 中驗證該應用程式並將您加入。

為您的網站與應用程式建立連結
您必須將您的網站與應用程式建立關聯,才能夠讓應用程式索引服務發揮作用。這也有助於我們充分瞭解您的應用程式內容,並使其在搜尋結果中獲得更高的排名。

追蹤您的應用程式內容在搜尋結果中的曝光情況
我們新推出的搜尋分析報表會提供各類詳細資訊,協助您掌握應用程式內容搜尋相關資料,例如在各個國家/地區的熱門查詢、熱門應用程式頁面以及流量。不僅如此,這份報表也提供了齊全的篩選條件,透過這些篩選條件,您可以查看特定查詢類型或特定地區的資料,還能依照點擊次數、曝光次數、點閱率和排名來排序相關資料。

使用搜尋分析報表時,您可以將您認為最重要的應用程式內容與實際出現在搜尋結果中且點擊次數最高的內容進行比對。如果兩者相符,就表示目前一切都在正軌上。也就是說,使用者不僅如您所願找到了對的內容,對於結果也很滿意。如果這兩者中只有少量內容是相同的,表示您可能需要調整導覽方式,或者讓最重要的內容更容易找到。此外,您不妨確認一下:對於您想要呈現給使用者的應用程式內容,您是否全都提供了深層連結?

確保 Google 能夠解讀您的應用程式內容
如果我們在為應用程式內容建立索引時遇到錯誤,就無法在搜尋結果中顯示這些應用程式頁面的深層連結。您可以透過檢索錯誤報告查看我們偵測到的錯誤類型和數量。

以 Google 的角度檢視您的應用程式內容
我們開發了應用程式專用的 Google 擷取工具 Alpha 版本,以便協助您檢查應用程式 URI 能否正常運作,並查看 Google 對於應用程式 URI 的轉譯效果。您也可以使用這項工具來比較應用程式內容和網頁內容,以便排除各項錯誤 (例如內容不相符)。大多時候,內容不相符錯誤是因為應用程式內有資源遭到封鎖,或是要求使用者登入或註冊的彈出式視窗所造成的。現在,您可以找出這些問題並且予以解決。


如果您想讓自己的應用程式擁有最佳表現,並解決其中隱藏的各種問題,請立即將其加入 Search Console。如要進一步瞭解「應用程式索引服務」,請造訪我們的開發人員網站閱讀相關資訊。如果您有其他問題,歡迎前往網站管理員說明論壇提問。


Posted:
作者:Michael Fink,Google Search Console 

近十年來,Google 網站管理員工具一直在推陳出新,讓使用者可以運用各式各樣的工具和指標來打造令人驚豔的網站,而這些網站也都能在 Google 搜尋系統中得到極佳的網站排名。去年,我們試圖進一步認識各位 Google 網站管理員工具的忠實使用者,希望瞭解您所扮演的角色和追求的目標,能夠讓我們的產品更貼近您的需要。
經過這些努力,我們發現各位之中其實只有部分人士符合「網站管理員」這個傳統角色的定位。網站管理員工具的愛用者遍及各行各業,包括特定興趣的愛好者、小公司業主、搜尋引擎最佳化專家、行銷人員、程式設計師、設計師、應用程式開發人員,網站管理員自然也在其中。各位的共同之處在於,大家都想在網路上提供自己的內容,也都想讓使用者透過 Google 搜尋找到自己的內容。因此,為了確保所有關注 Google 搜尋的人都能使用我們的產品,我們決定將 Google 網站管理員工具更名為 Google Search Console
我們期望透過 Google Search Console 開創精彩的未來,也希望各類型的使用者 (包括網站管理員) 能夠親身體驗、使用我們的服務診斷自己的網頁內容,藉以提高在網路搜尋的曝光度。接下來幾週,我們將陸續推動這項產品更名的相關作業,敬請密切注意。
歡迎前往 g.co/SearchConsole,立即開始使用 Google Search Console!