注意事項

• 本篇只限台北市的維修站。其它縣市的流程可能不一樣。
• 維修的產品有 SD，Micro SD, USB 隨身碟。

維修經驗

• Sandisk 。服務人員提醒沒有在維修，一律一換一。也不會還原或救資料。同意後會直接給一個全新品。
• Apacer。服務人員提醒不會還原或救資料，上電腦確認狀況後開維修單。維修完成後會通知再過來領取(新品)。

結論

Sandisk 勝。個人是建議在價格及產品效能差不多時選 Sandisk 。需維修更換是光是跑一次跟跑兩次的時間就勝過那些差價。

BPI-M2 Plus 規格

• 四核1.2GHz CPU.
• 1 GB DDR3內存.
• Mali-400 MP2 with Open GL ES 2.0/1.1.
• 8 GB eMMC儲存.
• 板載Wifi.
• 板載藍牙.

它的 8 GB eMMC 可把 micro SD 卡上的 OS 轉到 eMMC上。前提是 micro SD 卡上裝完的 OS 大小不得超過 8 GB。理想應該低於 5.5 GB 。你得留一些空間給程式或 LOG 檔。把 OS 從 micro SD 卡移到 eMMC 的好處是磁碟的速度快多了。在 SSH 的操作上感覺就不是一個級別的。

OS 選擇

由於未來可能會把 OS 由 micro SD 卡轉至 eMMC 上，所以在選擇 OS 上我是選擇 Minimal / IOT 上的 Ubuntu 24.04 。千萬不要選 Debian 13 在我 202604 月下載安裝時會卡在開機。但使用 Ubuntu 24.04 則不會。

刷 OS 至 SD 卡

可使用

• Win32 Disk Imager
• Rufus

這兩個擇一即可。把 image 刷至 micro SD 卡後放進版子上的 micro SD 卡的插槽裡之後打開電源即可。途中會要求輸入 root 的新帳密跟 1 個使用者的帳號資料及 OS 的時區。請依序輸入即即。

建議額外裝的程式

• Adguardhome
• Vaultwarden 

#Adguardhome 安裝方式
curl -s -S -L https://raw.githubusercontent.com/AdguardTeam/AdGuardHome/master/scripts/install.sh | sh -s -- -v

散熱片的選擇

• 2 x 2 x 1 小負載約 48-55 度(無風扇，一般家庭無冷氣的室溫下。室溫 28 °C )
• 4 x 4 x 2 小負載約 36-45 度(無風扇，一般家庭無冷氣的室溫下。室溫 28 °C )

一般來說只要低於晶片的工作溫度即可(-10 ~ 70 °C)，但如果你對溫度有執著可參考我的經驗一般還是在可允許的範圍內裝越大溫度會越低。不需要風扇會相對安靜點。

📌 Google 官方說法（重點）

Google 搜尋代表 John Mueller 在 Reddit 表示：

「Google 必須有意願去收錄更多內容」

如果它不確信你的網站有新的、重要的內容

👉 就不會使用 sitemap

這句話非常關鍵。

代表：

🔹 Sitemap 只是「提示」
🔹 不是「命令」

📌 這代表什麼？

很多站長的錯誤理解是：

我有 sitemap → Google 就會收錄

實際上流程是：

提交 sitemap
    ↓
Google 評估網站價值
    ↓
決定要不要抓
    ↓
決定要不要收錄

Google 不是照單全收。

📌 為什麼 Google 可能忽略 sitemap？

簡單說：

Google 會先判斷：

✔️ 網站是否有新內容
✔️ 是否有價值
✔️ 是否值得增加索引量

如果答案是 ❌

那 sitemap 裡的 URL：

👉 可能完全不會被處理

📌 延伸觀念（很重要）

文章也提到一個現實：

幾乎沒有網站能讓所有頁面都被收錄

即使：

✔️ 技術完全正確
✔️ sitemap 沒問題

Google 仍然只會選擇性收錄。

📌 與 Crawl / Index 的關係

另一段 John Mueller 的說法補充：

如果 Google 無法有效抓取：

