用 ACF 模板與大量發布，在 WordPress 做 Programmatic SEO 的實戰流程

一個服務要做 20 個城市頁面，還能手工寫完。換成 200 個城市加 30 種服務呢？多數團隊不是卡在產能，就是卡在一致性，最後變成一堆長得像、內容又薄的頁面。

programmatic SEO WordPress 的重點，其實不是「一次生很多頁」。真正的價值是把「可變的資料」和「固定的版型」拆開，先把規格定好，再用資料驅動產出。你可以用 ACF 做欄位模型，用模板渲染出一致的內容結構，最後用 WP-CLI 或 CSV 匯入把頁面批次發布，並且在 2026 的搜尋環境下，仍然保持品質和可索引性。

想先了解概念脈絡，可以參考這篇對 WordPress programmatic 做法的整理：Programmatic Seo WordPress – Web Dignify。

先把資料模型做好：ACF 欄位群組與模板設計

做大量頁面時，最常見的失敗點是「欄位不夠乾淨」。一旦欄位設計混亂，後面匯入再快都只是把混亂放大。所以第一個決策是：你要用 Page 還是自訂文章類型(CPT)？

多數情境我建議用 CPT，例如 service_location，因為你可以獨立設定 URL 規則、權限、欄位群組，查詢也更好控。接著用 ACF 建一個欄位群組，先滿足 80% 可重用內容，剩下 20% 留給「少量手工補強」。

下面是一個可直接套用的 ACF 欄位群組範例(含欄位 key，方便之後用 WP-CLI 寫入)。key 是示意，實作時以你站內產生的為準。

模板渲染時，第二個關鍵是「安全輸出」。大量頁面一旦資料來源混雜，沒做 escaping 很容易留下風險。以下是常用片段，刻意用短行呈現，方便你貼進 single-service_location.php 或區塊模板中：

• 文字欄位：echo esc_html( (string) get_field('service_name') );
• 可含少量格式的欄位：echo wp_kses_post( (string) get_field('service_intro') );
• 連結：echo esc_url( (string) get_field('cta_url') );
• 電話(避免奇怪字元)：$phone = preg_replace('/[^0-9+]/', '', (string) get_field('contact_phone'));
• 電話連結：echo esc_url( 'tel:' . $phone );

如果你打算用 WP-CLI 寫入 ACF 欄位，務必理解 ACF 的欄位 key 和 meta 儲存方式，官方這篇講得很清楚：How to add WordPress Post Meta Programmatically。

URL 與站內結構：讓大量頁面變成可爬、可理解、可轉換

大量頁面能不能排名，常常不是輸在內容，而是輸在「結構讓 Google 看不懂」。你需要先定一個穩定的 URL 策略，並且保證每一頁都有合理的內鏈入口。

Slug 策略與產生規則

在中文市場，slug 用中文會變成編碼字串，看起來雜亂，也不利於一致性。我更常用「資料表提供英文 slug」的方式，至少兩欄：

• city_slug，例如 taipei
• service_slug，例如 aircon-cleaning

然後把 URL 定成 /services/{city_slug}/{service_slug}/。好處是可讀、可擴充，之後做城市總覽頁也很順。

如果你在匯入時要自己組合 slug，原則很簡單：同一套資料永遠產生同一個結果。WordPress 端可用 sanitize_title() 做最後清理，避免空白和特殊符號。

內鏈與麵包屑自動化

別把 programmatic 頁面當孤島。每一頁至少要連回兩個地方：城市總覽頁、服務總覽頁。做法可以很樸素：

• 城市總覽頁放「該城市所有服務」清單
• 服務總覽頁放「該服務所有城市」清單
• 內容區塊放 3 到 6 個「鄰近城市」或「相近服務」連結

麵包屑建議交給 SEO 外掛處理，然後讓外掛能讀到 ACF 的內容。若你用 Yoast，這個外掛能讓 ACF 欄位也進入分析與可讀性檢查：ACF Content Analysis for Yoast SEO。

