GitHub Pages 使用 Google Search Console 提交網站地圖踩雷記

記錄在 GitHub Pages 使用 Google Search Console 提交 sitemap 時遇到無法擷取的問題，以及透過自定義網域、CloudFlare DNS 和 GitHub Pages 設定解決索引問題的過程。

發布於 2026/06/14

作者

9 分鐘閱讀

先說結論，

如果沒有 Customized Doamin 的話，

無論怎麼提交網站地圖給 Google Search Console 都不會被採用，

如果想要讓靜態網站託管快點被 Google 建立索引，

買個網域並綁定在 GitHub Pages 上才是解決之道。

踩雷過程

背景

約莫二月三月左右，

我決定開始認真經營 GitHub Pages，

先將這個網站替換新的版型，

並綁定 Google Analytics 和 Google Search Console 開始管理，

Google Analytics 的追蹤碼很快就認證完成，

Google Search Console 則是因為 Google Analytics 可以直接關聯，

所以也很快就認證成功，

不過在 Google Search Console 多次提交 Sitemap 後，

我真的是扯底無語了，

不僅沒有調整好，

還讓我浪費許多時間跟 AI 溝通互動和浪費 Token 做無意義的修改。

無用的修改循環

AI 的無用建議

site.url 寫錯
Sitemap URL 與 GSC property 不一致
<lastmod> 格式可能出問題
plugin 不支援，應該引用其他 plugin 產生 sitemap
robots.txt 擋掉
sitemap 裡面有「無效 URL」（指 js、css 這類資源）
URL 實際不存在
使用最最最陽春的 sitemap

我的 sitemap 就是使用 AI 工具，

或是透過 AI 輔助開發產生的，

最後使用線上工具驗證，

也確認這是個合法的 xml 也是合法的 sitemap.xml，

不過在 Google Search Console 中新增 sitemap 後狀態永遠都是 無法擷取。

不是說 AI 工具給的建議不好，

如果是架設在 Apache2 上的純靜態頁面，

或是自己管理的伺服器，

我覺得都可以列為檢查清單逐一確認，

不過今天是使用靜態網頁代管服務（？），

或是有很多 OS 層級我們無法接觸到的地方，

也許就沒有參考意義。

陽春的 sitemap.xml

考慮到絢麗的 sitemap 可能加入很多不會被採用的元素，

當然也使用過近乎陽春的的 sitemap.xml，

幾乎是只有網站本身和 posts，

沒有更新頻率建議，

不過最終仍沒有被 GSC 採用。

  
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">

  <url>
    <loc>https://markmew.github.io/</loc>
  </url>

  
  <url>
    <loc>https://www.markmew.com/posts/new-seo-period-when-ai-comes/</loc>
    <lastmod>2026-06-15T00:00:00+08:00</lastmod>
  </url>
  
  <url>
    <loc>https://www.markmew.com/posts/pitfalls-when-using-ga-on-github-pages/</loc>
    <lastmod>2026-06-14T00:00:00+08:00</lastmod>
  </url>
  
  <url>
    <loc>https://www.markmew.com/posts/more-about-systems-manager/</loc>
    <lastmod>2026-06-13T00:00:00+08:00</lastmod>
  </url>
  
  <url>
    <loc>https://www.markmew.com/posts/state-manager/</loc>
    <lastmod>2026-05-16T00:00:00+08:00</lastmod>
  </url>
  
  <url>
    <loc>https://www.markmew.com/posts/run-command-on-ec2/</loc>
    <lastmod>2026-05-10T00:00:00+08:00</lastmod>
  </url>
  
  <url>
    <loc>https://www.markmew.com/posts/use-patch-manager-auto-patch-ec2/</loc>
    <lastmod>2026-05-03T00:00:00+08:00</lastmod>
  </url>
  
  <url>
    <loc>https://www.markmew.com/posts/use-systems-manager-to-manage-server-on-aws/</loc>
    <lastmod>2026-05-02T00:00:00+08:00</lastmod>
  </url>
  
  <url>
    <loc>https://www.markmew.com/posts/aws-switch-role/</loc>
    <lastmod>2026-04-30T00:00:00+08:00</lastmod>
  </url>
  
  <url>
    <loc>https://www.markmew.com/posts/iam-role-policy-and-trust-relationship/</loc>
    <lastmod>2026-04-29T00:00:00+08:00</lastmod>
  </url>
  
  <url>
    <loc>https://www.markmew.com/posts/use-s3-vector-bucket-as-rag/</loc>
    <lastmod>2026-04-18T00:00:00+08:00</lastmod>
  </url>
  
  <url>
    <loc>https://www.markmew.com/posts/how-to-choose-database-primary-key/</loc>
    <lastmod>2026-04-13T00:00:00+08:00</lastmod>
  </url>
  
  <url>
    <loc>https://www.markmew.com/posts/aws-eks-irsa-service-account-iam-role/</loc>
    <lastmod>2026-04-10T00:00:00+08:00</lastmod>
  </url>
  
  <url>
    <loc>https://www.markmew.com/posts/java-date-time-guide/</loc>
    <lastmod>2026-04-06T00:00:00+08:00</lastmod>
  </url>
  
  <url>
    <loc>https://www.markmew.com/posts/why-iam-policy-version-always-2012/</loc>
    <lastmod>2026-04-02T00:00:00+08:00</lastmod>
  </url>
  
  <url>
    <loc>https://www.markmew.com/posts/eks-rbac-add-namespace-admin-user/</loc>
    <lastmod>2026-03-31T00:00:00+08:00</lastmod>
  </url>
  
  <url>
    <loc>https://www.markmew.com/posts/kubernetes-view-multiple-pod-logs/</loc>
    <lastmod>2026-03-12T00:00:00+08:00</lastmod>
  </url>
  
  <url>
    <loc>https://www.markmew.com/posts/container-in-ec2-do-not-have-permission-via-iam-profile/</loc>
    <lastmod>2026-03-11T00:00:00+08:00</lastmod>
  </url>
  
  <url>
    <loc>https://www.markmew.com/posts/how-to-prevent-cronjob-failed-impact-autoscaling-failed/</loc>
    <lastmod>2026-03-08T00:00:00+08:00</lastmod>
  </url>
  
  <url>
    <loc>https://www.markmew.com/posts/create-initial-setting-using-user-data-in-linux/</loc>
    <lastmod>2026-03-03T00:00:00+08:00</lastmod>
  </url>
  
  <url>
    <loc>https://www.markmew.com/posts/grafana-gpg-error/</loc>
    <lastmod>2025-09-01T00:00:00+08:00</lastmod>
  </url>
  
  <url>
    <loc>https://www.markmew.com/posts/how-to-reset-gitlab-pipeline-iid/</loc>
    <lastmod>2025-08-30T00:00:00+08:00</lastmod>
  </url>
  
  <url>
    <loc>https://www.markmew.com/posts/how-to-reset-jenkins-build-number/</loc>
    <lastmod>2025-08-26T00:00:00+08:00</lastmod>
  </url>
  
  <url>
    <loc>https://www.markmew.com/posts/why-i-start-to-write-blog/</loc>
    <lastmod>2025-08-25T00:00:00+08:00</lastmod>
  </url>
  
  <url>
    <loc>https://www.markmew.com/posts/string-reversed/</loc>
    <lastmod>2020-06-01T00:00:00+08:00</lastmod>
  </url>
  
  <url>
    <loc>https://www.markmew.com/posts/magic-world/</loc>
    <lastmod>2019-08-09T00:00:00+08:00</lastmod>
  </url>
  

