SEO 完整攻略

探索 SEO 的最佳實踐，提升網站能見度與流量。

技術審核清單

涵蓋網站速度、結構化資料、HTTPS 等項目。

作者：哇哇工作站更新於：2025年8月18日
技術審核清單

網站結構檢查：確保每個角落都能被搜尋引擎抓到

抓取可行性分析：確保搜尋引擎能順利進入網站

抓取可行性分析：確保搜尋引擎能順利進入網站

抓取是 SEO 的基礎，若搜尋機器人無法輕易訪問你的網頁，就算內容再好也難以被收錄。以下幾個步驟能協助你確認網站的抓取可行性：

  • robots.txt：檢查是否誤阻擋重要目錄或檔案。舉例來說，若 User-agent: * Disallow: /admin/ 這樣設定，搜尋機器人就無法抓取 /admin/ 下的任何頁面，即使該區塊有公開資訊也會被忽略。
  • 網站地圖（sitemap.xml）：確保所有重要頁面的 URL 都列在 sitemap 中，並且 sitemap 本身沒有錯誤。你可以使用瀏覽器直接開啟 https://example.com/sitemap.xml 看是否能正確顯示。
  • HTTP 狀態碼：確認首頁及主要子頁面回傳 200 OK；若有 301 或 302 的永久或臨時重定向，需確保目標 URL 正常且可被抓取。
  • 檢查 robots meta 標籤：在個別頁面上使用 <meta name="robots" content="noindex, nofollow"> 會阻止該頁面被索引，請確保只用於不需要曝光的內容，例如登入後的內部頁面。
  • 語言與區域設定：若網站同時支援多國語系，請使用 hreflang 標籤告訴搜尋機器人不同語言版本的對應關係；否則可能只抓取其中一個版本。
具體操作範例
  1. 檢查 robots.txt
  • 開啟 https://yourdomain.com/robots.txt，若看到類似以下內容：
  • User-agent: *
  • Disallow: /cgi-bin/
  • Allow: /
  • 這表示搜尋機器人只能抓取根目錄及子目錄，但排除了 /cgi-bin/。確認你沒有意外阻擋重要資料夾。
  1. 提交 sitemap
  • 在 Google Search Console 或 Bing Webmaster Tools 裡新增 https://yourdomain.com/sitemap.xml，並確認回傳 200 OK。
常見錯誤與解決方法
  • robots.txt 錯誤排版：若使用空白行或不正確的指令，搜尋機器人可能會忽略整個檔案。建議以純文字編輯器確認格式無誤。
  • 重定向太多層級：如果首頁被 301 重定向到另一域名，再由那個域名重定向回來，搜尋機器人可能會因循環而停止抓取。建議只保留一次重定向。
工具小技巧
  • robots.txt 測試工具：使用 Google Search Console 的 robots.txt 測試工具確認特定 URL 是否被允許。
  • 抓取日誌分析：伺服器的 access.log 可以顯示搜尋機器人實際訪問情況，透過查找 Googlebot、Bingbot 等 User‑Agent 了解抓取頻率。

透過上述檢核與修正，你就能確保網站的每一個角落都被搜尋引擎順利發現，為後續內容最佳化打下堅實基礎。

站點地圖驗證：XML 與 HTML 地圖都要檢查

站點地圖驗證：XML 與 HTML 地圖都要檢查

一個完整的網站結構應該同時擁有 XML 與 HTML 兩種地圖。XML 主要供搜尋引擎抓取，HTML 則方便使用者快速瀏覽。

XML 站點地圖驗證步驟

  • 確認檔案存在：在瀏覽器輸入 https://example.com/sitemap.xml，應該能看到清單。
  • 檢查 MIME 類型：伺服器回傳 application/xml 或 text/xml。
  • 解析錯誤排除：使用 XML 解析工具（例如 XML Validation）確認沒有語法問題。
  • 內容完整度：確保所有重要頁面都有條目，且 URL 為絕對路徑。
  • 更新頻率：若網站更新頻繁，請在 <lastmod> 標籤中使用最新日期，並設定合理的 priority 與 changefreq。

常見 XML 站點地圖錯誤

  • URL 使用相對路徑：搜尋引擎可能無法正確定位。
  • 缺少 <urlset> 根元素，或使用了錯誤的命名空間。
  • 多個 <sitemapindex> 與 <urlset> 混用導致解析失敗。
  • 內容過長：單一檔案超過 50,000 個 URL 或 10MB 尺寸時，需要拆分為多個子站點地圖。