👉 頁面會開始「從索引掉出」

而抓取速度、網站品質等
其實都是同一個問題的症狀。

📌 SEO 實務上的真正意思

這篇文章其實在提醒：

❌ Sitemap 不是 SEO 解法

❌ 提交 sitemap 不等於收錄

真正影響索引的是：

✔️ 內容品質
✔️ 網站更新
✔️ 網站重要性
✔️ 抓取價值

📌 一句話總結

👉 Sitemap 只是「邀請 Google 來看」
👉 但 Google 會決定要不要理你

如果你的站沒有被認為：

「有新且重要內容」

那 sitemap = 可能被忽略。

原始網站來源

個人認為 SEO 未明說的部份

點這裡看原始網站內容

相關文章

• Rank Math SEO 如何排除 Sitemap.xml 被快取住
• Rank Math SEO IndexNow 功能解說

這個通訊協定的運作方式，是讓網站只需將 URL 提交一次到 IndexNow API，該 URL 就會自動分享給所有參與的搜尋引擎。也就是說，你只需要提交一次網站變更與 URL，所有支援 IndexNow 的搜尋引擎都能即時得知你網站的最新狀態，並更快地進行爬行、索引，讓這些變更更早反映在搜尋結果中。

各位有看到 Rank Math SEO IndexNow 其實不含 Google 的搜尋引擎。也就是說 Rank Math SEO IndexNow 的功能對於現階段的搜尋環境來說實在沒什麼加分。台灣約有 7-8 成以來的流量都來至 Google 但只裝 Rank Math SEO 是不夠的，因為它不會通知 Google index API。

解決方式

安裝 Instant Indexing for Google Rank Math SEO 寫的。額外的免費外掛。

開通 Google Index API

• 開通 Google Cloud . 註冊(需信用卡)。一定要加開 2FA 驗証。防被開主機挖礦
• 開通 Google Index API 每天 200 筆不收費
• 建立 service account 並下載該認証檔。
• 把 service account 加入至 google search console 的權限列表理並調整為完整權限
• 用外掛上傳認証檔。

這只是簡短的步驟。實際上第一次作的人可能要花更多的時間來處理。不想自動化的則可手動加文章 URL 至 Google Search Console ，也是可以。只是每次新增修改文章都要記得去 Google Search Console 手動增加 URL 。有人會問那不作可不可以？當然可以只是文章被收錄至 Google 搜尋會慢一點。

解決方式

一般會以 robots.txt 來解備，但這緩不濟急，你得讓 Bingbot 重新讀取後才有可能生效。但問題是現在正面臨該問題。且也不知道新的 robots.txt 何時會生效。這邊我建議的是用 .htaccess 解決。直接擋 User Agent 是 bingbot 且搜尋字串有特定字出現。如附圖

40.77.167.17 - - [26/Dec/2025:15:14:15 +0800] "GET /search?source=keyword HTTP/1.1" 301 4246 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm) Chrome/116.0.1938.76 Safari/537.36"
40.77.167.1 - - [26/Dec/2025:15:14:20 +0800] "GET /search?source=keyword HTTP/1.1" 301 4246 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm) Chrome/116.0.1938.76 Safari/537.36"
40.77.167.17 - - [26/Dec/2025:15:14:38 +0800] "GET /search?source=keyword HTTP/1.1" 301 4246 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm) Chrome/116.0.1938.76 Safari/537.36"
40.77.167.17 - - [26/Dec/2025:15:14:39 +0800] "GET /search?source=keyword HTTP/1.1" 301 4246 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm) Chrome/116.0.1938.76 Safari/537.36"
40.77.167.17 - - [26/Dec/2025:15:14:40 +0800] "GET /search?source=keyword HTTP/1.1" 301 584 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm) Chrome/116.0.1938.76 Safari/537.36"
40.77.167.17 - - [26/Dec/2025:15:14:41 +0800] "GET /search?source=keyword HTTP/1.1" 301 584 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm) Chrome/116.0.1938.76 Safari/537.36"

