googlewebmaster-tcn: 7月 2015

#NoHacked：如何避免成為駭客攻擊的目標

2015年7月30日星期四

#NoHacked: How to avoid being the target of hackers作者：Eric Kuan, Webmaster Relations Specialist and Yuan Niu, Webspam Analyst
不論要在網路上發佈任何內容，都必須優先確保資料內容的安全性。遭到駭客入侵不僅會對您的網路形象產生負面影響，還會造成重要私人資料的損失。過去一年來，Google 發現遭到入侵的網站數量增加了 180%。在我們努力抵禦駭客入侵攻勢的同時，您也可以採取以下措施來保護自己的線上內容。

在 7 月，我們將繼續進行 #nohacked 推廣活動。這個月的重點是介紹如何避免網站遭受駭客攻擊，並讓您更深入瞭解這些駭客活動的方式。您可以在 Twitter 和 Google+ 上追蹤 #nohacked 推廣活動。在活動結尾，我們也會針對安全性問題舉辦一場 Google Hangouts，開放與會者向我們的安全性專家提問。在推廣活動開始之際，讓我們先為您提供一些維護網站安全的基本提示。提高帳戶安全性設定一個難以猜到或破解的密碼，是保護網站安全的先決要務。舉例來說，您可以在密碼中混用字母、數字及符號，或是指定一句通關密語。此外，密碼長度的重要性也不可輕忽，因為密碼越長，就越難被破解。網路上有許多資源可讓您測試密碼強度，您可以使用與自身密碼相似的密碼進行測試 (請不要在任何其他網站上輸入您真正的密碼)，即可瞭解自身密碼的大致強度。另外，請避免在不同服務中使用相同的密碼，因為當攻擊者取得他處洩漏的密碼清單或成功入侵其他服務後，常會利用從這些地方取得的使用者名稱和密碼組合企圖入侵更多帳戶。如果您的帳戶支援雙重驗證機制，建議您一併啟用這項功能。如此一來，便能大幅提升您的帳戶安全性，防禦各種形式的帳戶攻擊。我們會在兩週後更詳細地說明雙重驗證的優點。隨時更新網站所使用的軟體網站上存在的軟體漏洞，是駭客用來入侵網站的一種常見途徑。因此，請務必定期檢查您的網站是否有任何未更新的軟體，特別是針對安全性漏洞修補所做的更新。如果您使用 Apache、nginx 這類網路伺服器或商業網路伺服器軟體，請務必即時修補安全性漏洞。如果您的網站使用了內容管理系統 (CMS)、任何外掛程式或附加元件，則必須確保這些工具都是最新版本。另外，請為您的網路伺服器軟體和 CMS (如有使用) 註冊安全公告清單。也建議您將網站上不需要的附加元件和軟體全部移除，因為這些項目既可能造成安全性風險，也可能使網站效能降低。研究您的代管服務供應商如何處理安全性問題選擇代管服務供應商時，請務必將其安全性政策和對於網站遭入侵的處理方式納入考量。如果您目前有合作的代管服務供應商，您可以嘗試向對方瞭解，當您需要請他們協助處理個別網站問題時，是否能得到即時支援。您也可以參考網路上的評論，看看各家供應商是否有協助使用者清理網站上遭駭內容的實際業務。如果您自行管理伺服器，或使用虛擬私人伺服器 (VPS) 服務，則必須隨時準備處理可能發生的安全性問題。伺服器管理工作相當複雜，而伺服器管理員的其中一項重要工作，就是確保網路伺服器和內容管理軟體的漏洞和問題均已妥善修正，並且已更新到最新版本。如果您沒有必要自行管理伺服器，不妨花點時間瞭解您的代管服務供應商是否有提供管理服務。使用 Google 的各項工具即時瞭解網站上是否有駭客植入或竄改過的內容擁有可讓您主動監控網站的工具是很重要的，因為能夠越早發現網站遭到入侵的跡象，您就能越早修復網站。如果您尚未申請使用 Search Console，建議您可以試試這項服務。如果 Google 在您的網站上偵測到任何問題 (例如發現遭駭客植入或竄改過的內容)，就會透過 Search Console 通知您。您也可以為自己的網站設定 Google 快訊，以便在網站有可疑的結果時收到通知。舉例來說，如果您使用 www.example.com 這個網址經營了一家販售寵物配件網站，則可針對 [site:example.com <特價軟體>] 這個字串建立快訊；這樣一來，當您的網站遭到駭客入侵，突然出現關於特價軟體的內容時，您就會收到相關的通知。您可以使用不同的垃圾字詞為自己的網站建立多個快訊。如果您不知道該使用哪些垃圾字詞，請使用 Google 搜尋常見垃圾字詞。希望這些提示能幫助您在網路上維護您的網站安全。敬請追蹤我們的社交推廣活動，也歡迎透過 #nohacked 主題標記，分享任何關於維護網路安全的提示或技巧。如果還有其他問題，歡迎前往網站管理員說明論壇提問，該網站管理員社群中的其他成員會非常樂意回答您的問題。您也可以加入我們在8月26日針對安全性議題所舉辦的 Hangouts 直播。

