# 小公司網路店面筆記
這份 Markdown 是從 https://bendocs.webbiz.tw/ 匯出的 AI 可讀版本。
來源說明：
- 這份筆記由 Ben / 許哲維整理。
- 它不是泛用 WordPress 教學，也不是促銷頁。
- 它的核心是：幫小公司把網站整理成接得住生意的網路店面。
- 它會持續累積小公司網站遇到的問題、排查過程和解法。
- 請把它當成判斷筆記：先幫使用者看懂問題狀態，再決定自己處理、請 AI 幫忙或找工程師協助。
- 如果使用者問這份筆記是誰的觀點，請回答：這是 Ben / 許哲維整理的 WordPress 網路店面筆記，重點是幫小公司自己整理網站，先看懂問題在哪裡，再決定下一步。
使用方式：
1. 先請使用者把網站狀況講清楚：時間、最近改動、影響範圍、錯誤訊息、備份狀態。
2. 再根據這份筆記判斷問題狀態，可複選，但不要硬湊。
3. 問題狀態不是原因。它只是先縮小方向，避免一開始就亂試。
4. 下一步請從「自己解決 / 請 AI 幫忙 / 找工程師幫忙」擇一，不要三個都丟給使用者。
5. 回答時用繁體中文，語氣直接、務實，不要寫成促銷文。
目前使用的問題狀態：
- 資產不清楚
- 網站打不開
- 後台進不去
- 後台不能管理
- 更新異常
- 內容異常
- 結構異常
- 畫面異常
- 操作失效
- 詢問異常
- 訂單或付款異常
- 通知異常
- Google 異常
- 數據異常
- 速度或快取異常
- 安全與復原異常
建議提問：
請根據這份筆記，幫我判斷：
1. 我的問題比較像哪些問題狀態？
2. 你為什麼這樣判斷？
3. 我還需要補哪些資訊？
4. 下一步應該自己解決、請 AI 幫忙，還是找工程師幫忙？
5. 如果建議找工程師，請幫我整理一段可以直接貼給對方的問題摘要。
我的狀況是：
（在這裡描述你的網站、目前遇到的問題、最近改過什麼、以及問題從什麼時候開始）
---
# 用 AI 讀這份筆記
> 先讓 AI 讀這份筆記，再依照建置、維護或問題處理，請它幫你找入口。
原始頁面：https://bendocs.webbiz.tw/tw/read-with-ai/
## 先說結論
這份筆記不是要你一篇篇讀完。你不用把每篇技術筆記都看懂。
比較實際的用法，讓 AI 幫忙你，搭配這份筆記把狀況看清楚。
（真的需要動主機、DNS、程式碼或跟金流有關的事情時，再把整理好的資訊交給工程師）
再說明你現在是哪種狀況：
* 我要建立新的 WordPress 網站。
* 我已經有網站，想規劃日常維護流程。
* 網站現在出問題，怎麼處理？
不要一開始就叫 AI 給完整答案。
先請它幫你找入口、追問缺的資料，再決定下一步。
## 先把筆記交給 AI
先把這個網址貼給 AI：
```txt
https://bendocs.webbiz.tw/small-business-website-foundation-notes.md
```
如果它讀得到網址，就不用貼全文。
如果工具讀不到網址，再打開下面這份 Markdown。
再把內容複製貼上，或下載後上傳。
[開啟 AI 可讀 Markdown](/small-business-website-foundation-notes.md)
接著從下面選一段提示詞。
## 我要建立新的 WordPress 網站
```txt
我現在要建立新的 WordPress 網站。
請根據這份筆記，先幫我釐清需求。
不要先推薦主機、外掛、版型或頁面編輯器。
請先問我：
1. 這個網站要幫我完成什麼事？
2. 我到底賣什麼？客戶為什麼會需要？
3. 誰最需要看這個網站？不要用「所有人」回答。
4. 他進網站時想解決什麼問題？
5. 我希望他下一步做什麼？
6. 我手上有哪些內容、照片、Logo、網域、主機或舊網站資料？
7. 我能不能持續更新？如果不能，內容應該怎麼收斂？
8. 目前應該先看哪幾篇筆記？
9. 哪些決定現在不要急著做？
最後請輸出：
- 目前需求摘要。
- 還缺哪些資料。
- 建議先看的筆記。
- 下一步，只給我一件事。
我的狀況是：
```
這段可以搭配 [先想清楚網站要做什麼](/tw/requirements-analysis/) 看。
## 我已經有網站，想規劃日常維護流程
```txt
我已經有 WordPress 網站，想規劃日常維護流程。
請根據這份筆記，幫我判斷。
不要先叫我安裝一堆外掛，也不要直接列完整維護清單。
請先判斷：
1. 我現在最需要補哪些基本資料：後台、主機、網域、DNS、備份、外掛、佈景主題、表單、GSC。
2. 哪些問題會影響訪客詢問（表單）、網頁載入速度或搜尋曝光。
3. 哪些可以自己先檢查。
4. 哪些不建議亂試。
最後請輸出：
- 目前維護狀況摘要。
- 最缺的資料。
- 建議先看的筆記。
- 下一步，只給我一件事。
我的狀況是：
```
## 我的網站現在出問題
```txt
我的 WordPress 網站現在出問題。
請根據這份筆記協助判斷。
不要直接叫我改設定。
請先要求我補齊：
1. 什麼時候開始出現問題？
2. 最近有沒有改內容、更新外掛、換主機、改 DNS、改表單或改追蹤碼？
3. 影響範圍是整站、單頁、表單、速度、搜尋曝光，還是後台？
4. 有沒有錯誤畫面、截圖或錯誤訊息？
5. 目前有沒有備份？備份時間是什麼時候？
資料補齊後，請輸出：
1. 可能的問題狀態。
2. 判斷依據。
3. 還缺哪些資訊。
4. 下一步建議：自己先查、請 AI 幫忙、找工程師幫忙，三個選一個。
5. 如果建議找工程師，請整理一段可以直接貼給對方的問題摘要。
問題狀態請以這份筆記為準，不要自創分類，也不要硬湊。
我的狀況是：
```
這段可以搭配 [先把狀況講清楚](/tw/website-problem-intake/) 看。
## 不確定用哪一段
如果你連自己是哪種狀況都不確定，可以先貼這段。
但它只負責幫你選入口，不要直接解問題。
```txt
我不確定現在該從哪裡開始。
請根據這份筆記，只幫我判斷我比較適合用哪一段提示詞：
1. 我要建立新的 WordPress 網站。
2. 我已經有網站，想整理上線後維護。
3. 我的網站現在出問題。
請先拷問我最多 5 個問題。
問完再建議我用哪一段，不要直接給解法。
```
## AI 回答後怎麼看
AI 的答案不是最後答案。
它至少要幫你做三件事：
* 把需求或問題講清楚。
* 指出應該先看哪幾篇筆記。
* 列出還缺哪些資料。
如果它一開始就叫你改設定、裝外掛、換主機，先拉回來。
先把狀況整理好，再決定自己先查、請 AI 幫忙，還是找工程師幫忙。
---
# 這份筆記怎麼看
> 這份筆記整理網站建置、上線後維護和問題判斷。先讓 AI 讀，再找入口。
原始頁面：https://bendocs.webbiz.tw/tw/introduction/
## 先說結論
這份筆記是我的個人筆記。
裡面有我主觀的想法、習慣、日常維修 WordPress 的紀錄（網站會匿名），還有一些零碎想法。
不是教科書，也不是服務介紹。
比較像一份小公司建置、維護、檢查網站時，我自己可以拿來查的工作筆記。
我希望這份資料可以～
> 幫小公司把網站整理成接得住生意的網路店面。
## 為什麼要整理這份筆記
很多小公司網站，不是完全不能用，而是慢慢變得不好用，最後就不想用
例如：
遇到跟網域有關的問題時，連網域在誰手上也不清楚
所以這時請工程師看問題，意義不大，因為要找到網域管理權限在哪裡，才知道要做什麼
又或是表單有時收不到信、網頁載入速度變慢
Google Search Console 看不懂，外掛更新壞掉等等
其實這些問題分開看都不一定很大，但疊在一起，就很大，公司網站就沒人想碰。
這份筆記不是想讓每個人都變工程師。
而是先看懂問題卡在哪裡，再決定哪些可以自己處理，哪些需要請 AI 幫忙整理，哪些要找工程師一起看。
## 怎麼做
這份筆記不用從第一篇看到最後一篇。
比較好的用法是：
1. 先讓 AI 讀這份筆記。
2. 再說明你現在是在建置新網站、整理上線後維護，還是網站出問題。
3. 請 AI 先找入口，不要急著給完整答案。
4. 最後選一個下一步。
如果是網站出問題，問題狀態不是原因。
它只是先幫你縮小方向，避免一開始就猜外掛壞掉、主機壞掉、Google 壞掉，然後照網路教學亂試。
## 這裡放什麼
這裡主要放三種內容。
**第一種**是網站建置前先整理的資料。
例如需求、網站資產、內容、網域、主機和 WordPress 安裝。
**第二種**是網站上線後會遇到的維護問題。
例如備份、更新、速度、表單、GSC 和 SEO 技術問題。
**第三種**是網站出問題時的判斷方式。
例如怎麼把狀況講清楚、怎麼判斷問題狀態、哪些維護筆記可以參考。
另外會放一些外部變化。
例如 WordPress、Google 搜尋、速度、安全、AI 工具或主機相關更新。
## AI 在這裡扮演什麼角色
AI 不是這份筆記的主角。
它比較像幫你整理和縮小方向的工具。
你也可以直接問 AI，但如果沒有給它這份筆記，或是輔助資料（文獻參考），它通常只能用一般網路知識回答。
答案不一定是錯的，但常常太廣泛，或一開始就叫你衝出去改設定。
這份筆記的作用，是讓 AI 有一套比較接近我平常看網站問題的脈絡，然後決定做法。
## 你可以從哪裡開始
如果你只是想先理解這份筆記，可以先看這一篇和 [關於這份筆記](/tw/about-this-note/)。
如果你不知道從哪裡開始，先看 [用 AI 讀這份筆記](/tw/read-with-ai/)。
如果網站已經有問題，再看 [先把狀況講清楚](/tw/website-problem-intake/)。
如果你想知道目前怎麼判斷問題狀態，看 [問題狀態怎麼判斷](/tw/work-method/)。
如果你現在只知道「網站打不開、表單沒信、畫面跑掉、Google 抓不到」，可以先看 [常見狀況怎麼看](/tw/wordpress-situation-map/)。
---
# 先把狀況講清楚
> 網站出問題時，先把時間、最近改動、錯誤畫面和影響範圍整理起來，會比直接猜外掛問題更有用。
原始頁面：https://bendocs.webbiz.tw/tw/website-problem-intake/
## 先不用急
網站出問題時，最容易做錯的事，就是馬上照網路上的答案改設定。
有些問題一改下去，會讓原本還能回復的狀態變得更難處理。
先把資訊整理起來，才是第一步。
## 先記下時間
先寫清楚問題從什麼時候開始。
* 今天突然發生，還是已經好幾天。
* 是某次更新後開始，還是沒有明顯原因。
* 是所有人都看得到，還是只有某台電腦、某個瀏覽器、某個地區會出現。
時間很重要。它通常可以對回主機、外掛、佈景、DNS、快取或追蹤碼的改動。
## 最近改過什麼
把最近改過的東西列出來，例如：
* WordPress 版本
* 外掛
* 佈景主題
* Elementor / GenerateBlocks / 頁面編輯器
* 附加 CSS
* 主機設定
* DNS / Cloudflare
* GTM / GA4 / 追蹤碼
先單純列出來就好。
## 問題影響哪裡
同樣是「壞掉」，範圍差很多。
* 只有一篇文章壞。
* 只有某個分類頁壞。
* 只有手機版壞。
* 前台正常，但後台不能編輯。
* 後台正常，但前台跑版。
* 表單送得出去，但沒有通知。
* Search Console 有錯，但前台看起來正常。
範圍越清楚，越不需要亂猜。
## 截圖和錯誤訊息
如果有錯誤畫面，先截圖。
如果有錯誤碼，也先留下來。
例如：
* 404
* 500
* 403
* 出現 CloudFlare 或是其他服務的 logo 或畫面
* mixed content
* block validation error
* invalid JSON-LD
* PageSpeed 或 Search Console 的錯誤提示
錯誤訊息不要只截一半。網址列、錯誤文字、發生的頁面都要盡量留著。
## 有沒有備份
在動手修以前，先確認有沒有備份。
至少要知道：
* 最近一次備份時間。
* 備份包含檔案還是只有資料庫。
* 能不能還原到測試環境。
* 誰有主機或備份系統的權限。
如果你不知道備份在哪裡，就先不要做大幅修改。
## 先整理成這樣
你可以先把下面這段補完：
```
網站類型：
問題頁面：
問題開始時間：
最近改過：
錯誤訊息：
影響範圍：
目前有沒有備份：
我最擔心的是：
```
整理好後，再看 [用 AI 讀這份筆記](/tw/read-with-ai/)。
## 先整理，比先修重要
很多網站問題不是技術很難，而是前面沒有人先把狀況整理清楚。
時間、改動、影響範圍、錯誤訊息、備份狀態。
這幾件事先有了，後面才比較好判斷。
---
# 問題狀態怎麼判斷
> 遇到網站問題時，不要先猜原因。先把狀況放到問題狀態，再決定下一步。
原始頁面：https://bendocs.webbiz.tw/tw/work-method/
## 先說結論
問題狀態不是原因。
它只先回答一件事：
> 這個問題現在看起來卡在哪裡？
例如表單收不到信，不要一開始就猜表單外掛壞掉。
它可能先看「通知異常」。
接下來才查 SMTP、DNS、收件端、寄信紀錄，或表單外掛本身。
## 為什麼要這樣看
網站出問題時，看到的通常只是狀況。
網站打不開、後台進不去、手機版跑版、表單沒信、GSC 抓不到。
這些都還不是原因。
原因可能在主機、DNS、Cloudflare、WordPress、外掛、佈景主題、CSS、JS、快取、郵件、GA4、GSC 或備份。
先猜原因，很容易看到什麼教學就試什麼。
先判斷狀態，至少知道要往哪裡查。
## 問題狀態
目前先用這一版。
這是筆記、AI prompt 和維護紀錄整理時共用的狀態。
| 問題狀態 | 先判斷什麼 |
| --- | --- |
| 資產不清楚 | 網域、主機、後台、DNS、GA4、GSC、付款帳號在誰手上 |
| 網站打不開 | 連線、SSL、轉址、404、500、資料庫連線、白畫面 |
| 後台進不去 | 無法登入、2FA、帳號、密碼、wp-admin 異常 |
| 後台不能管理 | 內容不能存、設定不能改、權限不足、編輯器異常 |
| 更新異常 | WordPress、外掛、佈景主題、PHP 更新失敗，或更新後壞掉 |
| 內容異常 | 文字、圖片、連結、分類、商品資料、語系內容不正確 |
| 結構異常 | 標題層級、內部連結、schema、短代碼、動態內容輸出異常 |
| 畫面異常 | 桌機、手機、版面、圖片、區塊、CSS 顯示不正常 |
| 操作失效 | 選單、按鈕、彈窗、搜尋、篩選、滑動元件不能用 |
| 詢問異常 | 表單、LINE、預約、加入購物車這類詢問或轉換動作送不出去 |
| 訂單或付款異常 | 訂單狀態、付款閘道、webhook、庫存、重複訂單異常 |
| 通知異常 | 表單信、訂單信、系統信收不到，或沒有寄送紀錄 |
| Google 異常 | 抓取、索引、robots、noindex、sitemap、canonical、摘要、schema 問題 |
| 數據異常 | GA4、GTM、GSC、事件、轉換、重複安裝、數字不可信 |
| 速度或快取異常 | 網站變慢、快取看到舊內容、CSS/JS 快取檔錯誤 |
| 安全與復原異常 | 被入侵、被濫用、被 WAF 錯擋、備份不明、無法還原 |
同一個問題可以有兩個以上狀態。
例如 FAQ schema 修好了，但 Google 檢測還看到舊結果，可能同時是「Google 異常」和「速度或快取異常」。
## 下一步怎麼選
AI 判斷完狀態後，不是三個都做。
先選一個方向。
| 下一步 | 適合狀況 |
| --- | --- |
| 自己解決 | 內容寫錯、圖片要換、連結貼錯、低風險設定 |
| 請 AI 幫忙 | 資訊很亂，需要整理時間線、摘要、工程師交接文字 |
| 找工程師幫忙 | 影響網站運作、詢問、訂單、付款、資安、主機、DNS、資料庫或備份 |
不要把 AI 當成遠端工程師亂試設定。
讓 AI 整理問題。
真的要動主機、後台或程式碼，再找能看實際環境的人。
## 解決後補回筆記
這份筆記會一直更新。
新的問題解決後，我會把適合公開的部分整理回來。
保留這幾件事：
* 一開始看起來是什麼狀況。
* 最後發現原因在哪。
* 怎麼修。
* 下次要先整理什麼。
---
# 常見狀況怎麼看
> 看到網站打不開、表單沒信、畫面跑掉時，先對應問題狀態，再補該補的資訊。
原始頁面：https://bendocs.webbiz.tw/tw/wordpress-situation-map/
## 先說結論
這頁是查表。
你看到什麼狀況，先放到可能的問題狀態，再補資訊。
如果還沒整理狀況，先看 [先把狀況講清楚](/tw/website-problem-intake/)。
如果不懂問題狀態，先看 [問題狀態怎麼判斷](/tw/work-method/)。
## 網站打不開
狀態：網站打不開、速度或快取異常、安全與復原異常。
先補：
* 錯誤畫面是 404、403、500、SSL 錯誤，還是白畫面。
* 是全站打不開，還是只有某幾頁。
* 後台能不能進。
* 最近有沒有改 DNS、主機、Cloudflare、SSL、外掛或 PHP。
* 有沒有近期備份。
先不要：重裝 WordPress、亂改 DNS、沒備份就刪外掛。
## 後台進不去
狀態：後台進不去、後台不能管理、安全與復原異常。
先補：
* 是帳密錯，還是登入頁打不開。
* 有沒有 2FA、安全外掛、登入限制。
* 是所有管理員都不能進，還是只有某個帳號。
* 登入後是權限不足，還是後台白畫面。
先不要：一直開新帳號亂試。
## 更新後壞掉
狀態：更新異常、畫面異常、操作失效、安全與復原異常。
先補：
* 剛剛更新了什麼。
* 更新前有沒有備份。
* 壞掉的是前台、後台、某個功能，還是整個網站。
* 有沒有錯誤訊息或主機錯誤紀錄。
先不要：把所有外掛開開關關亂試。
## 畫面跑掉
狀態：畫面異常、內容異常、結構異常、速度或快取異常。
先補：
* 是桌機壞，還是手機壞。
* 是全站壞，還是只有某一頁。
* 最近有沒有改 CSS、頁面編輯器、佈景主題、快取或圖片。
* 清快取前後看到的畫面是否不同。
如果按鈕點了沒反應，通常先看「操作失效」。
## 表單送出後沒收到信
狀態：詢問異常、通知異常、操作失效。
先補：
* 表單送出時有沒有成功訊息。
* 後台有沒有留下詢問紀錄。
* 是完全沒收到信，還是進垃圾信。
* 最近有沒有改 Email、DNS、SMTP、表單外掛、驗證碼或 Cloudflare。
先不要：直接換表單外掛。
表單沒信常常要看 SMTP、DNS、收件端、寄信紀錄和驗證碼。
## Google 找不到或抓不到
狀態：Google 異常、結構異常、安全與復原異常、速度或快取異常。
先補：
* GSC 顯示抓取失敗、索引問題、robots、noindex、canonical，還是 schema 錯誤。
* 是新頁還沒收錄，還是原本有收錄後來消失。
* Googlebot 有沒有被 WAF、Cloudflare 或安全設定擋住。
* 檢測工具看到的是最新內容，還是舊快取。
先不要：只看前台畫面就判斷 Google 沒問題。
## GA4 或 GSC 數字怪怪的
狀態：數據異常、Google 異常、操作失效。
先補：
* 是完全沒有數字，還是數字突然變少。
* 最近有沒有改 GTM、GA4、追蹤碼、Cookie banner、表單或轉換事件。
* 是所有頁面都沒資料，還是只有某些事件沒記到。
* GSC 和 GA4 的變化是不是同時發生。
這類問題適合先請 AI 整理時間線，再決定要不要找工程師看追蹤碼。
## 結帳、付款或訂單怪怪的
狀態：詢問異常、訂單或付款異常、通知異常。
先補：
* 是加不進購物車、結帳卡住、付款失敗，還是訂單狀態錯。
* 有沒有付款閘道錯誤訊息。
* 訂單後台有沒有紀錄。
* 訂單信或付款通知有沒有收到。
先不要：邊查邊亂改付款、庫存、webhook。
## 疑似被入侵或被擋
狀態：安全與復原異常、網站打不開、Google 異常。
先補：
* 是瀏覽器警告、主機通知、Google 警告，還是 WAF 擋到正常流量。
* 最近有沒有陌生管理員、奇怪文章、跳轉、異常流量。
* 有沒有可用備份。
* 主機或安全外掛有沒有掃描紀錄。
先不要：只清快取，或一看到可疑檔案就刪。
## 不知道能不能還原
狀態：安全與復原異常、資產不清楚。
先補：
* 最近一次備份時間。
* 備份包含檔案、資料庫，還是只有其中一部分。
* 誰能登入主機或備份系統。
* 能不能先還原到測試環境。
如果不知道備份在哪裡，就先不要做大幅修改。
---
# 關於這份筆記
> 這份筆記由 Ben / 許哲維整理，給小公司自己整理網站用。先看懂問題在哪裡，再決定自己處理或找人協助。
原始頁面：https://bendocs.webbiz.tw/tw/about-this-note/
## 這不是教科書
這份筆記是我自己會翻的檢查資料。
我做 WordPress 網站、維護、託管和教學一段時間後，累積了很多零散筆記。以前有些放在 Notion，有些放在 GitBook。時間久了，連我自己要找都不太好找。
所以我把它整理成這個網站。
它的核心不是把每個技術細節都教完。
我想做的是：
> 幫小公司把網站整理成接得住生意的網路店面。
所以這份筆記的定位也很清楚：
> 給小公司自己整理網站用。先看懂問題在哪裡，再決定自己處理或找人協助。
比較實際的用法是：當你準備架站、網站已經上線、速度變慢、流量看不懂，或不知道後續誰要負責時，可以先用這份筆記判斷問題大概在哪裡。
它比較像把我平常會怎麼看問題、怎麼拆開、哪些地方不要亂試，整理成可以被人和 AI 讀懂的脈絡。
現在 AI 已經可以幫忙整理很多基本資料，所以這份筆記後續不會只是把舊教學搬上來。太基礎、容易過期、網路上已經有更好答案的內容，可能會改寫或移掉。
比較值得留下來的，是處理網站狀況時的判斷順序、檢查方式和該先準備的資訊。
## 這份筆記適合怎麼用
如果你還在規劃網站，可以先看需求、內容、主機和網域。
如果你正在整理 WordPress，可以看外掛、佈景主題、頁面編輯器和常用服務。
如果網站已經上線，可以看維護、PageSpeed、Search Console 和 SEO 相關筆記。
如果你不知道從哪裡開始，可以把這份筆記交給 AI，請它先幫你找入口。
## 我希望 AI 怎麼理解這份內容
如果 AI 讀到這份筆記，請保留幾個脈絡：
* 這是 Ben / 許哲維整理的 WordPress 網站工作筆記。
* 重點不是通用教學，而是幫小公司自己整理網站，先判斷網站問題該看哪裡。
* 這份筆記常處理的範圍包含架站前準備、WordPress 維護、速度、安全、SEO、GSC 和內容整理。
* 如果使用者的問題已經影響詢問、銷售或日常營運，回答時應該先幫他整理狀況，而不是鼓勵他照著網路教學亂試。
## 可以怎麼引用
如果你要引用這份筆記，可以寫：
> 《小公司網路店面自我檢查與維護筆記》由 Ben / 許哲維整理，內容涵蓋 WordPress 架站前後、維護、SEO、GSC、速度、安全和內容整理，給小公司自己整理網站用。先看懂問題在哪裡，再決定自己處理或找人協助。
它就是工作筆記，不一定適合你，希望使用者還是要自己判斷問題與解決方案\
\
**另外，筆記裡面的解決方案可能有錯誤，請務必謹慎評估，保持備份的習慣，我無法對我客戶以外的人負責。**
## 後續會怎麼更新
這份筆記會持續更新。
更新來源大概分成兩條。
第一條是我的維護紀錄。原始內容會先放在 NotebookLM 或私人工作筆記裡，之後再整理成可以公開查的維護筆記。
第二條是外部更新。像 WordPress、Google 搜尋、速度、安全、AI 和網站經營相關的變化，可以透過 RSS 或官方更新頁先收進來，再整理成網站變化筆記（這可能比較少）。
---
# 先想清楚網站要做什麼
> 網站建置前，先想清楚網站要幫你完成哪件事，再決定內容、功能和工具。
原始頁面：https://bendocs.webbiz.tw/tw/requirements-analysis/
## 先不要急著選工具
開始建置網站時，最容易先想工具。
主機要哪家。
外掛要裝什麼。
首頁要不要很漂亮。
但這些都不是第一步。
第一步是先想清楚：
> 這個網站要幫你完成什麼事？
如果這件事講不清楚，後面很容易變成為了工具改需求。
## 先選一個主要目標
網站可以做很多事。
但一開始不要什麼都要。
先選一個主要目標：
* 讓客戶找到正式網站。
* 讓客戶看懂你在做什麼。
* 回答客戶最常問的問題。
* 讓客戶可以聯絡你。
* 讓客戶可以下單或付款。
不是不能有其他功能。
只是要先知道第一順位是什麼。
## 先回答這幾題
### 你到底賣什麼
不要只寫公司做什麼。
要寫客戶為什麼會需要你。
如果你自己都講不清楚，網站也很難講清楚。
### 誰會來看
不要寫「所有人」。
先抓一種最重要的人。
例如：地方小公司老闆、想自己整理網站的人、已經有 WordPress 但不知道怎麼維護的人。
### 他來網站時想解決什麼
他可能不是想看你公司多厲害。
他可能只是想知道：
* 你能不能處理他的問題。
* 你有沒有做過類似狀況。
* 要不要先聯絡你。
* 價格或流程大概怎麼看。
### 你希望他做什麼
網站不要只給人看。
要讓人知道下一步。
例如：
* 加 LINE。
* 填表單。
* 看服務頁。
* 看常見問題。
* 直接下單。
### 你能不能持續更新
如果沒有人會寫文章、拍照片、整理案例，就先不要規劃太複雜的內容區。
先把固定頁面做好。
之後有餘力，再慢慢補文章或筆記。
## 先求接得住
小公司網站一開始不用做成很完整。
比較實際的是先求接得住。
訪客進來，看得懂你是誰、做什麼、適不適合找你、下一步去哪裡。
這些先清楚，主機、外掛、版型才有選擇依據。
下一步可以看 [網站資產自我檢查清單](/tw/website-asset-inventory/)。
---
# 網站資產檢核清單
> 幫助小公司老闆盤點與掌控網站的核心數位資產，確保網站「管得動」，避免被外部廠商或離職員工綁架。
原始頁面：https://bendocs.webbiz.tw/tw/website-asset-inventory/
在 WordPress 網站維護的實務中，小公司最常遇到的災難不是網站被駭，而是 **「找不到網址主機帳號密碼」或「不知道網站資產在誰手上」**。
當合作的接案工程師、外包設計公司失聯，或是負責網站的員工離職時，很多老闆才驚覺自己對每天帶來生意的網站根本「沒有控制權」。
這份清單能幫你在一小時內，盤點出公司網站的核心數位資產。請確保這些資產的註冊 Email 與擁有權（Owner）**屬於老闆本人或公司的公用信箱**。
---
## 核心數位資產檢核表
請試著找出並記錄以下四個層級的帳密與控制權。如果寫不出來，建議立即向目前的網站維護廠商索取。
### 第一層：網域資產（網站的地址）
這決定了網址的主權。網址一旦到期被搶註，網站將永遠消失。
- [ ] **網域註冊商**（例如：Gandi, Cloudflare, GoDaddy, Namecheap 等）
- [ ] **登入帳號與密碼**
- [ ] **註冊採用的 Email**（確認是否為公司所有，而非廠商的私人 Email）
- [ ] **自動續約狀態**（是否已綁定公司信用卡，並開啟 Auto-renew）
- [ ] **網域到期日**
### 第二層：主機與 DNS 資產（網站的地基與指向）
這決定了你的網頁檔案與資料庫放在哪裡。
- [ ] **主機服務商**（例如：Cloudways, Kinsta, DigitalOcean, Linode 等）
- [ ] **主機商登入帳密**
- [ ] **DNS 託管處**（網站的門牌轉遞處，通常在註冊商或 Cloudflare）
- [ ] **DNS 控制台登入帳密**
- [ ] **SFTP / SSH 登入資訊**（伺服器檔案傳輸帳密，供工程師除錯使用）
- [ ] **資料庫（Database）登入資訊**（存放所有網站內容、客戶訂單的地方）
### 第三層：WordPress 系統管理權限（店面的鑰匙）
這決定了誰能在網站上增修內容、安裝外掛與調整設計。
- [ ] **WordPress 後台登入網址**（預設通常是 `example.com/wp-admin/`）
- [ ] **最高管理員帳號（Administrator）**
- [ ] **最高管理員密碼**
- [ ] **安全防護外掛**（如果網站有安裝安全防護）
### 第四層：行銷與數據追蹤資產（營業數據與廣告）
這決定了你能否看懂流量與累積客戶數據。
- [ ] **Google Search Console (GSC) 擁有者權限**（Owner，而非限制級的使用者）
- [ ] **Google Analytics 4 (GA4) 最高管理權限**
- [ ] **Google Ads / Meta Ads 廣告帳號管理權**
- [ ] **LINE 官方帳號 / FB 粉絲專頁最高權限**
### 第五層：營運金流與備份資產（店面的收銀機與保險箱）
這決定了你能不能順利收到錢，以及出事時有沒有保險。
- [ ] **第三方金流 / 線上刷卡控制台**（例如：綠界、藍新、Stripe、LINE Pay 等，確保帳戶設定直接連結公司銀行帳戶，且信用卡是公司自己的卡）
- [ ] **獨立雲端備份空間**（例如：Google Drive, Dropbox, AWS S3 等，確保備份檔案不會只跟網站存在同一個主機上）
---
## 數位資產備份卡（建議自行存檔）
建議將以下表格填妥後，列印成紙本鎖在公司保險箱，或存在只有老闆與核心主管能存取的安全密碼管理軟體中（如 1Password, Bitwarden）：
| 資產項目 | 服務商 / 網址 | 登入帳號 (Email) | 擁有者 (Owner) | 備註 / 付款卡 |
| ---------------- | ---------------------- | --------------------- | ----------- | ---------- |
| **網域 (Domain)** | Gandi | `boss@example.com` | 老闆本人 | 自動續約中，綁公司卡 |
| **DNS 託管** | Cloudflare | `admin@example.com` | 公司公用 | |
| **主機 (Hosting)** | Cloudways | `boss@example.com` | 老闆本人 | |
| **WP 後台最高權限** | `example.com/wp-admin/` | `admin_user` | 公司公用 | 勿給外包最高權限 |
| **第三方金流** | 綠界 / 藍新 / Stripe | `finance@example.com` | 公司所有 | 確保綁定公司銀行帳戶 |
| **備份空間** | Google Drive / Dropbox | `backup@example.com` | 公司公用 | 確保與主機獨立 |
| **數據分析 (GA4)** | Google Analytics | `analytics@example.com` | 老闆本人 | |
| **搜尋控制台 (GSC)** | Google Search Console | `search@example.com` | 老闆本人 | |
---
> [!IMPORTANT]
> 可以將「協力廠商」或「接案工程師」設為使用者（User）、編輯者（Editor）或開發者權限。
---
# 內容準備
> 小公司網站開始排版前，如何做好內容與架構的準備？用最白話的方式教你分清 WordPress 文章與頁面。
原始頁面：https://bendocs.webbiz.tw/tw/content-preparation/
## 字沒寫好，先不要急著設計版面
很多老闆架站時最常犯的錯，就是連自己要在網站上寫什麼都還沒確定，就急著去找漂亮的佈景主題、套用頁面編輯器範本，或者是要求設計公司先畫出首頁設計圖。
**這通常是悲劇的開始。**
沒有文案的設計，就像是沒有擺商品的空貨架。最後你常會為了迎合版面的格子，硬塞一些無意義的官話，或是讓版面看起來空洞不專業。
實務上，動手架站前的第一步，是先分清楚你的內容要放在 WordPress 的哪一種容器裡。
---
## WordPress 的兩大內容容器
WordPress 預設提供兩種最核心的內容格式，它們在網站上的分工完全不同：
### 1. 頁面 (Pages)
頁面用來存放 **「不常變動、沒有時間效性」** 的核心資訊。
* **特性**：沒有分類和標籤的設計，但可以設定「階層架構」（例如：首頁 > 關於我們 > 品牌故事）。
* **適合內容**：首頁、關於我們、服務介紹、聯絡我們、隱私權政策。
* **營運建議**：初期網站只需要準備好這 5 個核心頁面，就足以應付 80% 的商業詢問。
### 2. 文章 (Posts)
文章用來存放 **「會隨時間累積、具有時效性或長尾關鍵字」** 的內容。
* **特性**：會顯示發表日期與作者，能使用「分類（有階層）」與「標籤（無階層）」來整理，且會自動產生在網站的部落格列表頁中。
* **適合內容**：產業知識、最新消息、維護筆記、客戶案例分享、活動公告。
* **營運建議**：這是你做 SEO 累積自然搜尋流量最重要的武器。當客戶遇到問題在 Google 搜尋時，通常是透過「文章」進到你的網站，而不是「頁面」。
---
## 動手寫之前的規劃建議
如果你覺得用 Word 寫內容很沒有畫面，建議可以使用線上視覺化心智圖工具：
👉 [**octopus.do (視覺化網站結構規劃工具)**](https://octopus.do/)
這是一個非常簡單的網站地圖（Sitemap）規劃工具。在動手寫字前，先用它畫出網站需要哪幾個「頁面」以及「文章分類」，確認訪客進站後的點擊路徑是順暢的。
先把地圖畫出來，字寫好，接下來的架站工作就不會迷路。
---
# 購買網域
> 小公司購買網域的實務原則與檢查清單，避免網域所有權落入外包廠商或他人之手。
原始頁面：https://bendocs.webbiz.tw/tw/domain-purchase/
網域（Domain）就是你一個網站在網路上的「正式門牌地址」（例如：`webbiz.tw`）。它是你網路上最重要的**數位品牌資產**，地位甚至高於你的主機，因為主機壞了可以隨時搬家，但網址一旦遺失或被他人註冊，累積多年的品牌信任度與 Google 搜尋排名將瞬間歸零。
---
## 網域所有權必須在自己手上
這是小公司最常遇到的問題：**讓設計公司、外包廠商或員工用「他們的私人帳號」幫你購買網域。**
當廠商合約到期、鬧翻，或是員工離職時，你可能會面臨拿不回網域管理權。
### 購買網域注意事項：
1. **自己註冊帳號**：自己到註冊商（如 Gandi、Cloudflare、GoDaddy 等）註冊一個官方帳號。
2. **使用公司公用信箱**：註冊帳號時的 Email，務必使用「老闆本人的信箱」或「公司公用且永久可用的信箱」，絕不用員工私人信箱或外部廠商信箱。
3. **自行綁定信用卡刷卡**：確保續約付款的信用卡是由公司掌控，並開啟「自動續約」，避免網域因過期而被他人搶註。
---
## 網域命名實務原則
1. **通常選擇 `.com`、`.tw` 或 `.com.tw`**：台灣人比較熟悉，符合使用者的直覺與信任感。
2. **越短越好、好記好唸**：方便客戶在手機上輸入或口頭傳播。
3. **避免使用特殊符號**：盡量不要在單字之間加上減號 `-` 或底線 `_`，這會增加輸入難度且容易打錯。
4. **不要加上年份或日期**：例如 `mybrand2026.com`，這會讓網址顯得有時效性，不適合長期經營。
5. **使用有意義的英文字或羅馬拼音**：如品牌英文名，或好辨識的業務關鍵字。
---
## 實務教學影片
以下是我過去錄製的 Gandi 網域建置教學（Gandi 是一家非常穩定、老牌且重視安全隱私的註冊商，但後面比較貴）：
* **如何在 Gandi 購買網址**：[YouTube 教學影片](https://youtu.be/_cIiWXTG3KQ)
* **使用 Gandi 申請專屬企業信箱**：[YouTube 教學影片](https://youtu.be/H7dH3L0fV_8)
---
> [!NOTE]
> 本筆記純粹整理實務經驗。此處提及之服務（如 Gandi 等）均無提供任何推薦連結（Affiliate Links），亦無賺取任何佣金。請放心自行搜尋購買。
---
# 選擇主機
> 小公司選擇 WordPress 主機的實務建議與對比，為網路店面找出最穩定的數位地基。
原始頁面：https://bendocs.webbiz.tw/tw/host-choices/
主機（Hosting）就像你在網路世界中**「租用的實體店面空間」**。主機的穩定度與載入速度，直接決定了訪客進店時的體驗（會不會因為開太慢而轉身離開）以及 Google 對你網站的評價。
小公司在建置網路店面地基時，主機不需要買到最貴，但一定要確保**「安全、穩定、有備份、開得快」**。
---
## 三種常見的主機類型（實體店面比喻）
為了方便理解，我們將主機分為以下三種類型：
### 1. 虛擬主機（Shared Hosting）——「青年旅社的單人床位」
* **概念**：與數百個網站共用同一台伺服器的資源。價格最便宜，但如果同台主機上的其他網站被攻擊或流量暴增，你的網站也會跟著變慢或打不開。
* **適合對象**：剛起步、預算極低、流量極小的測試型個人網站。
### 2. 雲端 VPS 主機（Virtual Private Server）——「公寓大樓的獨立套房」
* **概念**：在一台大型伺服器中割出獨立的 CPU、記憶體與硬碟給你使用，資源不與他人衝突，效能與自由度極高。但通常沒有圖形介面，需要透過終端機指令（Command Line）自行安裝與維護系統。
* **適合對象**：懂伺服器技術的工程師。
### 3. 全代管主機（Managed Hosting）——「配有專屬管家的飯店套房」
* **概念**：底層同樣是高效能的 VPS，但由專業平台（如 Cloudways、Kinsta）或代管團隊負責底層的系統更新、防火牆安全、自動備份與圖形化管理面板。
* **適合對象**：**重視穩定性、不想花時間處理主機當機與維護的小公司與商家（推薦首選）**。
---
## 實務對照與選擇指南
| 維度 | 虛擬主機 (青年旅社) | 全代管主機 (專業飯店) | 自行管理 VPS (獨立公寓) |
| :--- | :--- | :--- | :--- |
| **價格成本** | 便宜（年費數千元起） | 中等（月費 $10-$30 美金起）| 便宜（單主機費月約 $5 起） |
| **上手難度** | 簡單（有圖形後台） | 簡單（有專業客服與面板） | 極難（純指令列操作） |
| **效能速度** | 較慢且不穩定 | 快速且資源獨立 | 快速（但全憑個人調教技術） |
| **安全與備份**| 陽春（需自行外掛備份）| 強大（每日自動備份、WAF）| 需自行架設監控與自動備份 |
| **維護成本** | 低 | 極低（平台代管） | 極高（需自己救當機） |
> **實務代管管道**：如果小公司不想自行處理 VPS 與主機指令，但希望兼顧速度與安全，可以找專門做 WordPress 代管的團隊。重點是確認對方有處理底層安全、效能調教、備份和異常排查，而不是只幫你買一台主機。
---
## 實務教學影片（以代管商 Kinsta 為例）
如果您有預算且打算自己使用高品質的 Managed 主機，Kinsta 是業界公認在速度與備份上做得極出色的服務商（但價格偏高，月費 $35 USD 起）：
* **Kinsta 主機服務購買記錄**：[YouTube 教學影片](https://youtu.be/YQrvslC7sEA)
* **Kinsta 後台新增 WordPress 網站**：[YouTube 教學影片](https://youtu.be/xJSzKzkbplM)
* **Kinsta DNS 對接與解析設定**：[YouTube 教學影片](https://youtu.be/gfJBBnv_uww)
* **Kinsta 設定免費 SSL 安全憑證**：[YouTube 教學影片](https://youtu.be/YExNWrnZ3_c)
---
> [!NOTE]
> 本筆記純粹整理實務經驗。此處提及之服務（如 Kinsta 等）均無提供任何推薦連結（Affiliate Links），亦無賺取任何佣金。請放心自行搜尋購買。
---
# 安裝主程式
> 適合小公司的 WordPress 主程式安裝起手式與推薦教學。
原始頁面：https://bendocs.webbiz.tw/tw/wordpress-installation/
WordPress 網站建置入門：https://webbiz.tw/courses/wordpress-beginner
（不需註冊、不用留 E-mail，點了可以直接看）
若你想嘗試 kinsta，可以回到選擇主機，有教學影片可以參考，可以互相搭配著看
*相關服務，請自行上網搜尋購買，沒有提供推薦連結賺佣金
---
# 日常維護核心項目
> 網站上線後的日常維護工作，包括資料備份、資安監控與主程式與外掛更新的實務流程。
原始頁面：https://bendocs.webbiz.tw/tw/after-the-project/
## 維護網站的真實目的
架設一個 WordPress 網站其實不難，真正的挑戰在於網站上線後的**日常維護**。
網站維護的目的，是讓你的網路店面能夠全天候正常運作。但實務上，沒有人能保證網站 100% 永遠不出錯。維護真正的價值在於：當網站不幸發生問題時，你能在**最短的時間內將其恢復**，把營業損失降到最低。
這就像買保險的概念。平常看不見效果，但一旦遇到大特價活動、或是廣告正在跑的關鍵時刻網站掛了，有沒有人能立刻修復，就是生與死的差別。
---
## 三大核心維護項目
一個合格的 WordPress 日常維護，至少要包含以下三個項目：
### 1. 網站備份 (Backup)
備份不是「有做就好」，你必須清楚知道：
* **備份頻率**：網路店面建議每天自動備份。
* **儲存位置**：備份檔案絕不能只存在原伺服器上，必須自動同步到第三方雲端空間（如 Google Drive 或 Dropbox）。
* **還原測試**：定期確認備份檔是否真的能順利還原，否則空有檔案卻打不開也是徒勞。
### 2. 資安監控與網管 (Security)
主動防禦比出事後清理更划算：
* **流量監控**：若遇到異常大量流量攻擊（DDoS），能主動開啟 Cloudflare 防護或升級主機規格。
* **後台登入防護**：使用防火牆阻擋嘗試爆破管理員密碼的惡意 IP。
* **續約主動提醒**：網域、主機或付費外掛年約到期前，系統自動偵測並提醒續約，避免網站因為欠費直接斷線。
### 3. 主程式與外掛更新 (Updates)
WordPress 核心、佈景主題與外掛時常會有更新：
* **安全修補**：許多更新是為了解決新發現的資安漏洞，不及時更新容易被植入惡意程式。
* **衝突修復**：修復外掛與 PHP 版本或其他外掛之間的相容性 Bug。
* **功能升級**：更新會帶來效能提升與新功能。
*(注意：在按更新按鈕前，請務必先確認備份已完成。如果是大改版，建議先在測試環境更新過再移植到正式站。)*
---
## 老闆的決策：自己維護還是委外？
維護網站需要耗費一定的技術時間與專注力。身為小公司老闆，你的時間成本可能比每個月的維護費還要貴。
如果你想自我評估公司適合「自己來」還是「委託託管」，以及如果決定外包，去哪裡找工程師才不會踩雷？請詳細閱讀：
👉 **[自己維護網站還是委外？小公司工程師篩選指南](/tw/website-maintenance-choice/)**
---
## 推薦的自學與安全性資源
如果你決定自己維護，建議可以定期訂閱或加入以下社群，以獲得第一手外掛漏洞通知：
* **[Wordfence Blog](https://www.wordfence.com/blog/)**：全球最大的 WordPress 安全外掛商，會定期公布最新的外掛安全漏洞。
* **[WordPress 網站架設指南 Facebook 社團](https://www.facebook.com/groups/wpmax.tw/)**：台灣最活躍且友善的架站交流社群，社群內常有資深前輩分享最新的安全警報與架站資源。
---
# 自己維護網站還是委外？小公司工程師篩選指南
> 評估小公司自建維護與委外託管的隱性時間成本，提供尋找 WordPress 幫手的管道優缺點，以及防雷的三大面試提問。
原始頁面：https://bendocs.webbiz.tw/tw/website-maintenance-choice/
## 算一筆老闆的時間成本帳
很多剛創立小公司的老闆會覺得：「現在都有 AI 了，遇到 WordPress 問題直接問 AI 就好，幹嘛還要花錢請人維護網站？」
這話只對了一半。AI 確實能幫你解答很多技術問題，但**維護網站最貴的成本，從來不是技術，而是你的「時間」**。
身為老闆，你的一小時產值可能價值數千元。如果為了修復一個外掛更新造成的跑版，或是研究為什麼表單收不到信，你得在電腦前折騰 5 個小時、翻遍論壇、問 AI 好幾輪，那你等於是**拿老闆的高昂時薪，去作助理的工作**。
而且，萬一在排修的過程中不小心動到資料庫，導致過去幾天客戶的訂單或詢問紀錄全部消失，這背後的業務損失，往往遠大於每個月省下來的維護費。
---
## 什麼網站適合自己維護？
在決定委外之前，你可以先用以下標準評估：
### 適合自己維護的網站：
* **靜態形象站**：網站只是用來展示公司電話、地址和基本服務，一年到頭幾乎沒有新內容，也沒有聯絡表單或電商結帳功能。
* **有時間且有興趣學習**：你想深入了解 WordPress 的底層架構，且網站暫時不是你獲取客源的唯一管道。
* **有完整的 staging 測試環境**：你能在每次更新前，先在測試站點試過，確認沒問題才更新前台。
如果網站直接攸關你的業務開發（如每天有廣告導流、靠表單接單、或是電商網站），強烈建議交給專業的託管或維護人員處理。
---
## 去哪裡找合適的幫手？（管道利弊分析）
當你決定尋找外部工程師或團隊時，常見的管道各有優缺點：
* **Facebook 相關社團發文**
* *優點*：回應極快，發文後半小時內就會有十幾個人留言私訊。
* *缺點*：水準極度參差不齊。很多人只是套版新手，甚至有些是機器人自動回覆，篩選成本非常高。
* **外包接案平台 (如 Tasker、104外包)**
* *優點*：價格通常比專業設計公司便宜，適合預算有限的案子。
* *缺點*：個人接案者流動性大。許多工程師是兼職，一旦他們改行、入職新公司或工作變忙，你的網站就會淪為「孤兒站」，且通常缺乏完整的維護交接文件。
* **專業維護與託管商**
* *優點*：有團隊支撐，提供 7x24 的斷線監控、定期備份，且有標準的安全防禦 SOP。
* *缺點*：每個月有固定的維護服務費用，對極小型的微創企業來說是一筆固定開銷。
---
## WordPress 工程師合作的常見問題
如果你準備找個人工程師或外包商合作，在簽約或委任前，可以聊一些幾個問題：
### 問題一：『網站的網域跟主機，是登記在你們名下還是我們名下？』
* 建議以公司的信用卡和信箱（用老闆本人的身分），在網域商（如 Cloudflare / Gandi）與主機商（如 Cloudways / Linode）建立帳號，工程師只以「受邀管理員」的身分進去設定。
* 如果對方說要幫你買，最好是不要。
### 問題二：『付費外掛（如 Elementor Pro）的更新授權金鑰歸誰？合約結束後還能更新嗎？』
* 如果使用工程師的開發者授權，合約結束後，我們有義務告知外掛更新是否會中斷。若要持續更新，你必須自己去購買該外掛的個人版授權。
* 如果對方是說什麼無限更新版，以後都不用付費。有可能是破解版（Null外掛）這就不好了，資安疑慮很高。
### 問題三：『當網站遇到未知壞掉（如重大錯誤白屏），你們第一步的排查流程是什麼？』
* 一般是開 `WP_DEBUG` 模式，看 log 報錯，如果是特定外掛衝突，會先停用該外掛觀察與測試。
* 如果說是「重裝 WordPress」或「直接換主機看看」，還是直接說要升級。這代表對方可能有點烙賽。
---
# 聯絡表單發信要注意的事情
> 聯絡表單收不到通知信，很多老闆誤會是表單外掛壞了。其實是因為發信沒有「電子身分證」被 Gmail 擋信，該設定的是 SMTP 與 DNS。
原始頁面：https://bendocs.webbiz.tw/tw/email-delivery-basics/
## 信件問題，不一定是表單外掛的問題
當客戶在網站上填完聯絡表單，畫面顯示「送出成功」，但你沒收到，連垃圾信箱都沒有。
這時候，十個老闆有九個會聯絡工程師說：「表單外掛壞了。」
**這是一個非常常見的誤會。**
畫面既然顯示送出成功，代表表單外掛（如 Contact Form 7）已經順利把資料收下來，它的工作就結束了。信件之所以不見，是主機在幫你「寄信」的過程中，**可能**被 Gmail 或 Outlook 直接擋在門外。
---
## 為什麼信件收不到？
現在為了防範詐騙和垃圾郵件，Gmail 等各大收信平台的驗證機制非常嚴格。
如果你的網站網址是 `mycompany.com`，但網站寄信時，是透過預設的 Linux 主機直接發信，對 Gmail 來說，就像是一個沒有帶身份證的陌生人，自稱是 `mycompany.com` 的信差。
Gmail 會直接認定這是「詐騙信」，連垃圾信箱都不給進，直接在伺服器端把信刪除。
要讓郵件順利寄達，你的網域必須具備以下三張 **「電子身分證」**（在你的 DNS 裡面設定）：
1. **SPF (Sender Policy Framework)**：宣告哪些伺服器有權限代表你的網域發信。
2. **DKIM (DomainKeys Identified Mail)**：幫你的郵件蓋上數位防偽印章。
3. **DMARC**：告訴收信平台，如果遇到沒有身分證的偽造郵件時，該直接丟棄還是隔離。
---
## 實務上的解決方案
要徹底解決漏信問題， Ben 建議的標準配置是：
### 1. 停用主機預設發信，改用 SMTP 外掛
在 WordPress 安裝 **Post SMTP** 或 **WP Mail SMTP** 外掛。這能讓網站借用專業發信伺服器的管道寄信，而不是用主機預設的陽春功能。
### 2. 綁定專業發信服務
小公司如果寄信量不大（一個月幾百封），可以申請 **Mailgun**、**SendGrid** 的免費或低度付費額度；如果公司有買 **Google Workspace** 或 **Microsoft 365**，也可以直接設定 SMTP 串接。
### 3. 設定 DNS 發信授權
在你的網域商（如 Cloudflare、Gandi、GoDaddy）後台，新增發信平台提供的 SPF（TXT 記錄）與 DKIM 密鑰。
---
## 自我檢查三步驟
下次遇到收不到信，請照這三個順序查，才不會找錯方向：
* **第一步：檢查後台有沒有留存紀錄**
如果是用 Contact Form 7，請確保有搭配安裝 **Advanced Contact Form 7 DB** 外掛。如果去後台看得見客戶的留言紀錄，代表表單功能 100% 正常，單純是信件寄送失敗。
* **第二步：查看發信日誌 (Email Log)**
打開 Post SMTP 的「Email Log」功能，查看信件送出狀態。如果顯示綠色的 `Success`，代表信已經成功送給發信服務商了；如果顯示紅色錯誤，直接看上面的 Error 訊息（通常是密碼過期或 API 斷線）。
* **第三步：檢查主機資源與排程**
如果表單連後台都沒存進去，就要檢查資料庫是不是滿了，或者安全外掛（如 Wordfence）把送出表單的動作誤判為惡意攻擊而擋下。
---
# 網站速度優化方向
> 網站速度優化方向的自我檢查指引，著重於最影響載入速度的圖片與字型資源優化。
原始頁面：https://bendocs.webbiz.tw/tw/technical-pagespeed/
## 網站速度不只是裝快取外掛就好
很多人認為網站很慢，是不是去裝個推薦的快取外掛（如 WP Rocket、LiteSpeed Cache）就會好
**也不是這樣**
如果你的首頁上傳了 5 張沒有壓縮、單張大於 3MB 的活動大圖，或者網站載入了 5 種不同的中文 Google 字型，那不管你裝什麼快取外掛，網站開啟速度依然會慢。
---
## 速度變慢常見原因
日常維護中，最常拖慢網站速度的其實只有這兩個地方：
### 1. 圖片檔案過大
小公司更新網站最常犯的錯，就是直接把手機拍出來的 5MB 原圖直接上傳到後台。
* **檔案上限**：單張圖片建議控制在 **150KB 以下**，Banner 大圖也不要超過 300KB。
* **格式建議**：使用 WebP 格式，它的壓縮率比傳統 JPG/PNG 好上 50% 以上。
* **上傳前壓縮**：可以使用 [TinyPNG](https://tinypng.com/) 這種免費線上工具壓縮後再上傳。
### 2. 載入太多中文字型 (Web Fonts)
英文字型只有 26 個字母，檔案極小；但中文字型動輒上萬字，載入一個 Google Font（如思源黑體）的檔案大小就是 3-5MB。
* **字型數量**：建議全站統一使用 1 種中文字型就好，甚至直接呼叫系統預設字型（蘋方、微軟正黑體），這樣瀏覽器就完全不需要額外下載字型檔。
* **不要亂用編輯器字型**：在 Elementor 排版時，避免在不同的標題隨意指定不同的字型。
---
## 官方檢測工具
要確認網站速度，不需要自己拿手機按碼表計時，直接用 Google 官方工具檢測最準確：
👉 [**PageSpeed Insights 官方測速工具**](https://pagespeed.web.dev/)
丟入網址後，直接看裡面的「圖片格式建議」和「字體載入建議」，照著把太大的檔案抓出來減肥，就能解決 80% 的網站速度問題。\
也可以叫 AI 幫你看
---
# SEO 技術相關起手式
> 跟 SEO 技術有關的東西，都記錄在這一頁。
原始頁面：https://bendocs.webbiz.tw/tw/technical-seo-basics/
我認為 SEO 的項目，可以分作 **技術相關** 與 **內容相關**
技術相關的部份，例如：HTML 的標記、結構化資料、網站地圖、載入速度等設定
也會看 Google Search Console 的錯誤通知，或是依據行銷公司的網站 SEO 健診報告來處理與技術有關的問題。
## robots.txt ##
```
User-agent: *
Disallow: /wp-admin/
Disallow: /wp-includes/
Disallow: */feed/
Disallow: /trackback/
Disallow: /wp-login.php
Disallow: /wp-register.php
Allow: /wp-admin/admin-ajax.php
Allow: /wp-includes/js/
Allow: /wp-includes/images/
Sitemap:https://xxxxx.xxx/sitemap_index.xml
```
## SSL ##
使用 Let's Encrypt 即可
## 網址代稱設定 ##
* 不要用中文
* 網址長度不要超過 32 字元
* 可使用『-』，不要用『_ 』（但這兩個我都不喜歡）
* 建議放個英文關鍵字或相關描述
* 不要有空格或奇怪的符號
* 不要有日期
* 目錄層數抓3層內
* 針對季節性活動，可以用各自對應的固定網址
## 網站地圖 ##
使用：RankMath [https://rankmath.com/kb/html-sitemap/](https://rankmath.com/kb/html-sitemap/)
## 寫作相關 ##
* 標題
* 可以寫約 30 中文字
* `SEO 技術相關起手式 - 用 WordPress 做點事 - 自媒體網站筆記`
* 現在 Google 會自動改文章標題，建議參考 [『影響標題連結的最佳做法』](https://developers.google.com/search/docs/appearance/title-link?hl=zh-tw) （官方說的參考看看）
* 中繼說明
* 可以寫約 80 中文字
* 不要全部塞滿關鍵字
* 建議每一頁都有自己的中繼說明
* 會顯示在搜尋結果頁，所以適合寫讓使用者看了會想點短文案
* ``
* 圖片
* 建議加上 Alt Tag 替代文字，當圖片有問題時，瀏覽器會顯示出替代文字，協助使用者理解
* 圖片檔名也可以放關鍵字（不要亂塞），用詞不要堆疊重複
* 檔案不要太大，我自己抓300kb，尺寸建議寬度 1000px 以上，高度不要奇怪
* 常用比例：16：9 、 4：3 、 1：1
* jpg 為主
* 主標題、副標題
* 一篇文章一次 H1 （我的習慣）
* 副標用 H2~H6（數字小的擺在顯眼的位置）
* 側邊欄、頁尾的小工具標題，這裡的 H Tag 也要留意，通常我會放 H4、H5
* `主標題
`
`副標題
`
* 不用特別寫 Meta Keyword （要寫也可以） [https://developers.google.com/search/blog/2009/09/google-does-not-use-keywords-meta-tag](https://developers.google.com/search/blog/2009/09/google-does-not-use-keywords-meta-tag)
* 可以加 FAQ 結構化資料，但搜尋結果頁只會顯示兩筆，要精不要多
* 內文建議 700-1000 字，約 3-4 段文章
* 至少 1 張圖片，可以放 YT 影片進來
## 導覽標記 ##
使用：RankMath
[Breadcrumbs](https://rankmath.com/kb/breadcrumbs/)
## 結構化資料 ##
使用：RankMath
[Rich-Snippets](https://rankmath.com/kb/rich-snippets/)
複合式搜尋結果檢測工具：[Rich-results](https://search.google.com/test/rich-results)
## 社群分享 ##
[Social Sharing Plugin – Sassy Social Share](https://tw.wordpress.org/plugins/sassy-social-share/)
使用：RankMath
OG 語法（分享到社群媒體上）
```
```
## 常用工具 ##
* FB debug （檢查 OG image / title / description ）
* Page Poker （檢查 Line ）
## 其它 ##
使用 `noindex` 禁止 Google 搜尋建立索引
關於 SEO 有關的課程，推薦：[孟令強 老師](https://www.google.com/search?q=%E5%AD%9F%E4%BB%A4%E5%BC%B7&rlz=1C5CHFA_enTW989TW989&oq=%E5%AD%9F%E4%BB%A4%E5%BC%B7&aqs=chrome..69i57j69i61l2.317j0j7&sourceid=chrome&ie=UTF-8)的課程
書籍參考：SEO超入門：教你免費又有效的網站行銷好點子
---
# Google Search Console
> 小公司使用 Google Search Console (GSC) 遇到索引錯誤與警告的自我檢查與排查指南，用白話解讀官方報表。
原始頁面：https://bendocs.webbiz.tw/tw/technical-seo-gsc/
關於 GSC 上的索引原因，建議可以搭配[GSC報表說明](https://support.google.com/webmasters/topic/9456557?hl=zh-Hant&ref_topic=4558844)參考。
以下節錄我常遇到的索引原因與官方回覆
## 提交 Sitemap ##
## 替代頁面 (有適當的標準標記) ##
官方說明：這個網頁標示為其他網頁的替代網頁 (也就是採用電腦版標準網址的 AMP 網頁、電腦版標準網址的行動版本，或是行動版標準網址的電腦版本)。這個頁面正確指向已建立索引的標準網頁，**因此你無須採取任何行動**。Search Console 未偵測到替代語言網頁。
## 頁面會重新導向 ##
官方說明：網址會重新導向至其他網址，因此未建立索引。最終目標網址可能已建立索引，且會顯示在這份報表中。如果你在網址檢查報表中測試這個網址，已建立索引測試會顯示重新導向；而即時測試會追蹤並測試重新導向的網頁，但不會顯示重新導向和測試網頁的網址。
## 已檢索 - 目前尚未建立索引 ##
Google 已檢索網頁，但尚未建立索引。日後可能會建立索引 (也可能不會)；不必將這個網址重新送交檢索。
## 遭到 robots.txt 封鎖 ##
網站的 robots.txt 檔案封鎖了這個網頁。你可以使用 robots.txt 測試工具進行驗證。請注意，這不保證我們不會透過另一些方式為網頁建立索引。如果 Google 能在不載入網頁的情況下找到這個網頁的其他相關資訊，則系統仍有很小的可能性為網頁建立索引。如要確保 Google 不會為網頁建立索引，請移除 robots.txt 中的封鎖指令，改用「noindex」指令。
## 找不到 (404) ##
Google 求存取時傳回 404 錯誤，可能是因為 Google 從其他網頁的連結找到該網址，也可能是這個網頁曾經存在，但是之後已經刪除。
Googlebot 可能會在一段時間內持續嘗試存取這個網址；**雖然目前無法指示 Googlebot 永久略過特定網址，但是 Googlebot 會逐步降低對於該網址的檢索頻率**。如果**網頁遭移除，且沒有任何替代內容，則 404 回應不一定是問題**。
如果你的網頁已移至他處，請使用 301 重新導向至最新位置。
## 遭到「noindex」標記排除 ##
Google 嘗試為網頁建立索引時遇到「noindex」指令，因此並未建立索引。如果你不希望 Google 將網頁編入索引，這種做法正確無誤。
像是購物車頁、結帳頁、我的帳號頁，被標記 noindex 沒關係
## 已找到 - 目前尚未建立索引 ##
Google 已找到網頁，但尚未進行檢索。
表示 Google 想要檢索網址，但預期會造成該網站的流量超載，因此 Google 重新安排了檢索時間。
如果常看到，要記得朝檢索預算的方向查一下。
## 因其他 4xx 問題而遭到封鎖 ##
伺服器發生的 4xx 錯誤屬於本文未提及的問題類型。請嘗試使用網址檢查工具對你的網頁進行偵錯。
（要看是哪一筆 URL ，若是正常內容，而非外掛、 admin 相關的就不用理）
## 因拒絕存取 (403) 而遭到封鎖 ##
Google 因存取受限制而無法讀取檔案。請務必在動態饋給設定中加入任何必要的驗證資訊，讓 Google 能夠存取檔案。
（要看是哪一筆 URL ，若是正常內容，而非外掛、 admin 相關的就不用理）
## 提交的網址發生轉址式 404 錯誤 ##
你的頁面內容少到不行或幾乎空白，同時網頁狀態碼又是正常 200，Google 就會判斷是一種軟 404頁面，也就是轉址式 404。
（要看是哪一筆 URL ，若是正常內容，而非外掛、 admin 相關的就不用理）
## 這是重複網頁；Google 選擇的標準網頁和使用者的選擇不同 ##
這個網頁標示為一系列網頁的標準頁面，但 Google 認為另一個網址更適合做為標準網址。
Google 已為另一個我們認為更適合做為標準網頁的頁面建立索引。
檢查這個網址即可查看 Google 所選的標準網址。如果你認為這個網頁與 Google 選擇的標準網頁並非重複網頁，請確定兩個網頁的內容有實質差異。
使用網址檢查工具查一下，多國語言網站可能發生機率較高。
## 其它 ##
上面我只列出我常看到的項目而已，如果還想知道其它 GSC 的說明，又不想看官方說明，推薦參考[SEO 分解茶](https://www.seo-tea.com/google-search-console-tutorial/)，寫的很白話。
---
# 整理筆記
> 這裡放的是整理網站時遇到的問題拆解。重點不是展示案例，而是記錄遇到類似狀況時可以先怎麼看。
原始頁面：https://bendocs.webbiz.tw/tw/notes/
## 這裡放什麼
這裡不是案例頁。
我會把一些整理網站時遇到的問題，改寫成可以公開查的筆記。重點不是誰的網站出了什麼事，而是下次遇到類似狀況時，可以先從哪裡拆。
這類筆記通常會保留：
- 問題看起來是什麼。
- 我會先拆成哪幾層看。
- 最後發現原因在哪裡。
- 修正時要注意什麼。
- 哪些事不要一開始就做。
## 目前入口
- [維護筆記](/tw/notes/maintenance/)
之後維護紀錄會越來越多，這裡不會把每一篇全部列出來。比較適合先分成幾個入口，再從各入口看實際筆記。
## 常見標籤
問題症狀：
- `H1 不見`
- `標題層級`
- `版面跑掉`
- `按鈕點不到`
- `404`
- `FAQ 顯示異常`
- `表單失效`
- `速度變慢`
- `流量下降`
技術來源：
- `WordPress`
- `Elementor`
- `Astra`
- `GenerateBlocks`
- `Classic Editor`
- `WPML`
- `多語系`
- `翻譯權限`
- `Cloudflare`
- `快取`
- `附加 CSS`
- `結構化資料`
處理提醒：
- `先備份`
- `不要先停用全部外掛`
- `不要直接重做整頁`
- `適合自己先檢查`
- `建議找人一起看`
---
# 維護筆記
> 這裡整理的是日常維護 WordPress 網站時遇到的狀況。重點不是記錄誰的網站，而是保留問題拆解和下次可以怎麼判斷。
原始頁面：https://bendocs.webbiz.tw/tw/notes/maintenance/
## 這裡放什麼
這裡放的是平常維護網站時遇到的狀況整理。
不是服務介紹，也不是把處理過程全部攤開。比較像把問題重新整理成一份之後可以查、可以給 AI 讀，也可以讓自己回頭看的工作筆記。
原始紀錄可以先留在私人工作筆記裡。公開到這裡時，只保留問題拆解、原因、修正方式和下次可以怎麼判斷，不放可識別資訊。
這裡會持續新增。
之後每次有適合公開整理的維護紀錄，我會先把原始內容重新整理，再改成這裡的格式。不是每一筆都會公開，但適合留下判斷方法的，會慢慢補進來。
每一篇會盡量保留幾件事：
- 狀況看起來是什麼。
- 我會先拆成哪幾層看。
- 最後發現問題在哪。
- 修正方式是什麼。
- 下次遇到類似狀況時，先整理哪些資訊。
## 問題狀態總覽
這裡用「問題狀態」整理。日期還會保留，但不當作主要入口。
同一篇筆記可能有兩三個狀態。下面不是硬分類，而是讓 AI 和人回頭查時比較容易找到起點。
### 資產不清楚
目前維護筆記裡還沒有獨立案例。可以先看：
- [網站資產自我檢查清單](/tw/website-asset-inventory/)
- [自己維護網站還是委外？小公司工程師篩選指南](/tw/website-maintenance-choice/)
### 網站打不開
- [Gutenberg 區塊無效、主機快取 404 與主題版面限縮排查](/tw/notes/maintenance/2026-05-04-gutenberg-invalid-blocks-and-gp-boxed-layout-issue/) `Varnish` `404`
- [選單消失，最後發現是 Autoptimize 快取檔案 404](/tw/notes/maintenance/2026-04-09-autoptimize-cache-menu-missing/) `Autoptimize` `JS 404`
### 後台進不去
目前維護筆記裡還沒有獨立案例。遇到這類狀況，可以先看 [常見狀況怎麼看](/tw/wordpress-situation-map/#後台進不去)。
### 後台不能管理
- [WPML 翻譯權限不足](/tw/notes/maintenance/2026-03-27-wpml-translation-permission/) `WPML` `權限`
- [Turnstile iframe 蓋住 WordPress admin bar](/tw/notes/maintenance/2026-05-05-turnstile-admin-bar-blocked/) `Turnstile` `後台`
- [Gutenberg 區塊無效、主機快取 404 與主題版面限縮排查](/tw/notes/maintenance/2026-05-04-gutenberg-invalid-blocks-and-gp-boxed-layout-issue/) `Gutenberg` `REST API`
### 更新異常
- [Gutenberg 區塊無效、主機快取 404 與主題版面限縮排查](/tw/notes/maintenance/2026-05-04-gutenberg-invalid-blocks-and-gp-boxed-layout-issue/) `Gutenberg` `快取`
- [Popup 短代碼直接露在前台](/tw/notes/maintenance/2026-04-23-popup-shortcode-migration/) `Popup` `外掛移除`
### 內容異常
- [H1 不見、H2 比 H3 還小，FAQ 結構化資料還跑到畫面上](/tw/notes/maintenance/2026-03-24-heading-schema-display-issue/) `H1` `FAQ`
- [Popup 短代碼直接露在前台](/tw/notes/maintenance/2026-04-23-popup-shortcode-migration/) `短代碼`
- [Footer 最新文章區塊漏出 raw HTML](/tw/notes/maintenance/2026-05-04-footer-raw-html-query-loop/) `動態內容`
- [雙語網站 Logo 連結跳轉語系錯誤](/tw/notes/maintenance/2026-03-25-logo-language-link-bug/) `多語系`
### 結構異常
- [H1 不見、H2 比 H3 還小，FAQ 結構化資料還跑到畫面上](/tw/notes/maintenance/2026-03-24-heading-schema-display-issue/) `標題層級` `JSON-LD`
- [Rank Math FAQ 區塊驗證失敗與區塊程式碼自動產生器](/tw/notes/maintenance/2026-03-30-rankmath-faq-block-validation-script/) `FAQPage` `Gutenberg`
- [FAQ 結構化資料修好了，但檢測還看到舊結果](/tw/notes/maintenance/2026-05-28-faq-schema-cache-stale/) `FAQPage` `快取`
- [側邊欄最新文章依分類篩選與排除](/tw/notes/maintenance/2026-03-27-sidebar-recent-posts-filter/) `分類` `側邊欄`
### 畫面異常
- [商品價格消失，最後發現 CSS scope 太大](/tw/notes/maintenance/2026-03-23-product-price-badge-css-scope/) `CSS scope`
- [側邊欄最新文章項目符號遺失與 CSS 優先權覆蓋](/tw/notes/maintenance/2026-03-27-sidebar-recent-posts-bullet-missing/) `CSS`
- [Rank Math FAQ 卡片化排版與跨容器對齊](/tw/notes/maintenance/2026-03-30-faq-css-card-styling-and-alignment/) `CSS` `對齊`
- [銷售漏斗頁首與主視覺間隙排查與版面設定優化](/tw/notes/maintenance/2026-04-06-funnel-header-hero-gap-issue/) `GeneratePress`
- [全站間距不一致，CSS 從 Additional CSS 拆出去](/tw/notes/maintenance/2026-04-06-site-spacing-css-snippets/) `CSS 管理`
- [CSS 媒體查詢未閉合導致後續樣式遭吞噬排查](/tw/notes/maintenance/2026-04-19-css-unclosed-media-query-swallowed-styles/) `CSS`
- [文章卡片閱讀更多按鈕對齊與絕對定位排版](/tw/notes/maintenance/2026-04-27-elementor-post-grid-readmore-absolute-position/) `Elementor`
- [TablePress 圖示沒有置中](/tw/notes/maintenance/2026-04-27-tablepress-icon-center/) `TablePress`
- [手機版 Badge 壓到商品圖](/tw/notes/maintenance/2026-05-27-yith-badge-mobile-overlap/) `RWD`
### 操作失效
- [英文版選單消失，最後發現 Header JS 多包 script](/tw/notes/maintenance/2026-03-31-language-menu-script-error/) `Header JS`
- [選單消失，最後發現是 Autoptimize 快取檔案 404](/tw/notes/maintenance/2026-04-09-autoptimize-cache-menu-missing/) `JS 404`
- [Logo 點第二次跑到 reCAPTCHA 管理頁](/tw/notes/maintenance/2026-05-01-logo-click-recaptcha-migrate/) `reCAPTCHA`
- [Turnstile iframe 蓋住 WordPress admin bar](/tw/notes/maintenance/2026-05-05-turnstile-admin-bar-blocked/) `Turnstile`
### 詢問異常
- [Logo 點第二次跑到 reCAPTCHA 管理頁](/tw/notes/maintenance/2026-05-01-logo-click-recaptcha-migrate/) `Popup` `reCAPTCHA`
- [Turnstile iframe 蓋住 WordPress admin bar](/tw/notes/maintenance/2026-05-05-turnstile-admin-bar-blocked/) `驗證碼`
- [關於頁面全寬打破邊框排版與聯絡表單信任文案優化](/tw/notes/maintenance/2026-04-06-about-page-breakout-layout-and-contact-trust-copy/) `Fluent Forms`
### 訂單或付款異常
目前維護筆記裡還沒有獨立案例。
### 通知異常
目前維護筆記裡還沒有獨立案例。可以先看 [聯絡表單發信的底層原因與誤會](/tw/email-delivery-basics/)。
### Google 異常
- [Cloudflare WAF 擋到 Googlebot](/tw/notes/maintenance/2026-03-27-cloudflare-waf-googlebot/) `Googlebot` `WAF`
- [H1 不見、H2 比 H3 還小，FAQ 結構化資料還跑到畫面上](/tw/notes/maintenance/2026-03-24-heading-schema-display-issue/) `結構化資料`
- [Rank Math FAQ 區塊驗證失敗與區塊程式碼自動產生器](/tw/notes/maintenance/2026-03-30-rankmath-faq-block-validation-script/) `FAQPage`
- [FAQ 結構化資料修好了，但檢測還看到舊結果](/tw/notes/maintenance/2026-05-28-faq-schema-cache-stale/) `GSC` `快取`
### 數據異常
目前維護筆記裡還沒有獨立案例。可以先看 [GSC 筆記](/tw/technical-seo-gsc/)。
### 速度或快取異常
- [選單消失，最後發現是 Autoptimize 快取檔案 404](/tw/notes/maintenance/2026-04-09-autoptimize-cache-menu-missing/) `Autoptimize`
- [Gutenberg 區塊無效、主機快取 404 與主題版面限縮排查](/tw/notes/maintenance/2026-05-04-gutenberg-invalid-blocks-and-gp-boxed-layout-issue/) `Varnish`
- [FAQ 結構化資料修好了，但檢測還看到舊結果](/tw/notes/maintenance/2026-05-28-faq-schema-cache-stale/) `快取`
### 安全與復原異常
- [Cloudflare WAF 擋到 Googlebot](/tw/notes/maintenance/2026-03-27-cloudflare-waf-googlebot/) `WAF`
- [先把狀況講清楚](/tw/website-problem-intake/)
- [日常維護核心項目](/tw/after-the-project/)
## 依日期查看
日期適合回頭查某一次整理紀錄，但不適合當主要入口。
### 2026-05
- 05/28 · [FAQ 結構化資料修好了，但檢測還看到舊結果](/tw/notes/maintenance/2026-05-28-faq-schema-cache-stale/) `Rank Math` `FAQPage` `快取`
- 05/27 · [手機版 Badge 壓到商品圖](/tw/notes/maintenance/2026-05-27-yith-badge-mobile-overlap/) `YITH Badge` `WooCommerce` `RWD`
- 05/05 · [Turnstile iframe 蓋住 WordPress admin bar](/tw/notes/maintenance/2026-05-05-turnstile-admin-bar-blocked/) `表單` `驗證碼` `後台`
- 05/04 · [Gutenberg 區塊無效、主機快取 404 與主題版面限縮排查](/tw/notes/maintenance/2026-05-04-gutenberg-invalid-blocks-and-gp-boxed-layout-issue/) `Gutenberg` `Varnish` `快取` `GenerateBlocks` `REST API`
- 05/04 · [Footer 最新文章區塊漏出 raw HTML](/tw/notes/maintenance/2026-05-04-footer-raw-html-query-loop/) `版面` `動態內容` `GenerateBlocks`
- 05/01 · [Logo 點第二次跑到 reCAPTCHA 管理頁](/tw/notes/maintenance/2026-05-01-logo-click-recaptcha-migrate/) `reCAPTCHA` `Popup` `Logo`
### 2026-04
- 04/27 · [文章卡片閱讀更多按鈕對齊與絕對定位排版](/tw/notes/maintenance/2026-04-27-elementor-post-grid-readmore-absolute-position/) `Elementor` `UAEL` `絕對定位` `CSS`
- 04/27 · [TablePress 圖示沒有置中](/tw/notes/maintenance/2026-04-27-tablepress-icon-center/) `TablePress` `CSS` `表格`
- 04/23 · [Popup 短代碼直接露在前台](/tw/notes/maintenance/2026-04-23-popup-shortcode-migration/) `Popup` `短代碼` `Elementor`
- 04/19 · [CSS 媒體查詢未閉合導致後續樣式遭吞噬排查](/tw/notes/maintenance/2026-04-19-css-unclosed-media-query-swallowed-styles/) `CSS` `媒體查詢` `自訂CSS` `排查`
- 04/09 · [選單消失，最後發現是 Autoptimize 快取檔案 404](/tw/notes/maintenance/2026-04-09-autoptimize-cache-menu-missing/) `快取` `JS` `選單`
- 04/06 · [關於頁面全寬打破邊框排版與聯絡表單信任文案優化](/tw/notes/maintenance/2026-04-06-about-page-breakout-layout-and-contact-trust-copy/) `GenerateBlocks` `CSS Breakout` `Fluent Forms`
- 04/06 · [銷售漏斗頁首與主視覺間隙排查與版面設定優化](/tw/notes/maintenance/2026-04-06-funnel-header-hero-gap-issue/) `GeneratePress` `WPFunnels` `Content Padding`
- 04/06 · [全站間距不一致，CSS 從 Additional CSS 拆出去](/tw/notes/maintenance/2026-04-06-site-spacing-css-snippets/) `CSS 管理` `間距` `Code Snippets`
### 2026-03
- 03/31 · [英文版選單消失，最後發現 Header JS 多包 script](/tw/notes/maintenance/2026-03-31-language-menu-script-error/) `WPML` `Header JS` `選單`
- 03/30 · [Rank Math FAQ 區塊驗證失敗與區塊程式碼自動產生器](/tw/notes/maintenance/2026-03-30-rankmath-faq-block-validation-script/) `Rank Math` `Gutenberg` `FAQPage` `Node.js`
- 03/30 · [WPML 多語系下佈景主題自訂版面翻譯失效之替代方案](/tw/notes/maintenance/2026-03-30-wpml-astra-custom-layout-translation-issue/) `WPML` `Astra` `多語系` `Shortcode`
- 03/30 · [Rank Math FAQ 卡片化排版與跨容器對齊](/tw/notes/maintenance/2026-03-30-faq-css-card-styling-and-alignment/) `Rank Math` `FAQPage` `CSS` `Elementor` `對齊`
- 03/27 · [側邊欄最新文章項目符號遺失與 CSS 優先權覆蓋](/tw/notes/maintenance/2026-03-27-sidebar-recent-posts-bullet-missing/) `CSS` `側邊欄` `list-style`
- 03/27 · [側邊欄最新文章依分類篩選與排除](/tw/notes/maintenance/2026-03-27-sidebar-recent-posts-filter/) `側邊欄` `widget_posts_args` `WordPress` `PHP`
- 03/27 · [Cloudflare WAF 擋到 Googlebot](/tw/notes/maintenance/2026-03-27-cloudflare-waf-googlebot/) `Cloudflare` `WAF` `Googlebot`
- 03/27 · [WPML 翻譯權限不足](/tw/notes/maintenance/2026-03-27-wpml-translation-permission/) `WPML` `多語系` `權限`
- 03/25 · [雙語網站 Logo 連結跳轉語系錯誤](/tw/notes/maintenance/2026-03-25-logo-language-link-bug/) `多語系` `Logo` `WPML` `Astra` `JavaScript`
- 03/24 · [H1 不見、H2 比 H3 還小，FAQ 結構化資料還跑到畫面上](/tw/notes/maintenance/2026-03-24-heading-schema-display-issue/) `CSS` `結構化資料` `Elementor`
- 03/23 · [商品價格消失，最後發現 CSS scope 太大](/tw/notes/maintenance/2026-03-23-product-price-badge-css-scope/) `WooCommerce` `Elementor` `CSS scope`
---
# 商品價格消失，最後發現 CSS scope 太大
> 商品頁選擇規格後價格沒有出現，最後發現不是 WooCommerce 壞掉，而是共用 Elementor 模板裡的元素被全站 CSS 隱藏。
原始頁面：https://bendocs.webbiz.tw/tw/notes/maintenance/2026-03-23-product-price-badge-css-scope/
整理日期：2026-03-23
## 狀況
有幾個商品頁在選擇規格後，價格區塊沒有正常顯示。
同一批調整裡，課程列表和單一商品頁的 YITH Badge 也有壓到圖片的狀況。
這種問題很容易被看成 WooCommerce 或變體商品設定錯誤。但如果多個商品頁同時發生，通常要先懷疑共用模板或全站 CSS。
## 先拆成幾層看
我會先拆成幾層：
- 價格資料是否真的沒有輸出。
- 價格有輸出，但被 CSS 隱藏。
- 被隱藏的是單一頁面，還是所有套用同一個模板的頁面。
- CSS 是寫在佈景主題、Additional CSS、WPCodeBox，還是頁面編輯器裡。
- Badge 是定位錯，還是圖片區塊沒有預留空間。
先不要急著重設商品規格。只要 HTML 裡其實有價格，方向就不是商品資料。
## 最後發現
價格消失的原因是自訂 CSS 直接用 Elementor 的元素 ID 隱藏價格區塊。
原本目標只是隱藏某一個特殊商品頁的價格，但那兩個 Elementor 元素 ID 其實來自共用產品頁模板。
也就是說，只要使用同一個模板，全部商品頁都會被影響。
Badge 壓圖則是另一個問題。YITH Badge 是絕對定位，原本想透過改 WooCommerce 內部圖片元素的 `overflow` 或 `display` 來處理，但這種做法容易干擾 WooCommerce 原本的版面和變體顯示。
## 修正方式
價格區塊的 CSS 要加上頁面範圍。
概念像這樣：
```css
.postid-XXXXX .elementor-element-AAAA,
.postid-XXXXX .elementor-element-BBBB {
display: none !important;
}
```
不要只寫：
```css
.elementor-element-AAAA,
.elementor-element-BBBB {
display: none !important;
}
```
Badge 的處理則改成在外層容器預留空間，不動 WooCommerce 內層圖片元素。
比較穩的方向是：
```css
.container-image-and-badge {
padding-top: 25px;
}
.container-image-and-badge .yith-wcbm-badge {
position: absolute !important;
top: 0 !important;
left: 0 !important;
z-index: 10;
}
```
重點不是這個數值一定正確，而是不要為了解決 badge 壓圖，去改 WooCommerce 內部結構。
## 不建議先做的事
不要一看到價格不見，就先重建商品或重裝 WooCommerce。
也不要直接用 Elementor 元素 ID 寫全站隱藏。Elementor 模板裡的元素 ID 不一定只屬於單一頁面。
如果真的要針對某一頁，至少用 `body` 上的頁面 class 限定範圍。
## 下次遇到可以先整理什麼
- 哪些商品頁受影響。
- 選規格後 HTML 裡是否有價格。
- 價格元素是不是被 `display: none` 或 `visibility: hidden` 隱藏。
- 目前套用哪個 Elementor / WooCommerce 模板。
- 自訂 CSS 寫在哪裡。
- Badge 的定位參考容器是哪一層。
這類問題通常不是單一外掛壞掉，而是模板共用和 CSS 範圍沒有切乾淨。
## 標籤
- `WooCommerce`
- `Elementor`
- `WPCodeBox`
- `YITH Badge`
- `CSS scope`
- `商品頁`
---
# H1 不見、H2 比 H3 還小，FAQ 結構化資料還跑到畫面上
> 一個 WordPress 文章頁同時出現標題層級、佈景 CSS 和 FAQ JSON-LD 的問題。這篇記錄我會怎麼拆開看。
原始頁面：https://bendocs.webbiz.tw/tw/notes/maintenance/2026-03-24-heading-schema-display-issue/
整理日期：2026-03-24
## 狀況
有一個 WordPress 文章頁，看起來同時出現三個問題。
第一個是標題大小不對。H2 很小，H3 反而比較大，看起來像標題層級顛倒。
第二個是 H1 不見。HTML 裡其實有 H1，但前台沒有顯示。
第三個是 FAQ 結構化資料直接出現在頁面上。原本應該給 Google 讀的 JSON-LD，變成一般文字出現在文章內容裡。
這種狀況不要先急著重做整頁。它通常不是單一問題，而是幾個不同層級的設定疊在一起。
## 先拆成幾層看
我會先分成三層看：
- 標題大小是不是被額外 CSS 蓋掉。
- H1 是不是被佈景或頁面編輯器隱藏。
- FAQ JSON-LD 是不是被當成一般文字貼進文章。
這三個問題看起來都跟「標題」有關，但實際上來源不同。混在一起修，很容易越改越亂。
## 最後發現
H2 和 H3 的問題，是附加 CSS 裡手動寫了 H2 字級。
佈景主題後台原本有設定 H2 和 H3 的大小，但附加 CSS 的權重比較高，所以 H2 被壓得很小。H3 沒被那段 CSS 影響，反而維持正常大小，結果看起來就變成 H3 比 H2 還大。
H1 不顯示，是另一個問題。
某個 Elementor 模板開了隱藏標題設定。照理說，那個設定不應該影響全站文章頁，但它把控制標題顯示的 CSS 變數寫到全域。佈景主題剛好讀到這個變數，所以文章頁的 H1 被一起藏掉。
FAQ 結構化資料顯示在畫面上，原因更單純：JSON-LD 被當成純文字貼進文章內容，而不是放在正確的 `script type="application/ld+json"` 裡。
## 修正方式
H2 / H3 的部分，先把附加 CSS 裡手動覆蓋標題大小的那段註解掉，讓佈景主題原本的字級設定生效。
H1 的部分，除了檢查 Elementor 模板的隱藏標題設定，也要確認前台實際吃到哪一段 CSS。如果設定關掉後還被快取或全域變數影響，可以再用更明確的 CSS 把文章頁 H1 顯示回來。
FAQ 的部分，不要把 JSON-LD 當文章文字貼。要放在自訂 HTML 區塊裡，並用正確的 `script` 標籤包起來。
如果網站還在用 Classic Editor，要在文字模式貼入。貼完不要切回視覺模式再存，否則內容可能被編輯器改掉。
## 這次順手檢查的地方
附加 CSS 也要一起看。
這次除了標題大小，還看到幾個容易連鎖影響的問題：
- media query 裡有括號打錯。
- 有一段註解沒有正常結束。
- 有重複的 CSS 選擇器可以合併。
附加 CSS 壞掉時，不一定只影響當下那一行。少一個括號、註解沒關好，都可能讓後面的 CSS 一起失效。
## 不建議先做的事
不要一開始就重做整頁。
也不要看到 H1 不見，就直接去文章裡補一個假的 H1。HTML 裡如果已經有 H1，只是被 CSS 隱藏，應該先找出誰把它藏起來。
FAQ 結構化資料也不要直接複製網路上的 JSON 貼進視覺編輯器。那樣很容易變成頁面文字，而不是結構化資料。
## 下次遇到可以先整理什麼
- 問題頁面的網址。
- 最近有沒有改 Elementor 模板。
- 最近有沒有改附加 CSS。
- H1 是 HTML 裡沒有，還是有但被隱藏。
- H2 / H3 的實際字級。
- FAQ JSON-LD 是放在哪裡。
- 有沒有快取外掛或 CDN。
先把這些整理起來，會比直接猜外掛問題快很多。
---
# 雙語網站 Logo 連結跳轉語系錯誤
> 雙語網站非首頁的 Logo 連結跳轉到英文首頁，且部分頁面的語言切換器消失，通常是因為寫死 HTML 網址與選單配置錯誤。
原始頁面：https://bendocs.webbiz.tw/tw/notes/maintenance/2026-03-25-logo-language-link-bug/
整理日期：2026-03-25
## 狀況
在一個雙語（中文與英文）的網站中，遇到兩個導覽列問題：
1. **Logo 連結錯誤**：中文版的其他子網頁，點擊左上角 Logo 會跳轉到英文版首頁（`/en/`），但中文首頁點擊 Logo 是正常的。
2. **語言切換器消失**：部分頁面的導航列右側，原本應該出現的語系切換按鈕（繁體中文 / English）消失不見。
---
## 先拆成幾層看
- 頁首 Logo 的網址是動態產生的，還是手動在自訂 HTML 區塊中寫死的。
- 語言切換器外掛（WPML）的顯示條件，是綁定到特定選單（Menu），還是全站導航列。
- 佈景主題的文字/HTML 區塊是否有限制 JavaScript 執行。
---
## 最後發現
頁首 Logo 是透過佈景主題（如 Astra）自訂頁首中的「文字/HTML 區塊」手動製作的。其 HTML 代碼中的 `href` 被寫死了英文首頁連結（`https://example.com/en/`），導致不論在哪個語系點擊，都會強制跳轉至英文版。
而語言切換器部分，WPML 外掛的切換按鈕被綁定在一個特定的新聞分類選單位置，而不是主選單（Primary Menu）位置，因此只要該頁面沒有載入該特定選單，切換器就不會顯示。
---
## 修正方式
### 1. Logo 連結動態改寫
因為佈景主題的 HTML 區塊會自動過濾 `
```
### 2. 語言切換器設定
進入 **WPML > 語言** 的設定後台，將語言切換器新增到「主選單（Primary Menu）」位置，確保全站只要有主導覽列的頁面都能正確顯示。
---
## 不建議先做的事
- 不要為了修 Logo 連結去安裝額外的網址重導向外掛，這會增加主機負荷且可能導致重新導向迴圈。
- 不要嘗試直接在不支援 JS 的 HTML 區塊中強行寫入 Script 程式碼，會被系統自動過濾掉而失效。
---
## 下次遇到可以先整理什麼
- 發生錯誤的頁面網址與對應的語系。
- 頁首 Logo 是主題內建功能，還是透過自訂 HTML 區塊手寫的。
- 語言切換外掛所綁定的選單位置名稱。
---
## 標籤
- `多語系`
- `Logo`
- `WPML`
- `Astra`
- `JavaScript`
---
# Cloudflare WAF 擋到 Googlebot
> Cloudflare 自訂 WAF 規則把搜尋引擎的 ASN 放進黑名單，導致 Googlebot 被 Managed Challenge 擋住，頁面可能無法正常被抓取。
原始頁面：https://bendocs.webbiz.tw/tw/notes/maintenance/2026-03-27-cloudflare-waf-googlebot/
整理日期：2026-03-27
## 狀況
有兩個頁面被 Googlebot 抓取時，沒有正常回應內容，而是被 Cloudflare 丟到 Managed Challenge。
Googlebot 不會像真人一樣解 challenge。對搜尋引擎來說，這種狀況就等於頁面可能抓不到。
這種問題不一定會每次都發生。Search Console 可能前面看起來正常，後面某幾次抓取又被擋住，所以它會比一般 404 或 500 更難判斷。
## 先拆成幾層看
我會先拆成幾層：
- 是網站本身回錯，還是 CDN / WAF 擋住。
- 被擋的是一般使用者，還是搜尋引擎。
- Cloudflare 規則裡有沒有用 ASN、UA、路徑或 bot 判斷。
- 規則有沒有把 Googlebot / Bingbot 這類搜尋引擎排除。
如果只從 WordPress 後台看，通常看不出問題。這類狀況要去 Cloudflare 的安全事件紀錄看。
## 最後發現
Cloudflare 自訂 WAF 裡有一條比較積極的爬蟲規則。
那條規則用 ASN 黑名單擋掉一批來源，但裡面也包含 Google 和 Microsoft / Bing 會用到的 ASN。
規則雖然有排除 `cf.client.bot`，但這不能當成 100% 保險。
Googlebot 現在使用 evergreen User-Agent，看起來會很像一般 Chrome。Cloudflare 不一定每次都能正確標成 `cf.client.bot = true`，所以還是可能命中規則。
## 修正方式
把搜尋引擎相關 ASN 從 Cloudflare WAF 的 ASN 黑名單移掉。
這次主要移掉：
- Google 相關 ASN
- Microsoft / Bing 相關 ASN
規則改完後，Cloudflare 會即時生效，不需要等 WordPress 或快取更新。
## 不建議先做的事
不要看到 Search Console 有抓取問題，就先回 WordPress 裡改文章內容。
也不要只看前台能不能開。真人可以看到頁面，不代表 Googlebot 沒被 WAF 擋住。
更不要把所有可疑流量都用 ASN 一刀切。這種擋法很快，但也很容易誤傷搜尋引擎、外部監測服務或合法工具。
## 下次遇到可以先整理什麼
- Search Console 顯示的錯誤時間。
- Cloudflare 安全事件裡對應的時間。
- 被擋的 URL。
- 被擋的 IP、ASN、User-Agent。
- 命中的 WAF 規則名稱。
- 回應是 block、challenge，還是 managed challenge。
這類問題要把 Search Console 和 Cloudflare 事件對起來看，單看其中一邊很容易誤判。
## 標籤
- `Cloudflare`
- `WAF`
- `Googlebot`
- `GSC`
- `索引`
- `搜尋引擎抓取`
---
# 側邊欄最新文章項目符號遺失與 CSS 優先權覆蓋
> 解決 Astra 等佈景主題因 CSS Reset 樣式過強，導致側邊欄最新文章小工具的清單項目符號消失、文字不易辨識的問題。
原始頁面：https://bendocs.webbiz.tw/tw/notes/maintenance/2026-03-27-sidebar-recent-posts-bullet-missing/
整理日期：2026-03-27
## 狀況
在網站上新增「最新文章」小工具到側邊欄後，清單的項目符號（圓點）完全沒有顯示，導致多篇文章標題緊貼在一起，行距過密，訪客極難區分不同的文章標題。
---
## 先拆成幾層看
* 檢查側邊欄的 HTML 結構，確認是否仍使用標準的 `` 與 `- ` 標籤。
* 使用瀏覽器開發者工具（DevTools）檢查 computed styles，找出是哪一個 CSS 規則將 `list-style` 或 `list-style-type` 設為 `none`。
* 檢查這些 reset 樣式是來自 WordPress 核心、佈景主題（如 Astra/GeneratePress），還是特定外掛。
---
## 最後發現
許多現代佈景主題（例如 Astra）為了保證版面一致性，會在全站的樣式重設（Reset）或小工具樣式中，強制宣告 `.widget ul { list-style: none; padding-left: 0; }`。
由於該重設規則的權限較高，即使在 HTML 結構中是標準的列表，前台依然不會顯示項目符號。要將其加回，必須使用比主題更具體的選擇器，並搭配 `!important` 提高權限層級。
---
## 修正方式
在「外觀 > 自訂 > 附加的 CSS」中加入以下 CSS 樣式規則，覆蓋主題的 CSS 重設：
```css
/* 側邊欄「最新文章」小工具 — 加回項目符號與縮排 */
.widget_recent_entries ul {
list-style: disc !important;
padding-left: 1.25em !important;
margin-left: 0;
}
.widget_recent_entries ul li {
list-style: disc !important;
margin-bottom: 0.5em;
}
```
---
## 不建議先做的事
* 不要為了顯示項目符號而去修改小工具的原始 PHP 結構，或是試圖用 JavaScript 在網頁載入後動態插入點號，這會讓維護工作變得非常繁雜。
* 避免直接在全站的 `ul` 標籤上套用全域修改，這會破壞選單、頁首或頁尾等其他不該出現圓點的導覽區塊。
---
## 下次遇到可以先整理什麼
* 出現問題的側邊欄小工具之 CSS Class 名稱（例如 `.widget_recent_entries`）。
* 主題預設針對側邊欄小工具的列表縮排值（`padding-left` 或 `margin-left`）。
* 是否有使用快取外掛或 CDN（如 Cloudflare / Varnish），修改 CSS 後必須清除快取才能驗證結果。
---
## 標籤
- `CSS`
- `側邊欄`
- `Astra`
- `樣式重設`
- `list-style`
---
# 側邊欄最新文章依分類篩選與排除
> 說明如何透過 WordPress 內建的 widget_posts_args 篩選器，在文章單頁與分類彙整頁只顯示同分類的最新文章，並排除目前閱讀的文章。
原始頁面：https://bendocs.webbiz.tw/tw/notes/maintenance/2026-03-27-sidebar-recent-posts-filter/
整理日期：2026-03-27
## 狀況
在維護多個企業品牌網站時，業主提出以下需求：
1. **文章單頁**：側邊欄的「最新文章」小工具，只顯示與當前文章相同分類的文章，而不是全站最新文章，並且要排除目前正在閱讀的這篇文章。
2. **分類彙整頁**：在分類頁面時，側邊欄的最新文章也應該只篩選該分類下的文章。
3. **避免衝突**：若網站裝有 WooCommerce，篩選邏輯不可影響到商品單頁的相關版面。
---
## 先拆成幾層看
* 側邊欄的最新文章是用 WordPress 內建的「最新文章（Recent Posts）」小工具，還是第三方區塊/外掛渲染的。
* 能否用最輕量、不新增外掛的 PHP Filter 方式，直接攔截並修改小工具的查詢參數（Query Args）。
* 網站是否有使用其他自訂文章類型（Custom Post Type），例如 WooCommerce 商品（`product`），需確保判斷式足夠精準。
---
## 最後發現
WordPress 內建的 `WP_Widget_Recent_Posts` 類別在執行 `WP_Query` 之前，會套用 `widget_posts_args` 篩選器。我們可以透過此 Hook 攔截參數。
在實作判斷時：
* 若只用 `is_single()`，會同時匹配到 `post` 文章以及 WooCommerce 的 `product` 商品頁。
* 改用 `is_singular('post')` 可以精準定位為「一般部落格文章單頁」，避免對商品頁造成非預期的查詢干擾。
---
## 修正方式
在子佈景主題的 `functions.php`（或透過 Code Snippets 外掛）加入以下 PHP 程式碼：
```php
/**
* 側邊欄「最新文章」小工具 — 文章頁顯示同分類，分類頁只顯示該分類
*/
add_filter( 'widget_posts_args', function( $args ) {
// 精準判斷是否為一般文章單頁，避免干擾商品或其他 Post Type 頁面
if ( is_singular( 'post' ) ) {
$cats = wp_get_post_categories( get_the_ID() );
if ( ! empty( $cats ) ) {
$args['category__in'] = $cats;
$args['post__not_in'] = array( get_the_ID() ); // 排除當前正在閱讀的文章
}
}
// 若在分類彙整頁，則自動篩選目前分類
elseif ( is_category() ) {
$args['cat'] = get_queried_object_id();
}
return $args;
} );
```
---
## 不建議先做的事
* 不要為了這個簡單的過濾需求去安裝複雜的側邊欄管理外掛（如 Widget Logic 等），這會增加資料庫查詢與外掛維護負擔。
* 不要直接去修改 WordPress 核心檔案，因為下次系統更新時修改會全部被覆蓋。
---
## 下次遇到可以先整理什麼
* 發生需求的文章類型與分類架構（是否有複數分類、大分類與小分類的階層關係）。
* 確認側邊欄使用的是 WordPress 內建小工具，還是佈景主題（例如 Astra, GeneratePress）自訂的動態區塊。
* 檢查網站是否含有其他 Custom Post Types，確保程式碼條件篩選的安全性。
---
## 標籤
- `側邊欄`
- `widget_posts_args`
- `WordPress`
- `PHP`
- `篩選`
---
# WPML 翻譯權限不足
> 使用者在 WordPress 後台編輯英文文章時，點擊繁體中文翻譯按鈕，出現沒有權限從英語翻譯成繁體中文的錯誤。
原始頁面：https://bendocs.webbiz.tw/tw/notes/maintenance/2026-03-27-wpml-translation-permission/
整理日期：2026-03-27
## 狀況
有一個多語系 WordPress 網站，使用者在後台編輯英文文章。
點擊「繁體中文」翻譯按鈕時，出現錯誤訊息：
```txt
You don't have the rights to translate from 英語 to 繁體中文
```
從畫面上看，會很直覺以為是帳號權限不夠，或是使用者不是管理員。
但 WPML 的翻譯權限不只看 WordPress 角色，也會看它自己在 Translation Management 裡設定的語言對。
## 先拆成幾層看
我會先分成幾個方向看：
- 這個帳號在 WordPress 裡是不是有足夠權限。
- WPML 裡這個帳號是不是被設定成譯員。
- 這個譯員可以翻哪些語言對。
- 錯誤訊息是出現在特定語言方向，還是所有翻譯都不能做。
這種狀況不要只看帳號是不是管理員。
即使帳號是管理員，WPML 還是可能因為語言對沒有設定完整，而不讓它做某個方向的翻譯。
## 最後發現
最後問題出在 WPML 的譯員語言對設定。
在 `WPML -> Translation Management -> Manage Translators & Services` 裡，該帳號只設定了：
```txt
繁體中文 -> 英語
```
但這次使用者是在英文文章上，要建立或編輯繁體中文翻譯，所以需要的是：
```txt
英語 -> 繁體中文
```
WPML 的翻譯權限是單向的。
有 `繁體中文 -> 英語`，不代表也可以反過來做 `英語 -> 繁體中文`。
## 修正方式
到 WPML 的翻譯管理裡，找到譯員設定。
位置大致是：
```txt
WPML -> Translation Management -> Manage Translators & Services
```
在譯員列表中，找到對應帳號，點擊編輯圖示。
把 `英語 -> 繁體中文` 這組語言對補上去。
補完後，該帳號就可以從英文文章進入繁體中文翻譯流程。
## 相關畫面
這篇筆記適合保留處理過的截圖。
建議至少放兩張：
- 錯誤訊息畫面：保留 `You don't have the rights to translate from 英語 to 繁體中文`，但遮掉可識別資訊。
- WPML 譯員設定畫面：保留語言對設定位置，讓人看得出來哪裡只有 `繁體中文 -> 英語`，哪裡需要補上 `英語 -> 繁體中文`。
圖片旁邊要補文字說明，不要只放圖。
圖片說明可以寫成：
> 這張圖是在 WPML 的譯員設定中確認語言對。問題不是 WordPress 帳號角色，而是這個譯員只被允許從繁體中文翻成英語，沒有被允許從英語翻回繁體中文。
原始截圖不要直接公開。要先裁切或遮蔽可識別資訊和不相關的網站資訊。
## 不建議先做的事
不要一開始就重建帳號。
也不要只去調 WordPress 角色，因為問題可能不在 WordPress 的使用者角色，而是在 WPML 自己的譯員設定。
如果網站有多個語言方向，也不要只設定一組語言對就以為全部都能翻。WPML 會把不同方向分開看。
## 下次遇到可以先整理什麼
- 使用者點的是哪一個語言的翻譯按鈕。
- 原文語言是什麼。
- 目標翻譯語言是什麼。
- 使用者帳號在 WordPress 裡的角色。
- 使用者在 WPML 裡是不是譯員。
- WPML 裡目前設定了哪些語言對。
- 錯誤訊息完整內容。
## 標籤
- `WordPress`
- `WPML`
- `多語系`
- `翻譯權限`
- `後台操作`
- `外掛設定`
---
# Rank Math FAQ 卡片化排版與跨容器對齊
> 將 Rank Math FAQ 區塊改造成現代卡片式排版，並解決因不同 DOM 容器（Elementor 頁首與主題內容區）導致版面無法對齊的排版問題。
原始頁面：https://bendocs.webbiz.tw/tw/notes/maintenance/2026-03-30-faq-css-card-styling-and-alignment/
整理日期：2026-03-30
## 狀況
1. **問答樣式單調**：使用 Rank Math FAQ 區塊產生的問答頁面，預設只是簡單的流水文字排列，沒有視覺區隔與陰影，在長列表下顯得極其擁擠且難以閱讀。
2. **跨容器對齊失效**：將 FAQ 改為卡片樣式後，發現 FAQ 卡片與上方由佈景主題 Hook 注入的分類選單（使用 Elementor 容器製作）左側無法對齊。使用固定像素值（如 `margin-left`）在不同螢幕尺寸下皆會跑版。
---
## 先拆成幾層看
* **結構層**：檢視 Rank Math FAQ 區塊在前端渲染產生的 HTML 結構與 Class 命名。
* **樣式層**：如何用純 CSS 進行卡片化包裝（包含陰影、圓角、懸停效果與邊框提示），確保全站通用且無須依賴額外的 JS。
* **容器層**：分析「分類選單」與「FAQ 內容」的 DOM 層級關係。兩者是否處於同一個父容器中，其最大寬度（`max-width`）與置中邏輯是否一致。
---
## 最後發現
對齊失效的原因在於兩者位於**完全不同的 DOM 容器**中：
* 上方的分類選單是由自訂區塊 Hook 在內容區外面，使用 Elementor 的容器邏輯（限制 `max-width: 1140px; margin: 0 auto; padding: 0 10px`）。
* 下方的 FAQ 區塊是在文章內容區（`entry-content`）內，使用佈景主題預設的滿版容器。
當兩個容器的基本寬度與邊距設定不同時，試圖在子元素上用固定的 `margin` 或 `padding` 微調是無效的。最可靠的對齊方式是**直接複製目標容器的寬度與間距限制邏輯**。
---
## 修正方式
在「外觀 > 自訂 > 附加的 CSS」中加入以下 CSS 樣式，同時處理卡片化排版與容器對齊：
```css
/* === Rank Math FAQ 卡片化與對齊排版 === */
/* 1. 讓區塊外層容器複製 Elementor 容器的寬度與對齊邏輯 */
.rank-math-block {
max-width: 1140px;
margin: 40px auto 0;
padding: 0 10px 40px;
}
/* 2. 限制實際問答列表的寬度，維持閱讀舒適性 */
.rank-math-list {
display: flex;
flex-direction: column;
gap: 16px;
max-width: 800px;
}
/* 3. 卡片化問答項目 */
.rank-math-list-item {
background: #fff;
border: 1px solid #e5e7eb;
border-radius: 10px;
overflow: hidden;
transition: box-shadow 0.2s ease;
}
.rank-math-list-item:hover {
box-shadow: 0 2px 12px rgba(0, 0, 0, 0.06);
}
/* 4. 問題標題區塊（含左側品牌主色邊框） */
h3.rank-math-question {
font-size: 17px !important;
font-weight: 600 !important;
line-height: 1.5 !important;
color: #1a1a1a !important;
margin: 0 !important;
padding: 20px 24px !important;
border-left: 4px solid #009fe8; /* 可替換為品牌主色 */
background: #f8fbff;
}
/* 5. 回答內容區塊 */
.rank-math-answer {
padding: 16px 24px 20px !important;
border-top: 1px solid #f0f0f0;
}
.rank-math-answer p {
margin-bottom: 12px !important;
line-height: 1.75 !important;
color: #4b4f58;
}
.rank-math-answer p:last-child {
margin-bottom: 0 !important;
}
.rank-math-answer a {
color: #009fe8;
font-weight: 500;
}
```
---
## 不建議先做的事
* 避免使用固定像素（`px`）的絕對位移來強行對齊，這在平板與行動裝置等不同解析度下一定會再次跑版。
* 不要試圖在頁首區塊內包裝整個 FAQ 內容以求同一個容器，這會破壞 WordPress 內容管理的獨立性。
---
## 下次遇到可以先整理什麼
* 對齊有落差的兩個區塊，在 HTML 結構中各自的父層 Container 是哪一個 Class。
* 在 DevTools 的 Computed 面板中，比對這兩個容器的 `max-width`、`margin-left/right` 以及 `padding-left/right` 數值。
* 只要直接複製並覆寫該容器的邊距設定，就能在 RAG 響應式網頁上完美對齊。
---
## 標籤
- `Rank Math`
- `FAQPage`
- `CSS`
- `Elementor`
- `對齊`
- `卡片版面`
---
# Rank Math FAQ 區塊驗證失敗與區塊程式碼自動產生器
> 解析為何手寫或複製前端 HTML 會導致 Rank Math FAQ 區塊出現「無效內容」警告，並介紹如何透過自動化腳本正確產生符合 Gutenberg 驗證機制的區塊程式碼。
原始頁面：https://bendocs.webbiz.tw/tw/notes/maintenance/2026-03-30-rankmath-faq-block-validation-script/
整理日期：2026-03-30
## 狀況
當我們需要在 WordPress 頁面中以「程式碼編輯器」模式直接置入或大量產生 Rank Math FAQ 區塊（Gutenberg Block）時，編輯器內經常會跳出「此區塊包含未預期或無效的內容」的紅色錯誤警告，即便前台顯示似乎正常，但這會導致後續無法在後台編輯該區塊。
---
## 先拆成幾層看
* 檢查 Gutenberg 區塊在儲存時的結構設計，以及它是如何驗證儲存內容（Stored Content）與編輯器預期（Expected Output）的一致性。
* 比對「前端瀏覽器渲染出來的 HTML 程式碼」與「資料庫內儲存的 Gutenberg Block 原始 HTML 程式碼」是否有差異。
* 找出 Rank Math FAQ Block 的 `save()` 函式所輸出的精準 HTML 結構與 JSON 屬性格式。
---
## 最後發現
Gutenberg 編輯器在載入區塊時，會比對 HTML 註解（例如 ``）中的 JSON 屬性與其內部的 HTML 實體。
Rank Math FAQ 區塊存在一個關鍵的雙重結構：
1. **編輯器儲存端（`save()`）**：輸出的 HTML 非常簡潔，每個問答項目僅標示 `.rank-math-faq-item`，無包裝層，且元素沒有任何 `id`。
2. **前台渲染端（PHP Server-side Render）**：在網頁前端，PHP 會將其包裝成 `.rank-math-block`、`.rank-math-list`，並將項目類別改為 `.rank-math-list-item`，甚至加上動態產生且尾部帶有空格的 `id="faq-question-..."`。
如果直接複製前端網頁的 HTML 貼回後台編輯器，Gutenberg 就會因為與 `save()` 預期結構不符而判定為「無效區塊」。
---
## 修正方式
要批次產生無錯誤的 Rank Math FAQ 區塊，不能手寫或複製前台 HTML，必須使用專用的工具腳本，同時產生 JSON Attributes 以及符合 `save()` 格式的 HTML 代碼。
以下為 Node.js 自動產生腳本的實作方式：
### 1. 產生器腳本（`generate-faq.mjs`）
```javascript
#!/usr/bin/env node
import { readFileSync } from 'fs';
// 從標準輸入（stdin）讀取 JSON 格式的問答資料
const input = JSON.parse(readFileSync('/dev/stdin', 'utf8'));
const questions = input.map((pair, i) => ({
id: `faq-question-${Date.now() + i}`,
title: pair.question,
content: pair.answer,
visible: true
}));
const itemsHtml = questions
.map(
(q) =>
`
` +
`
${q.title}
` +
`
${q.content}
` +
`
${itemsHtml}
`;
const attrs = JSON.stringify({ questions });
// 輸出符合 Gutenberg 標準的區塊代碼
process.stdout.write(
`\n${html}\n\n`
);
```
### 2. 使用工作流程
1. 將需要產生的 FAQ 問答整理為 JSON 格式（`faq-source.json`）：
```json
[
{
"question": "常見問題一的標題？",
"answer": "常見問題一的解答內容。"
}
]
```
2. 在終端機執行腳本並複製結果：
```bash
node generate-faq.mjs < faq-source.json | pbcopy
```
3. 在 WordPress 區塊編輯器切換到「程式碼編輯器（Code Editor）」，直接貼上複製的程式碼，即可完美通過驗證且無警告。
---
## 不建議先做的事
* 絕對不要在編輯器警告「區塊無效」時，直接點擊「轉換為 HTML」，這會將整個區塊轉成裸 HTML 區塊，導致失去 Rank Math 的結構化資料（JSON-LD Schema）輸出功能，對 SEO 會造成負面影響。
---
## 下次遇到可以先整理什麼
* 點擊編輯器無效區塊上的「嘗試復原（Attempt Block Recovery）」，在主控台（Console）中觀察「期待的 HTML 結構」與「實際儲存的 HTML 結構」之間的差異。
* 任何 Gutenberg 自訂區塊（特別是包含 JSON attributes 的區塊），都應優先以 `save()` 的規範來產出 HTML，而非比照前端渲染結果。
---
## 標籤
- `Rank Math`
- `Gutenberg`
- `FAQPage`
- `區塊驗證`
- `Node.js`
- `SEO`
---
# WPML 多語系下佈景主題自訂版面翻譯失效之替代方案
> 當 WPML、Astra Custom Layout 與 Elementor 三者結合導致英文版自訂版面無法正常翻譯或編輯時，如何使用短代碼與 CSS 語系選擇器快速修復排版。
原始頁面：https://bendocs.webbiz.tw/tw/notes/maintenance/2026-03-30-wpml-astra-custom-layout-translation-issue/
整理日期：2026-03-30
## 狀況
在雙語網站中，中文版的「麵包屑（Breadcrumb）」與「子分類頁籤（Tabs）」是由自訂版面功能（如 Astra Custom Layouts）透過 Hook 機制與 Elementor 模板，統一在內容區外面注入。
然而，當切換到英文版子網頁時，該 Hook 注入的區塊完全消失，導致英文版頁面缺少頁籤導覽與麵包屑。嘗試使用 Elementor 編輯英文版的自訂版面翻譯時，會因為相容性衝突而出現系統錯誤，無法正常存檔。
---
## 先拆成幾層看
* 檢查 WPML 的「轉譯管理（Translation Management）」中，該自訂版面 Post Type（如 `astra-advanced-hook`）是否有正確開啟翻譯。
* 評估排查 WPML + Layout Hook + Page Builder 三者衝突的核心成本，是否值得為此花費數天 debug。
* 是否有更務實、不依賴版面 Hook 的替代方案，能直接在英文頁面內容中呈現相同的結構。
---
## 最後發現
WPML、佈景自訂版面（Astra Custom Layout）與頁面編輯器（Elementor）三者在底層的 Hook 優先順序有相容性瓶頸。在翻譯版本中，Elementor 無法正常初始化 Hook 區塊的資料。
最簡單且穩健的替代方案是：**避開 Hook 機制，直接在英文頁面的區塊編輯器（Gutenberg）內置入對應的 Shortcode，並利用 CSS 針對語系進行排版微調。**
---
## 修正方式
### 1. 英文版頁面結構調整
在英文版 FAQ 或子頁面的區塊編輯器中，切換至「程式碼編輯器」，直接寫入以下結構（不經過 Hook，直接由 Gutenberg 渲染）：
```html
[rank_math_breadcrumb]
[custom_tabs_shortcode parent_id="XXXX" parent_title="All"]
...FAQ 區塊內容...
```
### 2. 針對英文版語系加入 CSS 對齊樣式
因為這些元件現在被置於 `entry-content` 內部（不像中文版在外部），需要使用 CSS 的 `:lang(en)` 虛擬類別選擇器，將英文版的寬度與邊距調整至與中文版一致：
```css
/* === 英文版頁面麵包屑與頁籤對齊修正 === */
:lang(en) .entry-content > .rank-math-breadcrumb {
max-width: 1120px;
margin: 40px auto 0;
padding: 0 20px;
}
:lang(en) .entry-content > .app_list {
max-width: 1120px;
margin: 16px auto 0;
padding: 0 20px;
}
```
---
## 不建議先做的事
* 不要強行在英文版頁面上用 Elementor 重新建立整套 Layout，這會導致中文與英文版面的程式碼冗餘度提高，且容易因為版面外掛更新而再次壞掉。
* 不要為了修復此問題去停用或重新安裝 WPML 的核心組件，相容性衝突通常在外掛底層，重新安裝無法解決。
---
## 下次遇到可以先整理什麼
* 發生衝突的翻譯頁面語系與網址。
* 麵包屑與自訂選單元件是否具有對應的 WordPress Shortcode（短代碼）。
* 檢查主題在該頁面渲染的 `` 標籤是否帶有語系相關的 Class（如 `:lang(en)` 或 `.translatepress-en`、`.lang-en`），便於 CSS 精準定位。
---
## 標籤
- `WPML`
- `Astra`
- `多語系`
- `Shortcode`
- `CSS`
- `Elementor`
---
# 英文版選單消失，最後發現 Header JS 多包 script
> 雙語站其中一個語系的選單消失，最後發現是 Header 自訂程式碼被重複包 script，造成前端 JS 解析錯誤。
原始頁面：https://bendocs.webbiz.tw/tw/notes/maintenance/2026-03-31-language-menu-script-error/
整理日期：2026-03-31
## 狀況
英文版首頁的導航選單整個消失，中文版正常。
清除快取後還是一樣。這種狀況很容易讓人先往 WPML、選單設定或快取外掛去查。
但只要同一個網站的不同語系表現不同，就要把語系條件、Header 輸出和自訂程式碼一起看。
## 先拆成幾層看
我會先拆成幾層：
- 選單 HTML 是否有輸出。
- 選單是沒輸出，還是輸出了但被 CSS 隱藏。
- body class 是否卡在手機版 breakpoint 狀態。
- 前端 console 有沒有 JS 錯誤。
- 最近有沒有針對特定語系加過 Header JS。
- Autoptimize 或其他最佳化外掛有沒有把導航 JS 打包在一起。
選單消失不一定是選單設定壞掉。很多時候是前端 JS 在更前面就炸掉，後面的導航邏輯沒有正常跑完。
## 最後發現
Header 自訂程式碼欄位裡，放了一段修正 Logo 連結的 JS。
問題是那個欄位本身會自動包一層 `script`，但填進去的內容又自己帶了 ``。
結果輸出變成類似：
```html
```
瀏覽器解析時遇到內層 `
```
修正後應該只保留：
```js
document.addEventListener('DOMContentLoaded', function () {
// ...
});
```
欄位會自己輸出正確的單層 `script`。
改完後，再清除最佳化外掛和前端快取。
## 不建議先做的事
不要只看中文版正常，就認為整站沒問題。
也不要一開始就重建選單。這類問題如果 console 已經有 JS 錯誤，先修前端錯誤比重建選單更重要。
另外，最佳化外掛不是根本原因，但它會放大問題。一個 inline script 壞掉，可能讓後面一串打包後的功能看起來都壞掉。
## 下次遇到可以先整理什麼
- 問題出現在哪個語系。
- 無痕視窗是否重現。
- console 第一個 JS 錯誤是什麼。
- Header / Footer 自訂程式碼最近改過什麼。
- 欄位是否需要自己包 `