Posted:
作者:Michael Fink,Google Search Console 

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

Posted:
原文:Case Studies: Fixing Hacked Sites
作者:Julian Prentice and Yuan Niu, Search Quality Team

每天都有數以千計的網站遭到入侵,而遭到入侵的網站往往會提供惡意軟體、收集個人資訊或將使用者導向他們無意造訪的網站,可能因此對使用者造成損害。雖然網站管理員會努力儘速修復遭到入侵的網站,但是修復這類網站的程序往往相當複雜。

我們正致力於為網站管理員簡化網站遭到入侵的修復程序。為此,我們提供了等多項資源,例如安全性問題網站遭駭客入侵的相關說明討論網站入侵問題的論壇專區。近來我們也與兩位網站曾遭到入侵的網站管理員會談,進一步瞭解他們修復網站的方法。我們會在本文中分享這兩位網站管理員的經驗,希望能讓其他為駭客入侵所苦的網站管理員做為參考。此外,我們也會根據這類實務案例以及各方的反應,改善關於網站遭駭客入侵的說明文件,讓日後所有的網站管理員都能透過更簡便的流程修復遭到入侵的網站。

個案研究 #1:遭到駭客植入多個指令碼的餐廳網站
某間餐廳使用 Wordpress 架設網站,但該餐廳的網站管理員工具帳戶收到 Google 發出的訊息,警告管理員網站已經遭到駭客入侵。為了保護 Google 使用者,Google 已在搜尋結果中將這個網站標示為遭到入侵的網站。餐廳網站的管理員小珊在查看程式碼之後,發現網站上出現許多陌生連結,且其中包含「viagra」(威而鋼) 和「cialis」(犀利士) 等醫藥詞彙。同時她也注意到,許多網頁的中繼描述標記 (在 HTML 中) 都加入了類似「在佛羅里達州購買怯疹易」的內容,還有不少網頁的隱藏式 div 標記 (也在 HTML 中) 會連結到其他網站,但這些連結都不是小珊自己加入網站中的。

小珊將所有她發現遭到駭客入侵的內容全數移除,然後申請重審。Google 拒絕了這項重審申請,但在給她的訊息中建議她檢查所有 PHP 檔案 (或任何伺服器檔案) 中是否含有陌生的指令碼,同時也建議她檢查 .htaccess 檔案是否曾有任何異動。這是因為駭客可能會在上述檔案中加入用來竄改網站內容的指令碼,而這類指令碼只會對搜尋引擎顯示遭到駭客入侵的內容,一般使用者看不到這些內容。小珊仔細檢查了所有的 .php 檔案,並與她自己保留的備份複本對照,發現 footer.php、index.php 和 functions.php 檔案中都出現了新的內容。小珊用遭到入侵前的版本取代這些檔案之後,網站上就再也找不到任何遭到駭客入侵的內容。當她再次提出重審申請後,Google 就通知她網站上已經沒有遭到入侵的內容了!

雖然小珊這次成功清除了網站上遭到駭客入侵的內容,但她也瞭解到自己必須持續加強網站的安全防護措施,避免日後再次遭遇駭客攻擊。為了確保網站的安全性,小珊採取了下列步驟:
  • 將 CMS (內容管理系統,例如 WordPress、Joomla、Drupal 等) 保持在最新版本,同時也確保外掛程式是最新版本。
  • 為用來存取 CMS 管理功能的帳戶設定不易破解的專用密碼。
  • (如果 CMS 支援) 為登入流程啟用兩步驟驗證功能 (或稱為「雙重因素驗證」或「2 步驟驗證」)。建議您也為密碼救援使用的帳戶設定兩步驟驗證,大部分電子郵件供應商 (例如GoogleMicrosoft 和 Yahoo) 都支援這項功能!
  • 確認所安裝的外掛程式和主題的來源可靠,因為盜版的外掛程式或主題往往含有惡意程式碼,將為駭客大開方便之門!
個案研究 #2:包含許多遭到入侵的網頁卻找不到所在位置的公司網站
瑪莉亞經營一家小公司,並親自管理公司的網站。某天她在網站管理員工具中收到訊息,得知她的網站遭到駭客入侵。訊息中提供了一個由駭客植入的網頁示例:http://example.com/where-to-buy-cialis-over-the-counter/。瑪莉亞詢問主機供應商,但對方檢查首頁的程式碼後並沒有找到任何與藥品相關的關鍵字,造訪 http://example.com/where-to-buy-cialis-over-the-counter/ 時,系統則會傳回錯誤頁面。瑪莉亞也購買了惡意軟體掃描服務,但仍無法從她的網站中找出任何惡意內容。