Autocomplete API 更新

2015年7月26日星期日

Update on the Autocomplete API Peter Chiu, Autocomplete teamGoogle 搜尋提供的自動完成服務會在使用者輸入搜尋字詞的當下，嘗試預測查詢字詞。多年來，許多開發人員使用非官方和未發佈的 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 申請網頁中的說明。

Google+：應用程式下載插頁廣告的個案研究

2015年7月26日星期日

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

我們決定以 Google+ 行動網路平台做為觀察對象，進一步檢視插頁廣告的使用效果。在我們進行內部使用體驗調查後，發現使用者對插頁廣告的觀感不佳，而 Jennifer Gove 去年在 IO 大會上的精彩演講也強調了這一點。
雖然我們憑直覺認為應該移除插頁廣告，但我們更相信數字會說話這個不變的道理，於是我們開始研究插頁廣告對使用者的影響。分析結果顯示：

＊9% 造訪插頁廣告頁面的使用者按下了 [取得應用程式] 按鈕 (請注意，這之中包含已安裝應用程式的人，以及其後並未在應用程式商店下載應用程式的人)。

＊69% 造訪插頁廣告頁面的使用者直接離開了頁面。他們既沒有前往應用程式商店，也沒有繼續瀏覽我們的行動網站。

儘管對任何廣告活動來說，9% 聽來是很不錯的點閱率，但是我們更重視的數字其實是那些因為插頁廣告造成負面體驗而放棄探索我們產品的使用者人數。得到這樣的數據後，我們在 2014 年 7 月決定進行一項實驗，看看移除插頁廣告對產品的實際使用情形有何影響。我們參考行動版網站搜尋引擎最佳化指南中避免常見錯誤一節的建議，加入了 Smart App Banner，以干擾性較低的方式繼續宣傳原生應用程式，而實驗結果著實令人驚艷：

＊我們行動網站上的單日活躍使用者增加了 17%。

＊Google+ iOS 原生應用程式的安裝次數幾乎沒有受到影響 (減少 2%；大部分 Android 裝置均內建 Google+，所以此處不列出 Android 裝置的安裝次數資料)。

基於以上結果，我們決定讓插頁廣告永遠退出歷史舞台。我們認為能讓產品的使用人數增加，代表這樣的改變對產品絕對只有好處。希望將這個經驗與您分享後，您可以重新考慮是否繼續使用插頁廣告來宣傳應用程式。歡迎您和我們一起排除障礙，創造更方便實用的行動網路環境！

Google 如何處理新的頂層網域

2015年7月22日星期三

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 會提供任何相關支援嗎？我該如何在遷移網站的同時確保搜尋排名或紀錄不會因此受到任何影響？

答：我們的說明中心提供了各種網站遷移說明文件供您參考。我們會按照處理其他網站遷移作業的方式來處理這類網站遷移。也就是說，搜尋服務需要一段時間來處理網域異動 (除了搜尋之外，使用者也會希望原本的電子郵件地址能夠再使用一段時間)，因此一般而言，建議您最好選擇能夠符合長期所需的網域。

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

中文網站管理員 - 中文網誌

#NoHacked：如何避免成為駭客攻擊的目標

Autocomplete API 更新

Google+：應用程式下載插頁廣告的個案研究

Google 如何處理新的頂層網域

标签

博客归档

Feed

公司範圍

產品

開發人員