在 .htaccess 加上如下程式碼，

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{QUERY_STRING} (^|&)source=keyword(&|$) [NC]
RewriteCond %{HTTP_USER_AGENT} bingbot [NC]
RewriteRule ^ /? [R=301,L]
</IfModule>

注意事項

每個 URL 擋的規則都不一樣，得分析網頁記錄上的規則性。看不沒有同樣的規則，再利用同樣的規則寫 .htaccess 的條件。有用 chatgtp 或 gemini 的也可請 AI 寫，方便很多。

其它網上討論的相關問題 我自已的網站是發生明明我的是資訊網站但 BingBot 會搜健康或營養的關鍵字

一、為什麼 WordPress「一定要設」Security Headers？

WordPress 生態＝高風險目標

• 外掛多、主題多
• 第三方 JS 多（廣告、追蹤、GA、FB）
• 外掛品質參差不齊

就算你自己寫得很乾淨，
外掛一個 XSS 漏洞就全站陪葬

二、設定 Security Headers 的實際好處

1. 防止 XSS（最重要）

Content-Security-Policy

沒設 CSP

• 任何 inline script 都能跑
• 外掛被插 <script>alert(1)</script> 就 GG

有設 CSP

• 只允許特定來源 JS
• inline script 預設不能跑

👉 XSS 成功率直接下降 80% 以上

2. 防止 Clickjacking（iframe 釣魚）

X-Frame-Options: SAMEORIGIN

防止：

• 網站被嵌進別人頁面
• 用透明按鈕誘導你點擊（後台操作）

👉 對 WordPress 後台特別重要

3. 防止瀏覽器亂猜檔案類型

X-Content-Type-Options: nosniff

防止：

• .jpg 被當成 JS 執行
• 上傳檔案被惡意利用

👉 對有上傳功能的站（媒體、會員）很重要

4. 強制 HTTPS（SEO + 安全）

Strict-Transport-Security (HSTS)

效果：

• 瀏覽器永遠只走 HTTPS
• 防中間人攻擊
• Google 加分項目

👉 Cloudflare + WordPress 必設

5. 限制 Referer 洩漏資料

Referrer-Policy

避免：

• URL 中的 token、參數被送到第三方
• 追蹤、外洩敏感資訊

6. 提升 SEO 與信任度（間接）

• Lighthouse Security 分數↑
• Google PageSpeed 建議項目
• 減少惡意 JS 被插入 → 不被標示為「此網站可能有害」

三、htaccess 設定 Security Headers

在 .htaccess 增加下方程式。

<IfModule mod_headers.c>
    ##########################################
    # HTTPS / HSTS 強制安全連線
    ##########################################
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

    ##########################################
    #  X-Frame-Options (防止 Clickjacking)
    ##########################################
    Header always set X-Frame-Options "SAMEORIGIN"

    ##########################################
    # X-Content-Type-Options (防止 MIME 偽裝)
    ##########################################
    Header always set X-Content-Type-Options "nosniff"

    ##########################################
    # Referrer Policy (保護隱私)
    ##########################################
    Header always set Referrer-Policy "strict-origin-when-cross-origin"

    ##########################################
    #  X-XSS-Protection (舊版瀏覽器 XSS 防護)
    ##########################################
    Header always set X-XSS-Protection "1; mode=block"


</IfModule>

<IfModule mod_headers.c>
Header always set Content-Security-Policy "default-src 'self' https:; img-src 'self' data: https:; media-src 'self' https:; script-src 'self' 'unsafe-inline' 'unsafe-eval' https:; style-src 'self' 'unsafe-inline' https:; font-src 'self' data: https:; connect-src 'self' https:;"
</IfModule>


<IfModule mod_headers.c>
    Header always set Permissions-Policy "geolocation=(), camera=(), microphone=(), payment=(), usb=(), fullscreen=(self), autoplay=(self)"
</IfModule>

之後至 https://securityheaders.com/ 測試一下。分數應該是 A 。要得到 A+ 得看網站所使用的外掛跟連接分析後調整 Content-Security-Policy 這個 Header 。不然設太嚴可能網站前後台會有問題。