於是瑪莉亞開啟網站管理員工具,使用 Google 模擬器工具存取 Google 提供的示例網址 (http://example.com/where-to-buy-cialis-over-the-counter/),可是系統並未傳回任何內容。在困惑之餘,瑪莉亞向 Google 提出了重審申請,但遭到拒絕。Google 在發送給她的拒絕重審通知中建議她採取以下兩個動作:
  1. 驗證非 www 版本的網站;這是因為駭客常會試圖將內容隱藏在網站管理員容易忽略的資料夾中。
雖然 http://example.com 和 http://www.example.com 看起來像是同一個網站,但實際上 Google 會將其視為不同的網站。http://example.com 會被視為「根網域」,http://www.example.com 則稱為「子網域」。瑪莉亞雖已驗證 http://www.example.com,但卻沒有驗證 http://example.com;這是相當重要的關鍵,因為駭客加入的是非 www 網頁 (例如 http://example.com/where-to-buy-cialis-over-the-counter/)。只要瑪莉亞驗證 http://example.com 之後,就可以透過網站管理員工具中的 Google 模擬器工具,查看 Google 提供的網址中遭到入侵的內容。
  1. 檢查 .htaccess 檔案中是否出現新規則。
瑪莉亞與主機供應商聯絡,對方為她說明了如何存取 .htaccess 檔案。她立刻注意到 .htaccess 檔案中出現了一些她從未加入過的奇怪內容:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (google|yahoo|msn|aol|bing) [OR]
RewriteCond %{HTTP_REFERER} (google|yahoo|msn|aol|bing)
RewriteRule ^([^/]*)/$ /main.php?p=$1 [L]
</IfModule>

以上 mod_rewrite 規則就是駭客植入的,會將透過特定搜尋引擎進入網站的任何訪客和搜尋引擎檢索器重新導向至 main.php,所有遭到入侵的內容都是由這個檔案產生的。此外,這些規則也有可能將使用行動裝置造訪網站的使用者重新導向。當天瑪莉亞就看到新的惡意軟體掃描工具在這個 main.php 檔案中找到可疑內容。除此之外,她也在網站開發軟體的 FTP 使用者區域中發現了一名來路不明的使用者。

瑪莉亞移除了 main.php 檔案和 .htaccess 檔案,也將 FTP 使用者區域中的不明使用者移除,終於解決了網站遭到入侵的問題!

避免日後遭到入侵的防範步驟
  • 請避免使用 FTP 將檔案傳送到您的伺服器,因為 FTP 無法加密流量,也無法為密碼加密。建議您改用 SFTP,即可為包括密碼在內的所有資料進行加密,這項保護措施可以防止監視網路流量的有心人士竊取資料。
  • 檢查機密檔案 (例如 .htaccess) 的存取權限;如需相關說明,請向您的主機供應商尋求協助。.htaccess 檔案可用於改善及保護網站,但如果不慎讓駭客取得存取權限,也會被用於惡意入侵行為。
  • 請保持警惕,對於管理介面和任何其他可供使用者修改網站內容的地方,請留意其中是否出現陌生的新使用者。
我們誠摯希望您的網站不會遭到駭客入侵,但如果不幸遇到這類問題,我們在網站遭駭客入侵的相關說明頁面中為網站遭駭的管理員提供了許多資源。如果您需要進一步的說明,或是想分享自己的獨門防駭訣竅,歡迎前往我們的網站管理員說明論壇張貼文章。在論壇張貼文章或申請重審網站時,請在文中加入「#NoHacked」。

Posted:
原文:Easier website development with Web Components and JSON-LD
作者:Posted by Ewa Gasperowicz, Developer Programs Engineer, Mano Marks, Developer Advocate, Pierre Far, Webmaster Trends Analyst


JSON-LD 是以 JSON 為基礎的資料格式,這種資料格式可用來實作結構化資料,向 Google 和其他搜尋引擎描述您網站上的內容。舉例來說,如果您有一份有關活動、餐館、人物或其他內容的清單,那麼您可以透過結構化格式在自己的網頁上加入這項資料,只要以 JSON-LD 程式碼片段形式將 schema.org 詞彙嵌入網頁中即可。結構化資料有助於 Google 理解您的網頁內容,進而在某些搜尋功能 (例如知識圖譜中的活動複合式摘要) 中突顯您的內容。

Web Component 是仍處於初期發展階段的一組技術元件,作用是定義可重複使用的自訂使用者介面小工具及其行為模式。任何網頁開發人員都可以自行建立 Web Component。如要建立 Web Component,請先找到一個明確的使用者介面,然後為這部分的介面定義範本,並匯入網頁中,之後就能在網頁上使用這個 Web Component。Custom Element 可用來定義 Web Component 的行為模式。由於您已將使用者介面部分的顯示和邏輯關係統合到 Web Component 中,所以可以輕鬆將這部分內容與他人共用、重複應用到其他網頁上或提供給其他開發人員,進而達到簡化網頁開發作業的目的。

JSON-LD 和 Web Component 的搭配相當契合。Custom Element 可做為展示層,而 JSON-LD 可做為資料層,供 Custom Element 和搜尋引擎取用。也就是說,您可以建立任何 schema.org類型的 Custom Element,例如        schema.org/Event 和
 schema.org/LocalBusiness

就實際上的架構而言,您的結構化資料會儲存在資料庫中 (例如您的連鎖商店所在位置的資訊)。這項資料會以 JSON-LD 程式碼片段的形式嵌入網頁內,讓 Custom Element 可以調用該資料來提供給訪客查看,而 Googlebot 也可以擷取這項資料來建立 Google 搜尋索引。
如要進一步瞭解 Custom Element,並開始使用這個介面,請參閱下列資源:
             *我們在 webcomponents.org 發佈的最新文章和附帶的程式碼範例。
             *JSON-LD 網站和 W3C 規格
             *Web Component 維基和 Web Component 社群 (位於 webcomponents.org)

Posted:
原文:More precise data in the new Search Analytics report
作者:Zineb, 代表Google管理員工具團隊工程師和UX設計團隊

如果您是網站管理員,就必須深入瞭解使用者如何找到您的網站,以及網站內容在 Google 搜尋結果中的顯示方式。截至目前為止,這類資料均列在「搜尋查詢」報表中,而「搜尋查詢」報表也可能是網站管理員工具中最常使用的功能。過去這些年來,我們一直在傾聽您的意見,以及您對功能方面的需求。比方說,有人希望比較電腦版和行動版的流量,也有人需要比較不同的國家/地區或兩個不同時段的指標。
各位的種種需求我們都聽見了!今天,我們很高興在此宣佈 Google 網站管理員工具推出了全新的搜尋分析報表,可協助您充分利用流量分析資料。

新版「搜尋分析」報表會解析網站的搜尋資料,並且透過各種不同的方式進行篩選,為您提供更精確的分析結果。舉例來說,您可以比較 4 月 21 日行動裝置相容性更新前與更新後的行動裝置流量,進而瞭解這項更新對流量帶來的影響。

或者,如果您擁有國際性的網站,現在您可以掌握最常搜尋您品牌的使用者來自哪些國家/地區:選擇「曝光數」做為指標,使用您的品牌名稱進行篩選後,依照國家/地區將結果區分為不同的群組,即可按國家/地區顯示曝光數分類清單。

上述的範例僅僅是其中兩種應用方式,還有更多應用方式待您發掘。「搜尋分析」報表可讓您真正深入進行流量分析,協助您針對網站效能做出最適當的決策。
「搜尋分析」和「搜尋查詢」報表兩者間有些許差異。「搜尋分析」報表中的資料比舊版「搜尋查詢」報表更準確,運算方式也有所不同。如要瞭解詳情,請參閱「搜尋分析」說明中心文章的資料專區。我們瞭解有些管理員可能仍然需要使用舊版報表,因此我們決定暫時在 Google 網站管理員工具中繼續提供舊版報表服務,為期三個月。如要進一步瞭解新版報表,請參閱搜尋分析說明中心文章。
希望新版「搜尋分析」報表能夠在您進行流量分析時,為您提供更多協助。如果您有任何意見,歡迎在下方留言分享,或者前往 Google 網站管理員 Google+ 專頁告訴我們。如果您有任何問題或需要報表相關協助,也歡迎至網站管理員說明論壇發文。
最後最重要的是,我們在此由衷感謝所有信任的測試人員和網站管理員論壇的傑出貢獻者,他們花了相當多的時間測試「搜尋分析」Alpha 版本,協助我們製作出如此優質的報表系統:如果沒有各位持續提供意見和建議,我們也無法達到這樣的成果,感謝各位的卓越表現!

Posted:
原文:Rolling out the mobile-friendly update
作者:Takaki Makino 和 Doantam Phan

我們已於今年稍早宣佈,即將在全世界發佈行動裝置相容性更新。今天起,我們將針對適合行動裝置瀏覽的網頁,提升這些網頁在行動裝置搜尋結果中的排名。現在,搜尋者能夠更容易選取優質的相關結果,比如使用者不必點按或縮放畫面就可看到的清晰易讀內容點按目標的大小和距離間隔適當,未提供無法播放的內容或無需橫向捲動即可查看的內容



4 月 21 日發佈行動裝置相容性更新後,只要網頁在透過行動裝置瀏覽時具有易讀性和可用性,行動搜尋結果排名就會獲得提升。
本次更新的重點如下:
  • *只有行動裝置上的搜尋排名受到影響
  • *對全世界所有語言的搜尋結果都有影響
  • *適用於個別網頁,而非整個網站

如要確認您的網站是否適合行動裝置瀏覽,您可以運用行動裝置相容性測試檢測個別網頁,也可以參考網站管理員工具中的行動裝置可用性報告,藉此掌握整個網站的狀態。如果您網站的網頁不適合透過行動裝置瀏覽,來自 Google 搜尋的「行動裝置」流量可能會出現明顯下滑。不過請不要擔心,只要您的網站在經過調整後適合透過行動裝置瀏覽,我們就會自動重新處理您的網頁(即檢索網頁及建立索引)。您也可以使用 Google 模擬器的提交給 Google 建立索引功能加速整個流程,隨後我們就會將您的網頁視為適合行動裝置瀏覽的網頁,並且反應在排名上。
如有任何疑問,請造訪網站管理員論壇的行動網站專區

Posted:
原文:FAQs about the April 21st mobile-friendly update
Maile Ohye, Developer Programs Tech Lead

行動裝置相容性更新即將在4月21日發佈,為此我們整理了一些常見問題與各位分享。我們已在 2 月時宣佈行動裝置相容性更新會使全世界適合透過行動裝置瀏覽的網頁 (透過行動裝置瀏覽時容易閱讀且方便使用) 在行動裝置搜尋結果中的排名提升;相對地,只針對大螢幕設計的網頁在行動裝置搜尋結果中的排名可能明顯下滑。為確保各位都能瞭解這項更新,我們整理出以下幾個常見問題:
一般常見問題
1. 一般電腦和/或平板電腦的搜尋排名也會受到這項更新影響嗎?
不會,這項更新對於透過平板電腦或一般電腦執行的搜尋沒有影響,只會影響透過行動裝置執行的搜尋,且適用於所有語言和地區。
2. 提升行動搜尋排名的對象是個別網頁,還是整個網站?
這是頁面層級的更新。舉例來說,如果網站上有 10 個適合透過行動裝置瀏覽的網頁,但是網站上的其他網頁並非如此,那麼只有這 10 個網頁的排名可能提升。
3. 我怎麼知道 Google 會判斷我的網站上有哪些網頁適合透過行動裝置瀏覽?
您可以透過行動裝置相容性測試來檢測個別網頁。

透過「行動裝置相容性測試」即時檢測個別網址。
如要查看「網站層級」的行動裝置相容性資訊,請參考網站管理員工具中的行動裝置可用性報告。這份報告中的資料是 Google 根據最新一次對您網站的網頁進行檢索及建立索引的結果所產生。

網站管理員工具中的行動裝置可用性報告可讓您一覽整個網站的行動裝置相容性。
4. 我針對行動裝置調整的網頁要等 4 月 21 日後才會上線,Google 何時會將這些網頁視為適合透過行動裝置瀏覽的網頁,並且反應在排名上?
每當我們檢索網頁並建立索引時,都會判斷該網頁是否適合透過行動裝置瀏覽,因此您不必等到下次更新。當網頁被判定為適合透過行動裝置瀏覽後,您可以等待智慧型手機適用的 Googlebot 正常 (重新) 檢索網頁並更新索引,也可以前往網站管理員工具,使用Google 模擬器的提交給 Google 建立索引功能加速整個流程。如果網址數量龐大,建議您考慮提交 Sitemap。如果您是在既有的網址上提供行動內容 (例如採用回應式網頁設計動態服務),請在 Sitemap 中加入 lastmod 標記。
5. 行動搜尋排名的變化是從 4 月 21 日開始生效,那麼如果 4 月 22 日時我的網站流量並未減少,是否就表示我的網站排名未受到影響?
您無法在 4 月 22 日就斷定網站排名是否受到行動裝置相容性更新的影響。行動裝置相容性更新在 4 月 21 日推出後,需要經過大約一週的時間,我們索引中的網頁才會全數更新。
6. 我有一個很棒的行動版網站,但是「行動裝置相容性測試」的結果卻顯示我的網頁不適合透過行動裝置瀏覽,為什麼呢?
如果專為行動裝置設計的網頁沒有通過「行動裝置相容性測試」,通常是因為含有禁止智慧型手機適用的 Googlebot 檢索的資源 (例如 CSS 和 JavaScript),而這些資源是 Google 判斷網頁在行動裝置上是否具有易讀性和可用性 (即「適合透過行動裝置瀏覽」) 的關鍵。解決方法如下:
  1. 查看行動裝置相容性測試是否顯示遭到封鎖的資源 (通常附有轉譯的局部圖片)。
  2. 允許 Googlebot 檢索需要的檔案。
  3. 再次確認您的網頁是否通過「行動裝置相容性測試」。
  4. 使用 Google 模擬器的提交給 Google 建立索引功能加速重新處理最新網頁的流程 (或等待 Google 正常重新檢索並更新索引)。

如果行動版網頁無法通過「行動裝置相容性測試」,通常是因為含有禁止智慧型手機適用的 Googlebot 檢索的資源 (例如 CSS 和 JavaScript),這些資源是 Google 判定網頁是否適合透過行動裝置瀏覽的關鍵。
再次重申,我們建議網站擁有者開放 Googlebot 檢索網頁的所有資源 (包括 CSS、JavaScript 和圖片),使 Google 能夠順利轉譯並建立索引,以便評估網頁是否適合透過行動裝置瀏覽。
7. 如果網頁可連結至不適合透過行動裝置瀏覽的網站,會怎麼樣?
將網頁連結至不適合透過行動裝置瀏覽的網頁 (例如專為電腦等大螢幕裝置設計的網頁),並不影響網頁本身的行動裝置相容性,依然可以符合「適合透過行動裝置瀏覽」的標準。雖然對於行動裝置使用者來說,從行動版網頁前往電腦版網頁並不是理想的使用體驗,但隨著適合透過行動裝置瀏覽的網站越來越多,也許未來這種情況能獲得改善。
8. Google 是否對於採用回應式網頁設計的網頁 (電腦版和行動版共用相同的網址和 HTML),會給予比獨立代管的行動版網站 (例如電腦版使用 www 網址,行動版使用 m.example.com 網址) 更高的行動搜尋排名?
不論是採用回應式網頁設計 (RWD)、以獨立行動版網址提供內容,還是採用動態服務做為服務架構,行動裝置相容性都是以相同的標準評估。如果您的網站是以個別行動版網址提供內容或採用動態服務,我們建議您參閱行動版網站搜尋引擎最佳化指南,確保 Google 順利檢索您的行動版網頁並建立索引。
專業常見問題
9. 如果我的目標對象只有一般電腦使用者,是不是就沒有必要建立行動版網站?
不見得。根據統計資料顯示,有越來越多人因為沒有電腦或不想換電腦的緣故而成了「行動裝置專用戶」。而且,正是因為只用行動裝置的使用者變多了,所以不適合透過行動裝置瀏覽的網站可能沒有多少行動裝置訪客。
行動裝置相容性更新適用於所有透過行動裝置搜尋到的網站,無論網站的目標對象使用何種語言、位於什麼地區,以及行動裝置流量相對於電腦流量的比例是多少,都會受到影響。
10. 嵌入 YouTube 影片的網頁顯示行動裝置可用性錯誤訊息,該怎麼辦?
建議您仔細檢查 YouTube 影片的嵌入方式,如果您在行動版網頁使用「舊式」的 <object> 嵌入標記,請改成相容性更廣泛的 <iframe> 嵌入標記。YouTube 現在預設使用 HTML5 網路播放器,因此無論運用觀看網頁的「分享」功能還是 YouTube iFrame API,都能藉由支援行動裝置瀏覽的 <iframe> 標記嵌入影片。即使進行更為複雜的整合作業,行動裝置相容性也依然有保障,因為系統會指示裝置使用內建的支援功能。
如果您要嵌入來自 YouTube 以外網站的 Flash 內容,請確認這些內容是不是以同等作用的 HTML5 嵌入標記或程式碼片段嵌入,避免使用專屬的外掛程式。
11. 點按目標大小有明確的標準嗎?
有,我們建議主要點按目標的長度/寬度至少 7 公釐,次要點按目標之間至少保留 5 公釐的空間。由於成年人的指腹平均 10 公釐寬,這樣的規格一方面可確保網頁介面的可用性,一方面也能充分利用頁面空間
12. 為了儘早讓行動裝置使用者能輕鬆瀏覽網站,在新推出的回應式網站上線前,我們打算先架設一個精簡版網站 (位於獨立的行動版網址上)。這麼做會有任何問題嗎?
首先提醒您一件事,就是我們支援三種行動服務架構,所以網站不一定要採用回應式設計才適合透過行動裝置瀏覽。就這個問題來說,您在架設精簡版網站時必須謹慎以對。即使將網頁設定為行動裝置專用格式,如果您的訪客不能輕鬆完成常見工作,或者整體使用的流暢性不佳,那麼訪客仍有可能感覺不良,到頭來只是白忙一場。如果您已將暫代的行動版網站架設完畢,當 RWD 版本的網站上線時,請務必妥善遷移網站。舉例來說,請將所有連結更新為不再參照獨立的行動版網址,並且使用 301 重新導向,將造訪行動版網址的訪客重新導向至對應的 RWD 版網頁。
建議
如果您對於架設適合透過行動裝置瀏覽的網站完全不熟悉,現在開始學習還不晚!請參閱適合透過行動裝置瀏覽的網站說明文件當中的踏出第一步

造訪 https://developers.google.com/webmasters/mobile-sites/,瞭解如何著手打造行動網站。
如果您已經擁有行動網站,請參考網站管理員工具中的行動裝置可用性報告,確認 Google 的偵測結果是否證明您的網頁適合透過行動裝置瀏覽。

還有其他問題嗎?歡迎於下方提問,或是查看網站管理員論壇的行動網站專區

Posted:
作者:Mathieu Perreault, Chrome Software Engineer, and Zineb Ait Bahajji, Webmaster Trends Analyst

許多網站都會運用表單來完成重要步驟,比如說,使用者在購物網站上交易或是在新網站上註冊時,都可能需要填寫表單。對於很多使用者來說,在不同網站填寫線上表單的過程,就是一次又一次地輸入自己的姓名、電子郵件地址、電話號碼或地址等常用資訊。不僅枯燥乏味,還很容易出錯,導致許多人往往半途而廢。隨著人們越來越常使用行動裝置上網,使用筆電和桌機上網的頻率變少,設計表單時,更要特別注意如何能讓使用者輕鬆快速地填完表單內容!三年前,我們宣佈在 Chrome 中支援最新的「autocomplete」屬性,讓使用者能夠更迅速、更簡單、更能運用智慧功能填完表單。現在,Chrome 已全面支援「autocomplete」屬性,凡是符合現行 WHATWG HTML 標準的表單欄位一律適用。因此,網站管理員和網站開發人員只要為輸入元素欄位加上常見資料類型的標籤 (例如「name」或「street-address」) 即可,不必再變更使用者介面或後端設定。為表單加上自動完成標記後,許多網站管理員在網站上建立表單的效率都更加提升

以下示範如何為表單中的電子郵件地址欄位加上標記,以便支援自動完成功能 (另附完整表單範例):
 <input type=”email” name=”customerEmail” autocomplete=”email”/>



讓行動裝置使用者能夠更輕鬆自如地瀏覽網站是一項非常重要的課題。我們希望越來越多表單設計者能在表單中善用「autocomplete」屬性標記。如需更多資訊,請前往我們的「Web 基礎知識」網站參閱標籤與名稱輸入規格。如果您有任何問題,歡迎到我們的網站管理員說明論壇中發文。