SEO 防線：避免薄內容與重複頁

規模越大，越要先訂「不發布」規則。把門檻寫進流程，比事後補救便宜很多。

下面是一個可操作的防線表，你可以把它變成匯入前的資料驗證，或匯入後的 noindex 判斷。

結構化資料方面，最實用的是三種：FAQPage(對應 FAQ repeater)、Service(對應服務頁)、LocalBusiness(如果你有實體據點)。原則是「只標你頁面真的有的資訊」，例如電話、地址、服務範圍、價格區間。

大量產生與發布：WP-CLI 批次、CSV 匯入，以及效能與節奏

當模型和模板定好，發布方式就剩兩條路：工程化批次(WP-CLI)，或偏無程式的 CSV 匯入。

方法一：WP-CLI 批次建立，再寫入 ACF meta

先用草稿跑一批 20 到 50 頁，確認模板、內鏈、索引設定都正常，再擴大。常見指令會長這樣(概念示例，實際請替換你的 post type)：

• 建立草稿：wp post create --post_type=service_location --post_status=draft --post_title="台北 冷氣清洗" --post_name="taipei-aircon-cleaning"
• 寫入欄位值：wp post meta update 123 service_name "冷氣清洗"
• 寫入欄位 key：wp post meta update 123 _service_name "field_65f0a1b2c3d4e"

ACF 之所以需要同時寫「值」和「_欄位名對應 key」，是為了讓後台正確識別欄位。這也是前面強調 field key 要先固定的原因。

批次時記得控制節奏。你可以每批 50 到 200 篇，批次之間清快取，並且避免尖峰時段執行。

方法二：CSV 匯入(偏無程式)，先產草稿再審核

如果你的 CSV 主要是文章內容，先把頁面批次變成草稿最省時間。這類工具可以直接把 CSV 每一列變成一篇草稿，方便你抽查格式和品質，例如：Articla Lite Bulk Publisher。

若你同時要把資料對應到 ACF 欄位，通常會再搭配支援自訂欄位 mapping 的匯入器。流程上仍建議先草稿，抽查無誤再發布。

效能注意事項：別讓大量頁面拖垮站點

大量頁面最容易踩到三個坑：查詢太多、快取沒打中、一次寫入太大。你可以用幾個簡單規則降低風險：

• 模板取值時，盡量一次取整包欄位，例如用 get_fields()，避免同頁呼叫太多次。
• 列表頁不要對每篇文章跑複雜 meta query，先用分類或 taxonomy 做初步分流。
• 分批匯入時，控制 batch size，並在每批之間讓快取與資料庫喘口氣。

上線前與上線後清單

上線前，建議你至少完成這些檢查：

1. 抽查 20 頁，確認 H1、內文段落、FAQ、CTA 都有值
2. 檢查 canonical、noindex 規則是否符合門檻
3. 城市總覽頁與服務總覽頁都有連到 programmatic 頁
4. 站內搜尋或篩選不產生大量可索引參數頁

上線後，請把觀測當成流程的一部分：

1. 追索引與收錄，先看表現好的模式再擴大
2. 針對低品質頁，直接合併、canonical 或 noindex
3. 每週抽查 10 頁，確認資料沒跑版、連結沒失效

如果你想把模板、欄位、批次發布一路做成可維護的流程，並且有人能長期協助更新與監控，WPTOOLBEAR 的做法是把規格先定死，再用固定流程交付與維運(包含 AI 文章站與網站維護方案)：WPTOOLBEAR。

結語：把大量內容做成「可管理的產品」

大量頁面不是炫技，它更像工廠生產線。你先決定材料(資料)、模具(ACF 模板)、品管標準(SEO 防線)，最後才是出貨(批次發布)。當流程穩定後，你會發現擴張不再是壓力，而是一個可預期的產出節奏。真正能長期贏的，是把每一批頁面都維持在 可索引、可閱讀、可轉換 的水準。