你真的應該為使用者打造優質、獨特且原創的內容。當然,可能會出現一些捷徑,就像SEO 一樣,但那些不會持久。所以最好的策略是創作原創內容。我想人們也想要真實可信的優值內容。

此外,不要只專注於文字內容,還要包括影片、音訊、視覺和其他格式。

事實上,Danny Sullivan說他認為 AI SEO、GEO 或無論你想怎麼稱呼它,都應該歸類在 SEO 之下,作為 SEO 的一個子集。

SEO For AI 37 分鐘的談話內容重點

✅ 傳統 SEO = AI 搜尋的 SEO

• SEO 的基本原則沒有因為 AI 而改變。
• 大部分現在看到的 GEO、AIO 等名詞，其實只是 SEO 的子集。

✅ 內容品質優先，為使用者創作內容

• 不要只專注 SEO 本身，而是 寫出對使用者有價值的內容。
• 就算未來出現「SEO最佳化」，就像過去 SEO 的技巧一樣，那些捷徑不會長久有效。(個人感覺這跟每季的 Search Console 核心更心有關)
  最好的做法仍然是製作原創且獨特的內容。

✅ 不要只限於文字內容

• 不只文字，影片、音頻、圖片等其他媒體形式也很重要。(跟你說文章圖文並茂很重要)
• 存在於不同格式的內容，也能幫助網站被 AI 搜尋更好理解與呈現。

✅ 現在技術 SEO 多已內建於 CMS 系統

• 許多過去需要手動處理的技術 SEO，現在大多由內容管理系統（CMS）平台自動處理。(個人覺得特定流行的 CMS 應有加分。如 WordPress)
• 現在的焦點可以更多放在內容本身而不是技術細節。

✅ 不要把注意力放在特定搜尋引擎

• 過去 SEO 人員可能會為了不同搜尋引擎做不同版本的內容，但現在差異越來越小。
• 把焦點放在使用者想要看的內容，而不是哪一個搜尋引擎。

✅ AI 的優勢：原生能處理非原創內容

• 大型語言模型（LLM）和其他 AI 系統，其實已經能很好地處理那些非原創、普遍內容，例如：
  「超級盃幾點開始？」這類答案性的問題。

✅ 人們真正想找的是原創與真實內容

• 使用者想看到的不是可被機器自動回答的資訊，
  而是像 影片、Podcast、論壇中的第一手經驗、專家見解。
  這些內容不是 AI 簡單能產出的。

✅ 真實與共鳴勝過形式技巧

• 內容是否能與讀者共鳴，是否真實，比技巧更重要。
• Danny 提到： 真正重要的，是你對追隨你的人是否真誠，而不是刻意為搜尋系統寫內容。

✅ Danny Sullivan 不喜歡 “Multimodal” 這個名詞

• 他不喜歡用「多模態」這詞來描述 AI 搜尋，不想用太複雜的名稱來區分。
• 核心其實是：你用一種方式提問，AI可能用另一種方式回應。

✅ 成功不只看點擊數，而是「優質點擊與轉換」

• AI 搜尋格式將更強調參與度、高品質的互動，而非純流量。
• 使用者停留時間長、更專注於他們想要的資訊。

📌 另一個重要觀念：Query Fan-Out

• John Mueller 提到所謂的 query fan out：
  AI 系統會自行進行大量查詢，然後整合成一個答案。
  你過去靠傳統搜尋獲得的點擊，可能並不如 AI 格式裡的「深入互動」來得有效。

📌 AI 搜尋追蹤與分析工具仍需改進

• 包括 Google Search Console 也需要調整，
  讓網站持有人能更清楚了解自己的內容如何被 AI 搜尋找到。

原始網站內容

為何按裝了快取外掛 CPU 還是飆高

這些都會即時執行 PHP 程式作回應。也就會造成大量的 php 的 process 出現。除了回應變慢之外也有可能造成系統資源吃光短暫網站會連不上線，尤其是那些 5-12 美元每月的便宜主機。

解決方案一： 使用 robots.txt 擋 AI 爬蟲

User-agent: GPTBot
Disallow: /

User-agent: ChatGPT-User
Disallow: /