HTML 站點地圖驗證步驟

  • 確認頁面可見：在瀏覽器直接開啟 https://example.com/sitemap.html，確保不會被 robots.txt 阻擋。
  • 連結正確性：所有內部連結都應使用絕對 URL 或相對於根目錄的路徑，並且不含錯別字。
  • 標題與分類清晰：使用 <h2>、<ul>、<li> 等語意化標籤，方便使用者快速定位。
  • 互動性測試：點擊各個連結確認能正常載入目標頁面，並且在瀏覽器的「查看原始碼」中可以看到 <a> 標籤。

工具與資源

  • XML Sitemap Checker：https://www.xml-sitemaps.com/checksitemap.html，可快速驗證 XML 檔案的結構。
  • Google Search Console：上傳並監控站點地圖，能即時收到錯誤通知。
  • Bing Webmaster Tools：同樣支援站點地圖提交與問題回報。
  • HTML Sitemap Validator：自行使用瀏覽器的開發者工具檢查連結是否 404 或重定向。

robots.txt 審核：避免誤封鎖重要頁面

robots.txt 審核：避免誤封鎖重要頁面

1️⃣ 首先，開啟你網站根目錄的 robots.txt 檔案。若檔案不存在，可自行建立。

  • 常見錯誤一：將整個網站設定為 Disallow: /，這會阻擋所有搜尋引擎抓取任何頁面。
    範例：
    User-agent: * Disallow: /

  • 常見錯誤二：在特定目錄下使用 Disallow: /blog/，但實際上重要的文章也存於此目錄。
    建議：只封鎖不需要被索引的子目錄，例如 /admin/ 或 /tmp/。

2️⃣ 檢查是否有誤將 Disallow: /page 與 Allow: /page/index.html 混用，導致搜尋引擎仍無法抓取該頁面。

