2016 年 11 月 9 日，星期三
漸進式網頁應用程式 (PWA) 可利用新技術為使用者提供結合行動版網站與原生應用程式精華的體驗，也是網路世界中最引人注目的新概念之一。不過，若要真正發揮影響力，這類應用程式就必須開放外界連結及建立索引。無論是要建構漸進式網頁應用程式還是簡易靜態網站，本文中提出的各項建議都是目前提升可索引性的最佳做法。儘管如此，我們統整了這些最佳做法，為您提供檢查清單方便您：
讓內容可供檢索
為什麼？以往，網站一律是在伺服器上產生或轉譯 HTML，這是最簡單讓人直接連結內容的做法。網頁應用程式的發展則讓用戶端轉譯的概念蔚為風行，強調使用者瀏覽網頁時不必重新載入，網頁就會動態更新內容。
目前主流的做法是兼容以上兩者的混合式轉譯，也就是在使用者直接前往某個網址時，使用伺服器端轉譯模式；等到一開始的網頁載入作業完成後，則透過用戶端轉譯的做法來處理後續的瀏覽和非同步要求。
我們以伺服器端 PWA 示例說明純伺服器端轉譯的做法，以混合式 PWA 示例說明兩者並用的做法。
如果您不熟悉伺服器端和用戶端轉譯這兩個術語，可參考用戶端和伺服器端轉譯以及 react 和 Node.js 的伺服器端轉譯。
最佳做法：
使用伺服器端轉譯或混合式轉譯做法，這樣使用者就能在系統初步承載他們的網路要求時收到內容。
確保您的網址可供個別存取：
https://www.example.com/product/25/
上述網址應以深層連結形式連往特定資源。
如果您的漸進式網頁應用程式不支援伺服器端或混合型轉譯功能，而且您決定使用用戶端轉譯功能，建議您使用 Google Search Console 的「Google 模擬器」工具來驗證我們的搜尋檢索器是否成功轉譯您的內容。
請勿將存取深層連結的使用者重新導向你的網頁應用程式首頁。
此外，也請避免對使用者顯示錯誤頁面來取代深層連結。
提供簡潔網址
為什麼？片段 ID ( #user/24601/ 或 #!user/24601/) 對於利用 AJAX 處理來自伺服器的新內容而不重新載入網頁的瀏覽器而言，是相當有效的解決方案。這種設計又稱為用戶端轉譯。
然而，片段 ID 語法和一些網路工具、架構和通訊協定並不相容 (例如 Facebook 的 Open Graph 通訊協定)。
如今，只要使用 History API 就可以在沒有片段識別碼的情況下更新網址，並且依然以非同步的方式擷取資源，避免重新載入網頁，達成兩全其美的效果。雖然 AJAX 檢索配置 (搭配其 #! / 逸出片段網址) 曾經是合理的做法，但目前我們已不建議使用。
我們以混合式 PWA 和用戶端 PWA 示例說明 History API。
最佳做法：
提供不含片段 ID (# 或 #!)的簡潔網址，例如：
https://www.example.com/product/25/
如果使用用戶端轉譯或混合式轉譯，請務必使用 History API 來支援瀏覽器的運作，讓使用者能正常瀏覽網頁內容。
請避免：
使用 #! 網址結構來導引非重複網址：
https://www.example.com/#!product/25/
在 History API 推出之前，這曾是開發人員採行的權宜做法，現在則被視為 # 網址結構的一種獨立模式。
系統不支援在未附帶 ! 符號的情況下使用 # 網址結構：
https://www.example.com/#product/25/
這個網址結構已經是一種網頁概念，與特定網頁上內容的深層連結相關。
指定標準網址
為什麼？當有多個網址 (無論是否來自相同網域) 提供一樣的內容時，如要避免在建立索引時造成混淆，最妥善的方法就是將其中一個網頁標記為標準網頁，讓其他內容重複的網頁全部參照該網頁。
最佳做法：
在所有鏡射特定內容段落的網頁中加入下列標記：
<link rel="canonical" href="https://www.example.com/your-url/" />
如果您支援 Accelerated Mobile Pages，請務必正確使用其對應的 rel="amphtml" 指示。
請避免：
避免刻意在多個網址提供重複內容，且未使用 rel="canonical" link 元素。
具體來說，使用 rel="canonical" link 元素可減少由於附有追蹤參數的網址而產生的混淆。
避免建立會在網頁間產生衝突的標準參照。
可配合多種裝置的設計
為什麼？這是為了確保所有使用者無論使用何種裝置，都能在瀏覽您的網站時獲得最佳體驗。
請採用回應式的網站設計模式：網站的字型、邊界、間距、按鈕以及基本設計應配合螢幕解析度和裝置檢視點進行動態縮放。
對於桌上型電腦或平板電腦提供放大的小型圖片，並不能取得良好效果。另一方面，超高解析度的圖片不僅在行動裝置上需要較長的下載時間，還可能影響捲動操作的效能。
進一步瞭解 PWA 的使用者體驗。
最佳做法：
使用 srcset 屬性為不同的密度螢幕擷取不同的解析度圖片，以免下載的圖片大於裝置螢幕畫面能顯示的尺寸。
無論裝置大小為何，都須將字型調整為易讀的大小與行高。同樣地，也請確認元素的邊框間距和邊界都能正常縮放。
使用 Chrome 開發人員工具的裝置模式功能和行動裝置相容性測試工具，針對各種螢幕解析度進行測試。
向使用者顯示的內容須與向 Google 顯示的內容相同。如果您使用重新導向或偵測使用者代理程式 (又稱「探查瀏覽器」或動態放送) 針對不同裝置變更提供不同網站設計，請務必確保網站內容相同。
使用 Search Console 的「Google 模擬器」工具，確認 Google 擷取的內容是否與使用者看到的內容相符。
考量到可用性，請避免使用固定大小的字型。
迭代開發
為什麼？迭代變更是為網頁應用程式新增功能最安全的其中一種做法。在逐一新增功能的過程中，您可以觀察每次變更帶來的影響。
此外，許多開發人員傾向於將漸進式網頁應用程式視為一舉全面革新行動版網站的大好機會：他們在隔離環境中開發新的網頁應用程式，準備就緒後就直接以之替換現有的行動版網站。
迭代開發功能時，必須試著將各項變更劃分為獨立的項目。舉例來說，假設您計劃將伺服器端轉譯改成混合式轉譯，則可針對這項作業進行單一改版，不包括其他功能。
兩種做法各有利弊。迭代轉換的過程是持續而連貫的，所以可以降低搜尋引擎建立索引的複雜度。不過，迭代可能會減緩開發流程；而且如果開發作業本身並非從零開始，以全面革新的角度來看，也有可能產生創新不足的盲點。
無論選擇何種方式，標準網址和網站的 robots.txt 設定都是最容易受到影響的部分，請特別留意。
最佳做法：
逐步加入新功能，循序漸進地迭代網站。
舉例來說，如果尚未支援 HTTPS，就從遷移到安全的網站開始著手。
請避免：
如果您是在隔離環境中開發漸進式網頁應用程式，請不要在未確認 rel-canonical 連結和 robots.txt 是否正確設定的情況下，啟動應用程式。
務必確認您的 rel-canonical 連結指向了實際網站，而且 robots.txt 設定允許檢索器檢索您的新網站。
在網站正式上線前，禁止檢索器為開發中的網站建立索引是合理的做法，但在網站發布後請別忘了解除封鎖檢索器，讓檢索器可以存取您的新網站。
採用漸進增強原則
為什麼？在使用瀏覽器功能前，盡可能進行相關的偵測作業是相當重要的。功能偵測也比針對您認為可支援特定功能的瀏覽器進行測試來得更妥當。
過去常見的不當做法是針對使用者使用的瀏覽器進行測試，藉此決定要啟用或停用的功能。不過，由於瀏覽器會隨著各項功能持續進化，所以我們強烈反對這種做法。
Service Worker 是一項相對新穎的技術，而在追求進步的過程中，維持相容性也是很重要的環節，這是使用漸進增強技術的最佳範例。
最佳做法：
註冊 Service Worker 前，請檢查 API 是否可用：
if ('serviceWorker' in navigator) {
...
依照 API 偵測方法來使用所有網站功能。
切勿使用瀏覽器的使用者代理程式來啟用或停用網頁應用程式的某些功能。也請確認各功能的 API 是否可用，且不適用時可優雅降級。
先使用各家瀏覽器進行測試，再更新或發布網站！查看網站分析資料，瞭解您的使用者族群最常用的是哪一種瀏覽器。
使用 Search Console 進行測試
為什麼？瞭解 Google 搜尋如何查看您網站上的內容是相當重要的。您可以透過 Search Console 擷取網站上的個別網址，然後依序前往「檢索」>「Google 模擬器」，就能以 Google 搜尋的角度查看這些內容。如果您選取了相關選項，Search Console 也會處理您的 JavaScript 並轉譯網頁內容，否則只會顯示原始的 HTML 回應。
Google Search Console 也會透過各種方式來分析網頁中的內容，包括偵測結構化資料、複合式資訊卡、網站連結和 Accelerated Mobile Pages 的呈現方式。
最佳做法：
使用 Search Console 監控網站，並探索相關功能 (包括「Google 模擬器」)。
在 Search Console 中依序前往「檢索」>「Sitemap」提供 Sitemap，即可有效確保 Google 搜尋會檢索您網站中的所有網頁。
使用 Schema.org 結構化資料來加上註解
為什麼？Schema.org 結構化資料是相當靈活的詞彙，能夠將網頁中最重要的部分摘述為可供機器處理的資料。無論是單純指出網頁是 NewsArticle，還是詳細說明樂團巡迴的所在地點、樂團名稱、場地和自動售票機資訊，或摘述食譜中提及的食材和步驟等等，都是這類資料可涵蓋的範圍。
在網頁應用程式的每個頁面上使用這類中繼資料可能並不合宜，建議您視情況使用。Google 會在網頁轉譯後擷取網頁內容。
有多種資料類型，包括 NewsArticle、Recipe 和 Product 等。您也可以在這裡探索所有支援的資料類型。
避免使用與網頁實際內容不符的資料類型。舉例來說，請勿為您要販售的 T 恤使用「Recipe」，而是改用「Product」。
使用 Open Graph 與 Twitter Card 來加上註解
為什麼？除了 Schema.org 中繼資料外，建議您額外支援 Facebook 的 Open Graph 通訊協定和 Twitter 複合式資訊卡。
當您將內容分享到對應的社交網路時，這些中繼資料格式可進一步改善使用者體驗。
如果您現有的網站或網頁應用程式使用了這些格式，請務必確保您的漸進式網頁應用程式也包含這些格式，才能達到最佳觸及結果。
如果您現有的網站支援這些格式，請別忘了將這些格式包含在內。
使用多種瀏覽器進行測試
為什麼？從使用者的角度來看，網站行為不因瀏覽器不同而有所差異顯然相當重要。雖然使用經驗可能會因為螢幕大小的差異而有所改變，但我們希望無論是使用 iPhone 還是 Android 手機，行動網站在大小相近的裝置上都能具備同樣的運作方式。
由於全球各地使用中的瀏覽器數量繁多，網路出現了分隔化的情形，而這種多樣性和競爭，也是讓網路成為創新平台的原因之一。值得慶幸的是，網路標準發展至今已趨於完善，而各種新世代的工具也讓開發人員得以信心十足地打造出內容豐富、可搭配各家瀏覽器使用的網站。
最佳做法：
使用 BrowserStack.com、Browserling.com 或 BrowserShots.org 等跨瀏覽器測試工具，確保您的 PWA 適用於各種瀏覽器。
評估網頁載入效能
為什麼？因為使用者載入網站的速度越快，對網站的滿意度就越高。 在網站開發作業中，達到最佳網頁速度是眾所周知的重心所在，不過有時在開發新版網站時，這些必要的最佳化作業並不是我們優先考量的事務。
開發漸進式網頁應用程式時，建議您先評估網頁載入速度效能，進行最佳化處理後再發布網站，才能達到最好的效果。
最佳做法：
使用 Page Speed Insights 和網頁測試等工具評估網站的網頁載入效能。雖然 Googlebot 允許較長的轉譯時間，不過研究顯示，有 40% 的消費者會在網頁載入時間超過 3 秒時放棄瀏覽網頁。
請詳閱我們的網頁效能建議和這裡的關鍵轉譯路徑。
避免將最佳化作業留待網站發布後才進行。如果網站內容的載入速度在遷移至新的漸進式網頁應用程式前就相當快的話，在最佳化過程中就要注意不要影響到原有的載入速度。
希望上述的檢查清單能對您有幫助並提供適當的指引，讓您在開發漸進式網頁應用程式的同時，也能顧及可索引性。
著手進行時，請務必參考我們提供的漸進式網頁應用程式可索引性示例，其中具體示範了伺服器端、用戶端和混合式轉譯。如果您有任何問題，歡迎前往我們的網站管理員論壇尋求協助。