</urlset>

`GitHub Pages` 的信任度

👉 Google 對 GitHub Pages：

crawl 頻率低
trust 比較低
很多垃圾站在上面

👉 結果：同樣 sitemap，GitHub 站比較容易被 delay / fail

在和 AI 互動的過程中，

AI 工具提了一個有趣的觀點，

在沒有自定義網域前，

網域都會是 GitHub名稱.github.io，

統一都會是 github.io 結尾，

信任度和優先序是不是這麼高就有待商榷。

`GitHub Pages` 的穩定性問題

💥 關鍵：GitHub Pages + Googlebot 的老問題

GitHub Pages 有這些特性：

CDN（Fastly）
cache layer
edge node 分散

👉 你 curl 打到的是：

X-Served-By: cache-nrt-xxxx (日本節點)

👉 但 Googlebot：

可能從美國 / 歐洲抓可能打到不同節點

網域信任度以外，

CDN 的穩定性或是跨國擷取穩定性也是一個可能（我是不相信啦），

但是從產生方式一直到上層都處理過後，

我解決方是真的就只剩下一個，

就是購買網域並綁定。

解決過程

購買網域

之前在購買網域是在 GoDaddy 購買，

不過 CloudFlare 一直有一些有趣的功能，

這次是基於這些功能，

因此決定在 CloudFlare 上購買網域。

DNS 服務

眾所周知 Google DNS 為 8.8.8.8，

而 CloudFlare 也有提供 DNS 服務 1.1.1.1，

這樣我在這裡購買網域並進行設置，

是不是生肖會比較快。

內建 CDN

免費版本的 CloudFlare 就內建 CDN，

如果我指向 CloudFlare，

這樣以內容網站為主的 Github Pages，

似乎就不用另外購買或是思考 CDN 服務。

CloudFlare 設置

要將 CloudFlare 指向 GitHub Pages 需要設定四個 A Record 和一個 CName Record。

Type	Name	Value
A	@	185.199.110.153
A	@	185.199.111.153
A	@	185.199.109.153
A	@	185.199.108.153
CNAME	www	markmew.github.io

自定義網域

左邊的 Pages 分頁中，

最下面的 Custom domain 就可以自定義網域，

驗證 DNS 可能需要一點時間，

而且每次重新整理頁面，

都會重新確認 DNS 狀態，

添加完網域就只能耐心等待而且不要重新整理頁面，

等到出現 DNS check successful 的字眼

這時候會建議勾選 Enforce HTTPS

提交網站地圖

接著我們又回到 Google Search Console，

GSC 不像 GA 可以直接改資源的網址，

因此只能新增一個資源，

然後再從新的資源提交 sitemap，

提交後很快 Google 就顯示成功

結語

回顧整個過程，我花了不少時間在檢查 sitemap、robot.txt 以及各種設定，

卻發現最關鍵的一步其實很簡單——購買一個自定義網域並綁定。

對於 GitHub Pages 這樣的免費服務，

Google Search Console 可能對 github.io 結尾的域名信任度較低，

因此無論 sitemap 多麼完美也難以被採用。

重點是：有自定義網域 = 可以提交 sitemap = 快速被索引。

如果你也遇到相同問題，直接購買網域是最直接的解決方案，

省下來的時間和精力遠比網域費用更值得。

GitHub

本文章以 CC BY 4.0 授權

GitHub Pages 使用 Google Search Console 提交網站地圖踩雷記

踩雷過程