不知道制度存在，就無法搜尋。真正缺的不是「制度倉庫」，而是把制度送到人面前的配送網
1. 五秒結論：很多時候，搜尋根本還沒開始
地方政府提供住房、收入下降、育兒、照護、住宅修繕、災害援助等服務，其中一些對生活與家計很有價值。但一個人第一次聽到實用制度時，常見反應卻是：「原來還有這個？」知道之後，才會打開官方頁面、看條件、找申請方式。
這表示問題未必是「沒有價值所以不用」，而是很多人從未進入搜尋階段。
讓網頁更容易被搜尋引擎找到，也就是SEO，只能在搜尋詞已經出現後發揮作用。如果一個人完全想不到政府可能有這項制度，他就沒有制度名稱可以輸入Google。
搜尋框不會讀心。
更深層的問題是制度發現設計：公共服務應從居民熟悉的生活事件靠近，而不是先要求居民學會行政術語。
2. 「不知道，所以沒搜尋」本身就是一道高牆
要求一個人搜尋從未聽過的福利正式名稱，就像遊戲剛開始便要求玩家在攻略裡輸入隱藏Boss的名字。
人通常想的是：
- 我失業了
- 收入下降了
- 房租很吃力
- 我搬家了
- 我結婚了
- 孩子出生了
- 父母開始需要照護
- 房子需要修繕
- 遇到災害
行政為了管理，需要制度名、主管單位、法規與對象分類；居民則以生活事件理解問題。兩套結構沒有橋樑時，「請到官網搜尋」也不會自動產生正確搜尋詞。
3. 把整條流程畫出來，就知道人掉在哪裡
| 階段 | 使用者必須做什麼 | 常見故障 |
|---|---|---|
| 1 | 遇到問題或生活事件 | 還沒聯想到公部門支援 |
| 2 | 想到「也許有支援」 | 根本不知道制度可能存在 |
| 3 | 形成搜尋詞 | 生活用語與行政術語不同 |
| 4 | 到達官方資訊 | 標題、結構、導覽可能較弱 |
| 5 | 判斷自己是否可能符合 | 收入、年齡、家庭、期限複雜 |
| 6 | 申請 | 文件、身分確認、表單、窗口、期限造成摩擦 |
| 7 | 完成或續辦 | 忘記或中途放棄 |
SEO主要影響第3、4階段。停在第2階段的人，連SEO這場比賽都沒進場。
4. 資料也顯示：主動尋找地方政府服務並非預設行為
大阪府在2025年7月對1,000名成年居民進行網路調查。對於是否會透過公報或網站查詢市町村預算、事業與行政服務，33.6%回答「完全不會」，31.1%回答「不太會」，合計64.7%。常用資訊來源包括公報54.4%、官方網站38.9%、社群媒體10.0%。[R1]
大阪府也明確提醒，這是民間網路調查樣本，不能視為全體府民的完整縮影。因此64.7%不能直接推廣到全日本，但它至少說明主動搜尋不是理所當然。
另一項針對日本全國20至60多歲446人的民間Web調查顯示，57.8%從未在自治體主動通知之外自行搜尋行政服務；有搜尋的人中84.6%使用Web。17.3%表示曾因不知道服務存在而錯過服務。[R2]
Web對已經開始找的人很強。薄弱的是讓「不找的人」開始發現。
5. 行政語言與生活語言沒有對齊
行政需要制度名、主管單位、法規與資格分類；居民需要回答「房租付不起」「剛搬家」「孩子出生」這些問題。
民間調查中也出現網站雜亂、資訊難找、不確定自己是否符合、對象說明不清、行政用語難懂、無法一次找齊國家、都道府縣與市區町村制度等不滿。[R2]
解法不是把重要資訊刪掉，而是把入口改成生活語言。
不要先問正式制度名稱，而是先問「收入下降後，房租是否變得困難？」制度名可在使用者認出自己的情境後再出現。
6. 那麼自治體網站SEO真的很差嗎？部分正確，但不是全部
公共網站結構確實有改善空間。A.A.O.在2026年的第19次自治體網站品質調查，從無障礙與網站品質角度分析公開頁面。[R12]
但它不是Google排名調查，不能把它改寫成「自治體網站根本搜不到」。
Google建議每個頁面使用簡潔且具描述性的標題，並讓主要標題清楚。[R10] 這些基礎不足，確實可能讓搜尋結果較難理解與發現，所以SEO仍值得改善。
「政府愛用PDF，所以Google看不到」也不對。Google明確列出PDF為可建立索引的檔案格式。[R11] PDF可能在手機閱讀、導覽與更新上體驗不佳，但PDF不等於搜尋隱形。
7. 知道制度後還有第二道牆：申請負擔
OECD在2024年整理的主要利用障礙包括：資訊不足或過於複雜、申請麻煩、污名或心理社會負擔、預期利益太小。[R5] 報告引用的27國27,000人調查中，51%認為申請公共福利會困難且耗時。[R5]
所以至少有兩個斷崖：「不知道」和「知道，但申請很痛苦」。只修發現機制，卻把申請留成最終Boss，仍然會大量流失。
8. 實驗顯示：資訊有效，資訊加申請協助更強，但通知不是萬靈丹
美國一項SNAP隨機實驗把約3萬名可能符合資格但尚未加入的高齡者分為對照組、只提供資訊組、資訊加申請協助組。9個月後的加入率分別為6%、11%、18%。[R6]
但把通知寫得更漂亮並不能解決所有問題。EITC的6項預先登錄大型實驗、合計100萬次觀測，改變訊息內容、設計、發送者與傳遞方式後，仍未找到提高報稅或抵免領取的證據。[R7]
另一項約6.5萬名SNAP申請人的實驗則發現，更彈性的面談流程讓核准率提高6個百分點。[R8]
重點不是一則聰明通知，而是把發現、資格判斷與申請視為同一條流程來減少摩擦。
9. 日本的「申請主義」也會放大配送差距
荒見玲子對日本疫情支援的研究指出，以申請為起點的行政實務與難以掌握目標群體，會讓需要支援的人更難進入制度；有人會放棄申請，使政策實際觸及的人群進一步縮小。[R9]
很多制度當然需要本人意願、證明與個別條件確認。問題在於，如果整個系統都假設居民能先發現制度、找到主管機關、讀懂規則，再在期限內完成申請，資訊搜尋能力就會變成隱藏資格。
10. 解法：把制度名稱從入口拿掉
最初只問少量資訊：居住自治體、年齡層、大致家庭型態、居住狀況、最近發生的生活事件。
事件用日常語言：失業、收入下降、搬家、結婚、懷孕或生產、就學、照護、住宅改造、災害。
結果頁不要只列制度名，而要顯示可能相關程度、可能符合的理由、支援內容與上限、期限、所需文件、是否可線上申請、官方更新日與官方申請入口。
這樣使用者終於可以退出「請輸入你不知道的制度精確名稱」這款遊戲。
11. 再進一步：由生活事件觸發，只推送高相關制度
不要叫居民每天巡邏制度資料庫，而是在搬家、失業、收入下降、結婚、生產、升學、照護、住宅改造、災害等時點提示相關制度。
也不要推送所有政府公告，否則通知欄很快就變成公報墓地。
只送高度相關的變化：新出現的可能適用制度、快到期的制度、重要資格條件變化。
理想路徑是：生活事件 → 候選制度 → 幾個問題確認可能資格 → 文件 → 申請 → 截止提醒。
12. SEO仍然重要，只是要換入口詞
不要只抓知道正式制度名的人。入口可以是「失業後沒錢怎麼辦」「搬家補助」「單身租屋補助」「結婚搬家補助」「住宅改造補貼」「照顧父母有哪些支援」等生活問題。
SEO的工作，是把已經存在的生活問題搜尋轉成公共服務發現。
13. 從文章網站變成「行政服務推薦引擎」
Amazon會說「你可能也想要這個」，YouTube會推薦下一支影片。公共服務卻不能停在「請自行巡迴全國政府網站和PDF，找出你符合的制度」。這個難度設定確實奇怪。
制度倉庫已經很多，缺的是配送層。
文章可以成為入口，但不該是終點。回答一個問題後，系統可以提示「按照這些條件，還有三項制度可能有關」。內容網站因此變成制度發現引擎。
14. 日本已經開始建設必要的零件
數位廳的「育兒支援制度登錄庫」把國家與地方政府的育兒制度資訊集中、結構化，使民間App能在適當時機推送相關資訊。面向App業者的API串接於2025年11月開始，育兒App「ぴよログ」於2026年1月開始串接，2026年度後還計畫擴大制度範圍。[R3]
數位廳的使用者觀點行政服務指南也承認，過去偏提供者觀點的政府IT曾讓居民與企業覺得比民間服務更難用、更難懂，並使部分服務的使用量、滿意度與政策成果不足。[R4]
截至2026年9月，MyNaPortal API可在本人同意下，讓外部服務取得稅收與所得、家庭、育兒等行政個人資訊類別。[R13][R14] 電子申請API也支援地方政府育兒、搬家等手續。[R15]
未來可形成 經同意的屬性與事件 → 制度比對 → 可能資格 → 預先填寫 → 申請。但API使用需要申請、審查、協調與連線測試，並非任意開放。[R14]
15. 安全邊界：推薦引擎不能隨便斷言資格
官方確認前應標示「可能符合／需要確認」，並提供官方來源、更新日、適用地區與期限。必須追蹤規則變更，不能只靠舊文章判定。個人資料按步驟最小化收集；行政資料串接要清楚說明目的與同意範圍；電話、窗口與真人協助仍要保留。通知最佳化看相關性與期限，不看數量。
自動化不是把人趕出公共服務，而是讓機器負責容易的尋找，把真人協助留給複雜個案。OECD也強調，數位化需要搭配人工支援，以照顧難以使用電子流程的人。[R5]
16. 結論：比SEO不足更深的是「制度發現設計」不足
如果把地方政府服務不為人知全都歸因於SEO差，就會漏掉在第一次搜尋之前已經消失的人。
更好的路徑是：「問題發生 → 相關制度出現 → 回答幾個問題估算資格 → 進入申請」。SEO仍是重要入口，但不應成為找到幫助之前的隱藏考試。
即使不知道自己不知道什麼，也應該遇得到相關支援。
「公布制度」和「把制度送達」不是同一件事。
公共服務下一場競爭，不只是搜尋排名，而是配送。