3️⃣ 確認沒有設定過於寬鬆的 Disallow: /*.php?* 或類似通配符，會把動態參數頁面全部封鎖。可改為只封鎖真正需要保護的連結，例如：
Disallow: /private/

4️⃣ 使用 Crawl-delay: 10 時，請先確認搜尋引擎是否支援此指令，否則可能被忽略或造成抓取延遲。

5️⃣ 建議將重要頁面的路徑加上 Allow: 指令，以確保即使父目錄被封鎖，子頁面仍能被抓取：
User-agent: * Disallow: /blog/ Allow: /blog/about.html

實務檢查清單

  • [ ] 確認首頁、產品頁、服務頁未被 Disallow。
  • [ ] 重要子目錄（如 /shop/）已加上 Allow: 或移除不必要封鎖。
  • [ ] 沒有使用通配符導致關鍵頁面被誤封。
  • [ ] 檢查是否有重複或衝突的規則，例如同一目錄同時出現多個 Disallow 與 Allow。

小結

robots.txt 是搜尋引擎抓取路線圖，若設定不當，會讓重要頁面無法被索引。透過上述步驟與檢查清單，可以快速發現並修正錯誤，確保網站每個角落都能被搜尋引擎抓到。

Canonical 標籤實作：防止重複內容問題

Canonical 標籤實作：防止重複內容問題

在網站中，重複內容會讓搜尋引擎分散權重，甚至把你頁面列為垃圾訊息。使用 canonical 標籤可以告訴搜尋引擎哪一個版本是「正統」的來源。

在 HTML 頁面中插入 canonical 標籤
  1. 找到 <head> 區塊，最靠近 </head> 的位置。
  2. 加上以下語法：
    <link rel="canonical" href="https://example.com/正確的URL">
  • href 必須是 絕對路徑（包含協定）。
  • 若有多個版本，所有版本都要指向同一個 canonical。
  • 例子：若你網站可用 http://example.com/page?ref=abc 與 https://example.com/page 同時存取，兩者都應該加上相同的 <link rel="canonical">。
處理動態參數與多語系版本

  • 清除不必要參數：在 URL 中只保留對內容定位真正有幫助的參數；其餘使用 canonical 指向主頁面。

  • 多語系：若同一篇文章有多種語言，請在每個版本中加上指向自己該語言版本的 canonical。若要將所有語言合併權重，可選擇一個「主」語言並使用 hreflang + canonical。

  • 範例：
    <link rel="canonical" href="https://example.com/zh-tw/article-1">

這表示所有其他參數化 URL（如 ?utm_source=...）都視為同一篇文章。

驗證 canonical 實作是否正確
  • Google Search Console：使用「URL 檢測工具」輸入網址，查看搜尋結果中顯示的 canonical。
  • Chrome 開發者工具：打開元素面板，確認 <head> 中存在且 href 正確。
  • Bing Webmaster Tools：同樣提供標籤檢查功能。

若搜尋引擎未顯示正確的 canonical，可能是因為:

  1. 標籤被其他腳本動態覆寫；
  2. 伺服器回傳了錯誤碼（404、500）導致無法抓取；
  3. 使用相對路徑或缺少協定。
常見陷阱與最佳實踐
  • 不要在同一頁面放多個 <link rel="canonical">；搜尋引擎會混淆。
  • 避免重複使用 noindex 與 canonical：若你想讓頁面不被索引，直接用 noindex 即可，不需要再設置 canonical。
  • 確保所有子域或子目錄都有正確的 canonical；例如 shop.example.com/product/123 與主站 example.com/product/123 皆需指向同一個 URL。
  • 動態產生標籤時，使用伺服器端渲染（SSR）或靜態預先生成，避免客戶端 JavaScript 延遲載入導致爬蟲抓不到。

總結：正確實作 canonical 標籤能大幅減少重複內容的風險，讓搜尋引擎更清楚你網站的結構，從而提升整體 SEO 表現。

頁面速度評估：讓網頁跑得快，訪客也更滿意

載入時間指標：測量首屏與完整頁面速度

載入時間指標：測量首屏與完整頁面速度

在 SEO 的技術審核清單裡，頁面速度是最關鍵的項目之一。這裡我們聚焦於兩大核心指標：首屏載入時間（First Contentful Paint, FCP） 與 完整頁面載入時間（Time to Interactive, TTI）。

1. 首屏載入時間 (FCP)

  • 定義：從使用者點擊連結到瀏覽器開始渲染第一個可見內容的時刻。
  • 為什麼重要？ 用戶感受最先看到的是圖片、文字還是佈局，這直接影響留存率。
例子：
  • 手機網頁：如果 FCP 超過 3 秒，用戶可能已經滑到下方而不再回來。
  • 桌面網站：FCP 達到 1 秒以下，通常會看到更高的點擊率。

2. 完整頁面載入時間 (TTI)

  • 定義：網頁互動可用時刻，即使用者可以完全操作頁面（如按鈕、表單）而不被阻塞。
  • 為什麼重要？ 若 TTI 太長，雖然畫面已呈現，但功能尚未啟用，會造成挫敗感。
例子：
  • 單頁應用（SPA）：若 JavaScript 大量阻塞主執行緒，TTI 可能延遲到 10 秒以上。
  • 靜態頁面：通常 TTI 與 FCP 差距不大，但仍要避免大量外部腳本導致延遲。

如何測量這兩項指標

  1. Chrome DevTools：打開 Performance 面板，錄製後查看 FCP 與 TTI 位置。<br>2. Lighthouse：執行測試並在報告中找到 FCP、TTI。<br>3. Web Vitals API（JavaScript）：可實時收集指標並發送至分析後台。

優化技巧

  • 延遲載入圖片：使用 loading="lazy" 或 IntersectionObserver。<br>- 壓縮圖檔：選擇 WebP、AVIF，減少 50%+ 大小。<br>- 移除不必要的 JavaScript：將非首屏功能拆分到後續載入。<br>- 使用瀏覽器快取與 CDN：確保靜態資源快速回應。

小結

FCP 與 TTI 是評估網頁速度的兩大指標，透過工具測量並針對性優化，可直接提升使用者體驗與 SEO 表現。

常見問題 (FAQ)

  • Q：FCP 與 LCP 有什麼差別？<br> A：LCP（Largest Contentful Paint）是指最大可視內容載入時間，通常比 FCP 晚一些。
  • Q：TTI 能否用瀏覽器自動計算？<br> A：Chrome 已在 DevTools 與 Lighthouse 自動呈現，但若自行實作，可參考 Web Vitals API 的 ttfb、fid 等指標。

進一步閱讀

資源優化：圖片、腳本及樣式表的最佳做法

在網頁速度評估中，資源優化是提升載入效能的關鍵環節。本文將針對圖片、腳本及樣式表提出實用且符合 SEO 的最佳做法，幫助你打造更快速、更順暢的使用者體驗。
這些技巧不僅能夠降低頁面加載時間，也會讓搜尋引擎更容易抓取與評估你的內容，進而提升整體可見度。

資源優化：圖片、腳本及樣式表的最佳做法

1️⃣ 圖片處理技巧
  • 選擇合適格式：若圖像多為照片，建議使用 WebP 或 AVIF；若是簡易插畫或透明背景，則 PNG 或 SVG。
  • 壓縮工具：可用 TinyPNG、Squoosh 進行無損或有損壓縮。設定「品質」在 80‑90% 時往往能保持清晰且減少 30–50% 檔案大小。
  • 延遲載入（lazy loading）：在 <img> 加上 loading="lazy"，或使用 IntersectionObserver 於 JavaScript 中自行控制。這樣瀏覽器只會先抓取畫面內的圖片，提升首屏速度。
  • 尺寸預留：給每張圖設定明確的寬高屬性，避免載入後頁面跳動。
  • 使用 CDN：將靜態資源放於全球節點，縮短距離與減少延遲。
2️⃣ 腳本效能提升法
  • 非同步加載（async）或延遲執行（defer）：在 <script> 標籤加入 async 或 defer，讓 HTML 解析不會因腳本阻塞而被卡住。
  • 拆分檔案：將大型腳本拆成功能模組，只於需要時載入。可利用現代瀏覽器的 ES6 模組支援（type="module"）。
  • 最小化與合併：使用 Terser、UglifyJS 進行語法縮減，並將多個檔案合併成一個，以降低 HTTP 請求數。
  • 利用瀏覽器快取：設定適當的 Cache‑Control 標頭（例如 max-age=31536000），讓同一腳本不必重複下載。
  • 避免全域變數與命名衝突：使用立即執行函式 (IIFE) 或模組化，減少潛在錯誤與記憶體佔用。
3️⃣ 樣式表最佳實務
  • 將關鍵 CSS 放於頁面頂端：把影響首屏渲染的樣式寫入 <style> 或單獨檔案，並置於 <head> 最前方。其餘非必要樣式可延後載入。
  • 使用 preload 先行下載：對於需要立即執行的大型 CSS，可在 <link rel="preload" as="style"> 標籤中加入 onload="this.rel='stylesheet'"，確保不阻塞渲染。
  • 合併與壓縮：CSS 也同樣可用 cssnano 或 CleanCSS 進行最小化，並合併多個檔案以減少請求數。
  • 避免重複選擇器：每一次 querySelector 都會觸發重排（reflow），盡量將選取器存於變數或使用事件代理（event delegation）。
  • 利用 CSS 變數與預處理器：SCSS、Less 或 PostCSS 能幫你集中管理主題色彩與尺寸，減少手動重複。
📊 資源優化對頁面速度的實際影響
優化項目 預估縮短載入時間（秒） SEO 受益
圖片壓縮與延遲載入 0.5–1.2 更快首屏，降低跳出率
腳本非同步 + 合併 0.3–0.8 減少渲染阻塞，提高 Core Web Vitals
CSS 延後加載 0.2–0.6 提升 CLS（視覺穩定性）
🔗 附加資源

小結：把圖片、腳本和樣式表拆分、壓縮、延遲載入，再加上一點 CDN 與快取策略，就能大幅提升頁面速度。這不僅讓使用者更順暢，也符合搜尋引擎對「用戶體驗」的重視，進而帶來更好的排名與曝光。

伺服器回應調校：減少延遲與提升效能

本篇文章將帶您了解如何調整伺服器回應時間，減少延遲並提升效能。從硬體升級到軟體設定，我們會一步步說明實際可行的技巧，讓網站在搜尋引擎與使用者眼中都更快、更順暢。
接下來您將看到具體的操作流程、範例以及常見陷阱，別忘了實作前先備份資料喔！

調整伺服器回應時間概念

網站載入速度不僅取決於前端渲染，還受伺服器回應時間（TTFB）影響。若伺服器回應慢，即使網頁本身優化再好，也會讓訪客感到卡頓。

1️⃣ 常見造成延遲的原因

  • 硬體資源不足：CPU、記憶體或磁碟 I/O 不足。
  • 資料庫查詢效率低：未加索引或複雜 JOIN。
  • 應用程式啟動時間長：例如 PHP 的 FPM 初始化太慢。
  • 網路傳輸瓶頸：DNS 解析、TCP 三次握手延遲。

2️⃣ 測試工具與指標

  • curl -w "@latency.txt" -o /dev/null https://example.com，查看 TTFB。
  • Google PageSpeed Insights 或 Lighthouse 會顯示「伺服器回應時間」項目。
  • Nginx / Apache 的 access.log 可追蹤每個請求耗時。

3️⃣ 具體調校步驟

a) 選擇合適的主機方案
  • 若流量高，考慮 VPS 或雲主機（AWS、Azure、GCP）並設定自動擴充。
  • 使用 SSD 而非傳統硬碟，可提升磁碟 I/O。
b) 優化資料庫
操作 說明
建立索引 為常查詢欄位加索引，避免全表掃描。
使用快取 Redis 或 Memcached 將熱點資料存入記憶體。
限制 JOIN 數量 避免一次拉取過多資料，分頁處理。
c) 應用程式啟動優化
  • PHP：使用 PHP-FPM 的 pm.max_children 調整同時執行數；開啟 opcache。
  • Node.js：將主程式拆成多個 worker，利用 cluster 模組。
  • Python：採用 uWSGI 的 pre-fork 方式，或使用 Gunicorn。
d) 網路優化
  • 設定 HTTP/2 或 QUIC，可同時發送多筆請求。
  • 使用 CDN 把靜態資源緩存到離訪客最近的邊緣節點；這樣可以把原始伺服器回應時間從 200ms 降到 30~50ms。
e) 監控與自動化
  • 建立 Grafana + Prometheus 報表，實時觀察 TTFB。
  • 用 CI/CD 自動部署後即執行 curl 測試；若超過閾值（例如 400ms），就觸發警報。

4️⃣ 常見陷阱與錯誤

錯誤 影響 解決方案
過度使用 CDN 但忽略原始伺服器回應 CDN 仍需請求來源伺服器，造成延遲累積 確保所有 API 回傳都快於 200ms
資料庫只在開發環境做優化 生產環境資料量大時效能不佳 在生產環境先測試索引、查詢計畫
監控忽略長連線 長連線占用資源，導致短請求延遲 設定 HTTP keep-alive 時間、限制最大並發數

5️⃣ 小結

透過硬體升級、資料庫優化、程式碼執行速度、網路協議與 CDN 配合，以及持續監控，您可以將伺服器回應時間大幅縮短。記得定期檢查 TTFB，並把它當作 SEO 重要指標之一，讓搜尋引擎與使用者都能感受到更快的網頁。

6️⃣ 進一步閱讀

  • Google 官方「最佳化伺服器回應」文章
  • Nginx 官方文件：ngx_http_stub_status_module 用於監控
  • Redis 官方指南：如何設定慢查詢日誌

祝您順利提升網站效能，讓每位訪客都快速到達想看的內容！

行動裝置友善度審核：手機版也要給力

Viewport 設定：確保手機版視窗正確縮放

Viewport設定：確保手機版視窗正確縮放

在行動裝置上瀏覽網頁時，最常見的問題就是畫面被拉伸、字體太小或是需要左右滑動才能看到完整內容。

這些都是因為沒有正確設定 viewport 造成的。透過一個簡單的 meta 標籤，就能告訴瀏覽器「請以裝置寬度來顯示網頁，並且初始縮放比例為 1」。

如何在 HTML 中加入 viewport

在 <head> 區塊內貼上以下程式碼：
<meta name="viewport" content="width=device-width, initial-scale=1">

說明：

  • width=device-width 代表畫面寬度等於裝置螢幕寬度；
  • initial-scale=1 讓頁面一開始不會被自動縮放。

舉例：

假設你有一個手機版網站，網址為 https://example.com，打開後看到畫面被拉伸成超大字體，那麼就很可能是忘記加上這行程式碼。

常見錯誤與排除方法
  • 沒有設定 viewport：瀏覽器會預設為 980px 寬，導致手機顯示失真。
  • 寫成 initial-scale=0 或小於 1：頁面一開始就被縮小，看起來像是「太細」的樣子。
  • 使用 maximum-scale=1 並禁止放大：會讓使用者無法自行放大，對視力不佳者不友善。

建議做法：

  • 只設定 width=device-width, initial-scale=1，必要時再加上 user-scalable=yes 允許使用者自由縮放。
  • 若要限制過度縮放，可改用 maximum-scale=2 或 minimum-scale=0.5。
小結

只要把這行 meta 標籤貼在 <head> 裡，絕大多數手機瀏覽器就能自動以正確比例呈現網頁。記得每次改版時都要確認它還在位！

觸控目標尺寸：避免按鈕太小影響使用者體驗

觸控目標尺寸的重要性

在手機上，點擊的準確度跟螢幕大小有關。若按鈕太小，用戶會不斷滑到錯誤位置，造成挫敗感。
舉例來說：一個 10px 的圖示按鈕，在 iPhone 13 上實際尺寸只有約 2.5mm，連手指都難以準確觸碰。

設計最佳做法

1️⃣ 按鈕最小寬高 44px（≈11mm）是業界共識。
2️⃣ 內邊距（padding）至少 8px，讓文字或圖示不會被擠壓。
3️⃣ 避免將多個功能放在同一行，保持足夠空間。
4️⃣ 使用 cursor:pointer; 樣式提示使用者可點擊。

CSS 範例

button { min-width:44px; min-height:44px; padding:8px; }

AMP 方案考量：是否適合你的網站

AMP 方案考量：是否適合你的網站

在手機使用者持續增長的今天，速度成為 SEO 的關鍵。AMP（Accelerated Mobile Pages）是一種專為行動裝置優化的技術，但它並不一定是每個站台都該採用的最佳方案。以下就跟你聊聊什麼時候、怎樣才選擇 AMP，還有替代方案。

1️⃣ 先了解你的流量來源
  • 新聞類網站：像《聯合報》或《自由時報》，大部分讀者透過手機搜尋新聞。AMP 能減少載入時間，提升點擊率與停留時間。
  • 電商平台：如「蝦皮購物」或「露天拍賣」，使用者常在瀏覽商品時快速切換頁面。AMP 在商品列表頁表現不錯，但單筆產品的詳細資訊往往需要完整互動，這時可考慮只對熱門類別開啟 AMP。
  • 部落客或個人網站：流量多來自社群分享，速度固然重要，但內容豐富（影片、圖表）時 AMP 可能會限制展示方式。可以先測試幾篇文章的載入時間，再決定是否全面推廣。
2️⃣ 評估技術成本與維護難度
  • 開發投入：AMP 頁面必須遵守嚴格的 HTML 標記，不能使用一般 JavaScript。若你已有自訂腳本，轉為 AMP 需要重寫或改用內建指令。
  • 內容管理系統（CMS）整合：WordPress 透過官方插件可以快速產生 AMP 頁面；但如果你是自訂程式，需要自行實作模板。若 CMS 更新時 AMP 模組不跟進，維護成本會上升。
  • 測試與排錯：AMP 有自己的驗證工具（例如 Google Search Console 的 AMP 檢查器）。在正式發佈前必須先把所有頁面通過驗證，否則搜尋結果可能顯示「無效」或不呈現。
3️⃣ 看是否符合商業目標
  • 廣告收入：AMP 原生支援 Google AdSense 的 AMP 廣告，但若你依賴自訂廣告網路，可能需要額外開發。若廣告是主要收益來源，先評估是否能轉換為 AMP 版。
  • 品牌形象：如果你的品牌重視「輕盈、快速」的使用體驗，AMP 可以協助傳達這種感受。但如果你希望在頁面上展示大量自訂動畫或互動效果，AMP 的限制可能會削弱品牌特色。
4️⃣ 替代方案與最佳化策略
  • Core Web Vitals：Google 強調「Largest Contentful Paint（LCP）」、"First Input Delay（FID）」、"Cumulative Layout Shift（CLS）」三項指標。透過靜態資源優化、Lazy Load 影像等方式，也能達到相似的速度提升，而不必放棄完整功能。
  • PWA（Progressive Web App）：如果你想在手機上提供「離線閱讀」或「推播通知」功能，PWA 是更靈活的選擇。AMP 只能載入一次內容，無法做到持續更新。
  • SSR + CDN 快取：利用伺服器端渲染（Server‑Side Rendering）與全球 CDN，可以在多地快速回應，同時保留所有互動功能。
5️⃣ 小結：什麼時候選擇 AMP？
  • 高流量新聞、內容聚合站：需要極速載入且主要是閱讀體驗。<br>例如《中央社》或《即時通訊》在手機上使用 AMP，能有效提升用戶停留與分享率。
  • 產品目錄頁面：商品列表需快速顯示多筆資料，AMP 可縮短首屏載入時間。但詳細頁面最好還是非 AMP 版，以保留完整互動性。
  • 測試階段：先對 5-10% 的熱門文章做 AMP 試驗，觀察跳離率、平均停留時間等指標。若改善明顯，再擴大覆蓋範圍；否則可考慮其他優化方式。

如果你不確定是否適合 AMP，建議先從「測試小規模」開始，或諮詢技術專家評估。最重要的是：速度好、體驗佳才能真正提升 SEO 與使用者滿意度。

安全性與SSL檢查：HTTPS是基本條件

憑證有效性檢查：確保 HTTPS 不被瀏覽器拋棄

憑證有效性檢查概念

在 SEO 審核中，HTTPS 的可信度直接影響搜尋排名與使用者信任。若憑證過期、名稱不符或簽發機構不受信任，瀏覽器會把網站視為不安全，甚至拋棄連線。

常見的問題包括：

  • 憑證已過期（Expiry）
  • 主機名稱與憑證不匹配（Common Name mismatch）
  • 受信任根憑證缺失（Untrusted root）
  • 中間憑證鏈斷開（Broken chain）

憑證有效性檢查流程

  1. 使用瀏覽器 DevTools
  • 在 Chrome 或 Edge 的「安全」標籤查看憑證狀態。
  • 觀察「連線安全」區塊是否顯示綠色鎖定圖示，若有紅叉表示問題。
  1. 利用 OpenSSL 命令列
  • openssl s_client -connect example.com:443 -servername example.com 取得完整憑證鏈。
  • 查看 subject, issuer, notBefore, notAfter 欄位，確定日期與主機名稱一致。
  1. 線上工具快速檢查
  • SSL Labs 提供完整報告，包括失效、重複使用或缺少中間憑證的情況。
  • 也可用 curl -v https://example.com 查看 TLS 握手細節。
  1. 檢查根憑證受信任度
  • 在 Windows 的「憑證管理員」或 macOS 的鑰匙圈中確認根 CA 已列入受信任的根憑證存儲。
  1. 自動化監控
  • 設定 cron job 週期性執行 openssl 指令，若發現即將到期或失效則立即發送通知。
  • 可使用第三方服務（如 UptimeRobot）搭配 webhook 自動提醒。

混合內容清理：避免 HTTP 與 HTTPS 同時載入造成風險

當網站同時從 HTTP 與 HTTPS 載入資源，瀏覽器會視為「混合內容」，不僅影響安全性，也可能被搜尋引擎降權。
本文將說明如何快速偵測、清理混合內容，以及實務操作範例，確保網站在 SSL 檢查中通過。

混合內容清理：避免 HTTP 與 HTTPS 同時載入造成風險

為什麼要清理混合內容？
  • 搜尋引擎會把混合內容的頁面視為不安全，影響排名。
  • 使用者瀏覽器可能顯示警告或直接阻止資源載入，使用體驗下降。
步驟一：偵測混合內容
  1. 打開 Chrome 或 Edge 的「開發人員工具」(F12)。
  2. 前往 "Console" 標籤，搜尋 "mixed content" 相關訊息。
  3. 或前往 "Network" 標籤，篩選 "Mixed Content"，查看被阻擋的 URL。
步驟二：修正資源連結
  • 將所有 http:// 開頭的連結改為 https://，或使用相對路徑 //example.com/ 以自動採用目前協定。
  • 若外部 API 或 CDN 僅提供 http，請聯絡供應商或尋找 HTTPS 替代品。
步驟三：更新站內連結與引用
  • 使用搜尋替換功能，例如在 WordPress 的 phpMyAdmin 執行：
    UPDATE wp_posts SET post_content = REPLACE(post_content, 'http://', 'https://') WHERE post_content LIKE '%http://%';
  • 若使用 JavaScript 動態載入資源，確保 URL 為 https 或相對路徑。
步驟四：驗證修正結果
  • 再次開啟「開發人員工具」，確認 "Mixed Content" 消息已消失。
  • 透過 Google Search Console 的安全性報告，確定沒有新混合內容警示。
常見陷阱與建議
  • 圖片、CSS 或 JS 可能被隱藏在 template 檔案內，請檢查主題或插件來源。
  • 第三方廣告或社群分享按鈕經常使用 http，最好改為 HTTPS 或完全移除。
  • 設定伺服器自動重導向：在 Apache 的 .htaccess 加入 RewriteCond %{HTTPS} off
    RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] 以確保所有請求皆使用 HTTPS。