User-agent: OpenAI
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: anthropic-ai
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: PerplexityBot
Disallow: /

User-agent: Amazonbot
Disallow: /

User-agent: Applebot-Extended
Disallow: /

User-agent: Bytespider
Disallow: /

User-agent: YandexAI
Disallow: /

User-agent: Meta-ExternalAgent
Disallow: /

User-agent: Meta-ExternalFetcher
Disallow: /

# 預設允許一般搜尋引擎
User-agent: *
Allow: /

解決方案二： 使用 .htaccess 擋 AI 爬蟲

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (GPTBot|ChatGPT-User|ClaudeBot|CCBot|PerplexityBot|Bytespider|anthropic-ai|Google-Extended) [NC]
RewriteRule .* - [G,L]
</IfModule>

解決方案三： 使用 Cloudflare

 Security Settings -> Settings

一：使用 Cloudflare 阻擋 AI BOT 功能。

二：按裝一個快取外掛(只要一個不要多裝。會相互影響)

1. WP Super Cache

• Automattic 官方出品
• 產生靜態 HTML，效能穩定
• 簡單易用、設定快速
• 適用：共用主機、一般網站

2. W3 Total Cache (W3TC)

• 功能最完整的快取外掛之一
• 支援 Page Cache、Object Cache、Database Cache、Minify
• 可整合 CDN
• 適用：需要高度客製化的網站

3. WP Fastest Cache

• 界面簡單，效果顯著
• 支援 Minify、瀏覽器快取、合併 CSS/JS
• Pro 版可支援圖片壓縮、Mobile Cache
• 適用：不想複雜設定的使用者

4. LiteSpeed Cache (LSCWP)

• 若主機使用 LiteSpeed Web Server，效能頂尖
• 全站快取、Object Cache、圖片優化、CDN
• 一站式網站加速方案
• 適用：LiteSpeed 主機、Cloudways、cPanel LiteSpeed

5. Cache Enabler

• 由 KeyCDN 開發
• 輕量級快取外掛
• 支援 WebP、自動清除快取
• 適用：希望快取外掛越簡單越好

6. Hummingbird Performance

• Page Cache + 檔案壓縮 + 資源優化
• 有效提升 GTmetrix / PageSpeed 分數
• 與 Smush 圖片壓縮搭配效果更佳
• 適用：需要完整站點優化工具

7. Comet Cache

• 前身為 ZenCache
• 自動快取清除、自動版控
• 安裝即可用，設定簡單
• 適用：一般中小型網站

8. Breeze (Cloudways)

• Cloudways 官方快取
• 支援 Varnish、Minify、Gzip
• 適用：使用 Cloudways Hosting 的網站

9. NitroPack（加速服務）

• 雲端加速，不只快取
• 自動優化 CSS/JS、lazy load、CDN
• 快但過度優化可能影響 Lighthouse 分析
• 適用：需要“一鍵加速”的網站

推薦搭配方式

• LiteSpeed 主機 → LiteSpeed Cache
• 一般虛擬主機 → WP Super Cache / WP Fastest Cache
• 需要極高自訂 → W3 Total Cache
• 只要小巧快速 → Cache Enabler

個人習慣 WP Fastest Cache 。快取多半大同小異不用特別研究。號稱最快的也快不了多少。主機快硬碟快較實在。

三：Cloudflare Cache Rule 快取規則。

這個設定主要是用來對付專門直抓 API 的。wordpress 預設是有開放的。那些 AI 商也都知道直接抓 API 回傳的 XML 方便 AI 處理。如下

• /wp-json/wp/v2/posts/186428
• /wp-json/oembed/1.0/embed?url=

但是這些 API 在預設的快取模組上並不會主動作快取的動作。也就是每一次 CALL API 的都需要 PHP / MYSQL 作大量的運算然後回傳結果給 AI 。這也是在主機上已封機器人後還 CPU 爆增的可能原因之一。

在 Cloudflare 管理介面 Caching -> Cache Rules 增加規則

其中 TTL 視自已的情況設定。通常如文章不會經常改的可設定大一點，如 1 個月。