持續可發現性廣播器

從網站上線、爬蟲發現到事件驅動式內容廣播應用

文件類型： 概念說明與技術設計文件
版本： v0.1
定位： 網站可發現性基礎設施、搜尋引擎通知系統、AI／知識爬蟲內容變更信標
適用場景： 多網站、多網域、論文庫、產品站、知識節點庫、AI Agent 可讀資料源

摘要

一般網站上線後，並不會主動把內容「廣播」給所有搜尋引擎、爬蟲、資料聚合器或 AI Agent。網站真正完成的，是建立一個可被 DNS 解析、可被 HTTP 存取、可被索引、也可被掃描的公共網路節點。

然而，若網站營運者希望搜尋引擎與各類爬蟲更快知道內容已新增、修改、刪除或重新導向，便可以建立一套「持續可發現性廣播器」。這套系統不是以高頻率重複提交相同網址，而是監測網站中真正發生的內容變化，再將變更事件同步發布到 IndexNow、Sitemap、RSS／Atom、WebSub、自訂 Webhook 與其他機器可讀端點。

因此，本系統的核心不是「不停製造流量」，而是：

將網站中的真實內容變化，轉換成可驗證、可追蹤、可重試、可跨協議傳播的網路事件。

此應用可作為多網站內容基礎設施，集中管理不同網域的索引通知、爬蟲觀測、內容指紋、變更歷史與廣播效能。

第一部分：網站上線與網路可發現性的基本說明

1. 網站上線並不等於向全網廣播

網站上線後，最基本的狀態是：

\text{Website Online} = \text{Resolvable} + \text{Accessible}

其中：

Resolvable：網域可經由 DNS 解析。
Accessible：伺服器可透過 HTTP 或 HTTPS 回應請求。

更完整地說，網站上線後進入了以下四種公共狀態：

O(t) = R(t) + A(t) + I(t) + S(t)

其中：

$R(t)$ ：可解析性，Resolvable。
$A(t)$ ：可訪問性，Accessible。
$I(t)$ ：可索引性，Indexable。
$S(t)$ ：可掃描性，Scannable。

網站並不會自動把所有頁面傳送到全世界，而只是向網路提供一個可被發現與請求的端點。

因此，更精確的描述是：

網站上線不是全網廣播，而是公共可發現性的啟動。

2. DNS 傳播不等於內容廣播

當網域綁定至伺服器、CDN 或 Cloudflare Pages 時，DNS 記錄會逐步被各地解析器取得並快取。

這個過程較接近：

\text{Domain} \rightarrow \text{IP or Service Endpoint}

它告訴網路：

這個網域目前應該指向哪一個服務位置。

DNS 並不負責傳播文章、圖片、產品頁或論文內容，也不會主動通知搜尋引擎網站已發布新頁面。

3. HTTP 是被動回應模型

典型網站採取以下模型：

\text{Client Request} \rightarrow \text{Server Response}

伺服器等待瀏覽器、搜尋引擎、API 客戶端或爬蟲發送請求後，才回傳內容。

若沒有任何請求：

\text{No Request} \Rightarrow \text{No Content Delivery}

因此，即使網站完全公開，也可能在很長一段時間內沒有被特定搜尋引擎或特定爬蟲發現。

4. 爬蟲如何發現網站

搜尋引擎與資料爬蟲通常透過以下方式找到新網站或新頁面：

已知頁面中的超連結。
網站 Sitemap。
RSS 或 Atom Feed。
搜尋引擎站長工具。
IndexNow 類型的 URL 通知協議。
公開 GitHub 儲存庫與部署記錄。
社群媒體、論壇與外部引用。
憑證透明度記錄。
網路掃描、子網域掃描與常見路徑探測。
其他已知爬蟲或聚合器提供的資料。

爬蟲發現網站可形式化為：

P(D_u) = f(L_u,S_u,F_u,N_u,E_u)

其中：

$D_u$ ：網址 $u$ 被發現。
$L_u$ ：外部與內部連結訊號。
$S_u$ ：Sitemap 訊號。
$F_u$ ：Feed 訊號。
$N_u$ ：主動通知訊號。
$E_u$ ：其他外部暴露訊號。

5. 上線後會被合法與非法掃描器共同觀測

網站公開後，可能很快遇到：

搜尋引擎爬蟲。
AI 資料爬蟲。
SEO 分析工具。
網站存檔服務。
弱點掃描器。
登入頁與管理路徑掃描器。
API 端點探測器。
垃圾留言或機器人程式。
自動化漏洞利用工具。

因此：

\text{Public Exposure} \neq \text{Only Desired Crawlers}

網站的可發現性提升，往往也意味著攻擊面與伺服器負載增加。

第二部分：持續宣告與廣播是否可行

6. 可以持續宣告，但不能強迫爬蟲前來

網站可以反覆向不同發現通道宣告內容變化，但無法命令搜尋引擎立即抓取或收錄。

因此真正可以控制的是：

\text{Signal Emission}

而不是：

\text{Crawler Decision}

可將整體關係表示為：

P(\text{Crawler Visit}) = f( \text{Signal Quality}, \text{Site Authority}, \text{Change Frequency}, \text{Server Health}, \text{Crawler Policy} )

應用程式可以提高爬蟲回訪機率與發現速度，但不能保證：

一定被抓取。
一定被收錄。
一定提高排名。
一定進入 AI 訓練資料。
一定被所有爬蟲接受。

7. 「一直廣播」不應等於「高頻重複提交」

錯誤方法是每隔幾分鐘將全部網址重新提交一次。

例如：

B_t = \mathcal{U}

其中 $\mathcal{U}$ 是網站中的全部網址集合。

若每個時間點都重新廣播完整集合，容易造成：

重複通知。
API 配額浪費。
訊號可信度下降。
伺服器與佇列負擔。
搜尋引擎忽略。
被判定為垃圾行為。
難以追蹤真正的內容變更。

正確方法應是：

B_t = \Delta \mathcal{U}_t

其中 $\Delta \mathcal{U}_t$ 表示在時間 $t$ 真正新增、更新、刪除或重新導向的 URL 集合。

8. 事件驅動比定時重複廣播更合理

系統應遵守：

\text{Broadcast} \iff \text{Meaningful Content Change}

而不是：

\text{Broadcast} \iff \text{Timer Triggered}

定時任務仍可存在，但其作用應是：

檢查是否漏掉事件。
重試失敗任務。
更新健康狀態。
重新生成 Sitemap。
檢查失效網址。
低頻重新同步。

第三部分：應用定位

9. 應用名稱建議

可採用以下名稱：

中文

持續可發現性廣播器
持續爬蟲信標
網站內容變更信標
網路發現事件廣播器
內容索引廣播中樞

英文

Continuous Discovery Beacon
Continuous Crawl Beacon
Web Discovery Broadcaster
Content Change Beacon
Indexing Signal Orchestrator

本文件暫定名稱為：

Continuous Discovery Beacon

縮寫：

CDB

10. 核心目標

CDB 的主要目標為：

偵測網站內容的真實變化。
將變化轉換為標準化事件。
向多個協議與平台發布通知。
追蹤每次廣播是否成功。
觀測不同爬蟲何時回訪。
評估不同通知通道的效果。
支援多網站、多網域與多內容類型。
提供第三方 AI Agent 與爬蟲可訂閱的變更資料流。

第四部分：系統總體架構

11. 高階架構

Git Push / CMS Publish / Scheduled Scan / API Update
                         │
                         ▼
                Change Detection Engine
                         │
                         ▼
             URL Normalization & Canonicalization
                         │
                         ▼
                   Event Generator
                         │
                         ▼
                     Event Queue
          ┌──────────────┼───────────────┐
          ▼              ▼               ▼
      IndexNow       Sitemap Engine    RSS / Atom
          │              │               │
          ▼              ▼               ▼
 Search Engines    Search Console      WebSub Hub
          │              │               │
          └──────────────┼───────────────┘
                         ▼
                Crawler Telemetry
                         │
                         ▼
                Analytics Dashboard

12. 系統資料流

完整流程可表示為：

C_t \rightarrow H_t \rightarrow \Delta H_t \rightarrow E_t \rightarrow Q_t \rightarrow B_t \rightarrow T_t

其中：

$C_t$ ：時間 $t$ 的內容狀態。
$H_t$ ：內容雜湊或內容指紋。
$\Delta H_t$ ：與前一版本的差異。
$E_t$ ：生成的內容變更事件。
$Q_t$ ：進入事件佇列。
$B_t$ ：向外部通道廣播。
$T_t$ ：爬蟲回訪與結果遙測。

第五部分：核心技術模組

13. 變更偵測器

變更偵測器負責確認網站是否真的發生內容變化。

可監控的來源包括：

Git commit。
GitHub Actions。
Cloudflare Pages 部署事件。
CMS 發布事件。
Markdown 檔案新增或修改。
資料庫資料列更新。
API 資料更新。
頁面重新導向。
頁面刪除。
標題、摘要、正文與結構化資料變更。

內容指紋

對每個 URL 建立內容雜湊：

H(u,t) = \operatorname{SHA256} \left( C_{u,t} \right)

其中 $C_{u,t}$ 是網址 $u$ 在時間 $t$ 的標準化內容。

若：

H(u,t) \neq H(u,t-1)

則建立更新事件。

標準化內容

在計算雜湊前，應排除不重要的變化：

建置時間。
隨機 ID。
動態廣告。
訪客計數。
Session 值。
每次請求都不同的 nonce。
不影響內容語義的空白與格式差異。

否則每次部署都可能被誤判為內容更新。

14. URL 正規化與 Canonical 管理

同一頁面可能存在多種 URL：

https://example.com/page
https://example.com/page/
https://example.com/page?utm_source=x
http://example.com/page
https://www.example.com/page

系統需將其歸一為 Canonical URL。

可定義：

N(u) = u^\*

其中 $u^\*$ 是 URL $u$ 對應的標準形式。

正規化應包括：

強制 HTTPS。
統一 www 或非 www。
移除追蹤參數。
統一路徑尾斜線。
統一大小寫策略。
排除 Session 參數。
驗證 <link rel="canonical">。
驗證重新導向鏈。

15. 事件生成器

標準事件格式可設計如下：

{
  "event_id": "evt_20260714_000001",
  "site_id": "logic_evemisslab",
  "url": "https://logic.evemisslab.com/paper/example",
  "canonical_url": "https://logic.evemisslab.com/paper/example",
  "event_type": "updated",
  "content_hash": "sha256:abcdef123456",
  "previous_hash": "sha256:987654fedcba",
  "modified_at": "2026-07-14T20:00:00+08:00",
  "priority": 0.82,
  "channels": [
    "indexnow",
    "sitemap",
    "rss",
    "websub"
  ]
}

事件類型

建議至少包含：

created
updated
deleted
redirected
restored
metadata_changed
structured_data_changed

16. 事件佇列

事件佇列負責：

去除重複事件。
合併短時間內多次修改。
延遲發送。
錯誤重試。
指數退避。
優先級排序。
API 頻率限制。
任務狀態追蹤。
失敗事件隔離。

可使用：

Redis。
PostgreSQL。
SQLite，適合初期 MVP。
RabbitMQ。
Kafka，適合大規模。
Cloudflare Queues。
GitHub Actions 配合持久化資料庫。

初期可使用：

SQLite + Python Worker

或：

PostgreSQL + FastAPI + Background Worker

17. 優先級模型

不同頁面不必擁有相同廣播優先級。

可定義：

P_u = \alpha N_u + \beta M_u + \gamma A_u + \delta V_u

其中：

$N_u$ ：新內容權重。
$M_u$ ：修改幅度。
$A_u$ ：頁面重要性。
$V_u$ ：近期訪問或引用價值。
$\alpha,\beta,\gamma,\delta$ ：可調係數。

例如：

新論文首頁：高優先。
產品定價頁：高優先。
拼字修正：低優先。
只修改頁尾年份：不廣播。
大量正文改寫：高優先。

第六部分：廣播通道

18. IndexNow 廣播器

IndexNow 是最接近 URL 即時通知的通道之一。

範例：

POST https://api.indexnow.org/indexnow
Content-Type: application/json

{
  "host": "example.com",
  "key": "YOUR_INDEXNOW_KEY",
  "keyLocation": "https://example.com/YOUR_INDEXNOW_KEY.txt",
  "urlList": [
    "https://example.com/new-page",
    "https://example.com/updated-page"
  ]
}

模組需具備：

API Key 管理。
URL 批次提交。
提交頻率限制。
回應碼記錄。
失敗重試。
刪除 URL 通知。
多網域支援。

19. Sitemap 引擎

系統應自動生成：

/sitemap.xml
/sitemap-index.xml
/sitemap-pages.xml
/sitemap-papers.xml
/sitemap-products.xml
/sitemap-images.xml

每個 Sitemap 應只更新真正發生變化的 <lastmod>。

錯誤做法：

<lastmod>每天都改成今天</lastmod>

正確做法：

<lastmod>內容實際修改時間</lastmod>

Sitemap 本身是提示，不是收錄保證。

20. RSS 與 Atom Feed

對知識網站、論文網站與產品更新站，Feed 是低成本而穩定的發現通道。

建議提供：

/feed.xml
/atom.xml
/papers/feed.xml
/products/feed.xml
/changes/feed.xml

每個項目至少包含：

標題。
Canonical URL。
摘要。
發布時間。
更新時間。
作者。
分類。
唯一識別碼。
內容雜湊，可選。

21. WebSub

WebSub 可讓訂閱者收到 Feed 更新通知。

系統可提供：

Topic:
https://example.com/feed.xml

Hub:
https://hub.example.com/

發布流程：

\text{Content Update} \rightarrow \text{Feed Update} \rightarrow \text{Hub Notification} \rightarrow \text{Subscriber Callback}

這使網站從完全被動的 Pull 模型，轉為：

\text{Push-Pull Hybrid Web}

22. Search Console 與站長平台整合

系統可管理：

Sitemap 提交狀態。
索引覆蓋。
抓取錯誤。
robots.txt 問題。
Canonical 衝突。
行動裝置可用性。
結構化資料錯誤。

但必須區分：

提交 Sitemap。
要求重新檢查特定 URL。
搜尋引擎的最終收錄決策。

系統只能發送訊號，不能取代搜尋引擎的判斷。

23. 自訂 Agent Webhook

可提供第三方 Agent 訂閱服務：

POST /api/subscriptions

範例：

{
  "callback_url": "https://agent.example.com/hooks/content",
  "topics": [
    "papers",
    "products"
  ],
  "events": [
    "created",
    "updated"
  ],
  "secret": "shared-secret"
}

事件發生後：

POST https://agent.example.com/hooks/content

{
  "event_type": "updated",
  "url": "https://example.com/paper/123",
  "modified_at": "2026-07-14T20:00:00+08:00"
}

應使用：

HMAC 簽章。
重放攻擊防護。
Timestamp。
Retry ID。
Event ID。
訂閱取消機制。
速率限制。

第七部分：機器優先發現端點

24. `.well-known` 發現文件

建議提供：

/.well-known/discovery.json

範例：

{
  "site": "EVEMISSLAB",
  "canonical": "https://logic.evemisslab.com/",
  "sitemaps": [
    "https://logic.evemisslab.com/sitemap.xml"
  ],
  "feeds": [
    "https://logic.evemisslab.com/feed.xml"
  ],
  "indexnow": true,
  "change_stream": "https://logic.evemisslab.com/changes.jsonl",
  "webhook_docs": "https://logic.evemisslab.com/docs/webhooks",
  "api": "https://logic.evemisslab.com/api/discovery",
  "updated_at": "2026-07-14T20:00:00+08:00"
}

此端點未必被傳統搜尋引擎直接採用，但可服務：

自有 Agent。
合作平台。
AI 研究爬蟲。
第三方索引器。
未來自訂協議。
網站群內部同步。

25. 變更資料流

提供：

/changes.jsonl

範例：

{"url":"/paper/a","event":"created","time":"2026-07-14T10:00:00Z"}
{"url":"/paper/b","event":"updated","time":"2026-07-14T11:20:00Z"}
{"url":"/paper/c","event":"deleted","time":"2026-07-14T12:00:00Z"}

也可提供：

/api/changes?since=2026-07-14T00:00:00Z

回傳：

{
  "since": "2026-07-14T00:00:00Z",
  "next_cursor": "cursor_abc123",
  "items": [
    {
      "url": "https://example.com/paper/a",
      "event": "created",
      "time": "2026-07-14T10:00:00Z"
    }
  ]
}

第八部分：爬蟲觀測與遙測

26. User-Agent 與 IP 驗證

爬蟲觀測模組可記錄：

User-Agent。
IP。
反向 DNS。
ASN。
存取時間。
請求 URL。
HTTP 狀態碼。
回應時間。
傳輸流量。
robots.txt 存取。
Sitemap 存取。
距離上次廣播的時間。

但不能只依賴 User-Agent，因為它可以被偽造。

可建立可信度函數：

C_c = w_1 U_c + w_2 D_c + w_3 I_c + w_4 B_c

其中：

$U_c$ ：User-Agent 一致性。
$D_c$ ：DNS 驗證。
$I_c$ ：IP 範圍可信度。
$B_c$ ：行為模式一致性。

27. 廣播到爬取的延遲

可計算特定網站 $i$ 與爬蟲 $c$ 的平均回訪時間：

\tau_{i,c} = \frac{1}{n} \sum_{k=1}^{n} \left( t_{crawl,k} - t_{broadcast,k} \right)

其中：

$t_{broadcast,k}$ ：第 $k$ 次廣播時間。
$t_{crawl,k}$ ：廣播後首次爬取時間。

此數據可用來判斷：

哪個通道最有效。
哪種內容最容易被回訪。
哪個網域爬取速度較慢。
是否需要調整 Sitemap 或內部連結。
是否存在伺服器阻擋或 robots.txt 問題。

28. 儀表板欄位

建議顯示：

欄位	說明
網站	網域或站點名稱
URL	被廣播的頁面
事件	created、updated、deleted
最後廣播時間	最近一次送出訊號時間
IndexNow 狀態	成功、失敗、等待
Sitemap 狀態	已寫入、未寫入
Feed 狀態	已更新、未更新
首次爬取時間	廣播後第一次被訪問
爬蟲名稱	Googlebot、Bingbot、CCBot 等
回訪延遲	廣播至爬取的時間
HTTP 狀態	200、301、404、500
重試次數	外部通知失敗次數

第九部分：安全與濫用防護

29. 不應建立爬蟲陷阱

為吸引爬蟲而建立近乎無限 URL 的做法不可取。

例如：

/page?id=1
/page?id=2
/page?id=3
...

若 URL 空間持續膨脹：

|\mathcal{U}| \rightarrow \infty

可能造成：

Crawl budget 浪費。
重複內容。
Canonical 混亂。
搜尋品質下降。
伺服器負載暴增。
被視為垃圾網站。
資料庫與日誌膨脹。

30. 廣播頻率限制

每個通道都應設定：

每分鐘上限。
每小時上限。
每日上限。
單次批次大小。
單網域限制。
失敗退避時間。

重試時間可採指數退避：

T_n = \min \left( T_{\max}, T_0 \cdot 2^n \right)

其中：

$T_0$ ：初始等待時間。
$n$ ：失敗次數。
$T_{\max}$ ：最大等待時間。

31. Webhook 安全

對外 Webhook 必須包含：

HTTPS。
HMAC。
Timestamp。
Nonce。
Event ID。
重放檢查。
回應逾時。
重試上限。
訂閱驗證。
秘鑰輪替。

簽章可表示為：

S = \operatorname{HMAC}_{K} \left( T \Vert B \right)

其中：

$K$ ：共享密鑰。
$T$ ：時間戳。
$B$ ：請求內容。
$S$ ：簽章。

32. 防止內部網址洩漏

廣播器只能提交公開網址。

應排除：

localhost
127.0.0.1
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
staging.example.com
internal.example.com
admin.example.com

系統應建立網域白名單：

allowed_hosts:
  - example.com
  - www.example.com
  - logic.example.com

第十部分：MVP 技術方案

33. 建議技術堆疊

後端

Python 3.12
FastAPI
SQLAlchemy
SQLite or PostgreSQL
httpx
Pydantic
APScheduler or Celery

前端

Astro
React
Tailwind CSS
Chart.js or ECharts

部署

Docker
Cloudflare
GitHub Actions
Railway / Render / Fly.io / VPS

監控

OpenTelemetry
Prometheus
Grafana
Sentry

34. MVP 目錄結構

continuous-discovery-beacon/
├── app/
│   ├── main.py
│   ├── config.py
│   ├── models.py
│   ├── database.py
│   ├── api/
│   │   ├── events.py
│   │   ├── sites.py
│   │   ├── subscriptions.py
│   │   └── telemetry.py
│   ├── services/
│   │   ├── change_detector.py
│   │   ├── url_normalizer.py
│   │   ├── event_builder.py
│   │   ├── dispatcher.py
│   │   └── crawler_detector.py
│   ├── adapters/
│   │   ├── indexnow.py
│   │   ├── sitemap.py
│   │   ├── rss.py
│   │   ├── websub.py
│   │   └── webhook.py
│   └── workers/
│       ├── broadcast_worker.py
│       └── retry_worker.py
├── migrations/
├── tests/
├── scripts/
├── docker-compose.yml
├── pyproject.toml
├── .env.example
└── README.md

35. MVP 資料表

sites

CREATE TABLE sites (
    id TEXT PRIMARY KEY,
    name TEXT NOT NULL,
    base_url TEXT NOT NULL UNIQUE,
    enabled INTEGER NOT NULL DEFAULT 1,
    created_at TEXT NOT NULL
);

pages

CREATE TABLE pages (
    id TEXT PRIMARY KEY,
    site_id TEXT NOT NULL,
    url TEXT NOT NULL UNIQUE,
    canonical_url TEXT NOT NULL,
    content_hash TEXT,
    previous_hash TEXT,
    last_modified TEXT,
    last_seen TEXT,
    status_code INTEGER,
    FOREIGN KEY(site_id) REFERENCES sites(id)
);

events

CREATE TABLE events (
    id TEXT PRIMARY KEY,
    site_id TEXT NOT NULL,
    page_id TEXT NOT NULL,
    event_type TEXT NOT NULL,
    priority REAL NOT NULL DEFAULT 0.5,
    payload TEXT NOT NULL,
    created_at TEXT NOT NULL,
    processed_at TEXT,
    status TEXT NOT NULL DEFAULT 'pending',
    FOREIGN KEY(site_id) REFERENCES sites(id),
    FOREIGN KEY(page_id) REFERENCES pages(id)
);

deliveries

CREATE TABLE deliveries (
    id TEXT PRIMARY KEY,
    event_id TEXT NOT NULL,
    channel TEXT NOT NULL,
    status TEXT NOT NULL,
    attempts INTEGER NOT NULL DEFAULT 0,
    response_code INTEGER,
    response_body TEXT,
    next_retry_at TEXT,
    delivered_at TEXT,
    FOREIGN KEY(event_id) REFERENCES events(id)
);

crawler_visits

CREATE TABLE crawler_visits (
    id TEXT PRIMARY KEY,
    site_id TEXT NOT NULL,
    url TEXT NOT NULL,
    user_agent TEXT,
    ip_address TEXT,
    crawler_name TEXT,
    confidence REAL,
    visited_at TEXT NOT NULL,
    response_code INTEGER,
    latency_ms INTEGER,
    FOREIGN KEY(site_id) REFERENCES sites(id)
);

第十一部分：API 設計

36. 建立內容變更事件

POST /api/v1/events

{
  "site_id": "logic_evemisslab",
  "url": "https://logic.evemisslab.com/paper/example",
  "event_type": "updated",
  "modified_at": "2026-07-14T20:00:00+08:00",
  "content_hash": "sha256:abcdef",
  "priority": 0.8
}

37. 查詢事件狀態

GET /api/v1/events/{event_id}

{
  "event_id": "evt_20260714_000001",
  "status": "completed",
  "deliveries": [
    {
      "channel": "indexnow",
      "status": "success"
    },
    {
      "channel": "sitemap",
      "status": "success"
    },
    {
      "channel": "websub",
      "status": "success"
    }
  ]
}

38. GitHub Actions 串接

name: Notify Discovery Beacon

on:
  push:
    branches:
      - main

jobs:
  notify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Collect changed files
        id: changes
        run: |
          git diff --name-only HEAD^ HEAD > changed_files.txt

      - name: Notify beacon
        run: |
          curl -X POST "${{ secrets.BEACON_URL }}/api/v1/deployments" \
            -H "Authorization: Bearer ${{ secrets.BEACON_TOKEN }}" \
            -H "Content-Type: application/json" \
            -d '{
              "site_id": "logic_evemisslab",
              "commit_sha": "${{ github.sha }}"
            }'

實際版本應將檔案變更列表與 URL 對應後再送出。

第十二部分：多網站中央化設計

39. 中央服務

可建立：

beacon.evemisslab.com

統一管理：

evemiss.com
evemisslab.com
logic.evemisslab.com
agiright.org
eveglyph-editor.com
emlphosphor.com
thisoneisneok.com

每個站點部署完成後：

GitHub Actions
      │
      ▼
POST beacon.evemisslab.com/api/v1/deployments
      │
      ├── 偵測變更 URL
      ├── 更新 Sitemap
      ├── 發送 IndexNow
      ├── 更新 RSS / Atom
      ├── 發送 WebSub
      ├── 通知 Agent Webhook
      └── 紀錄爬蟲回訪

40. 多租戶模型

即使目前只有單一公司使用，也可預留多租戶設計：

Organization
   └── Sites
        └── Pages
             └── Events
                  └── Deliveries

資料關係：

\mathcal{O} \supset \mathcal{S} \supset \mathcal{P} \supset \mathcal{E} \supset \mathcal{D}

其中：

$\mathcal{O}$ ：組織集合。
$\mathcal{S}$ ：網站集合。
$\mathcal{P}$ ：頁面集合。
$\mathcal{E}$ ：事件集合。
$\mathcal{D}$ ：廣播交付集合。

第十三部分：自適應廣播

41. 通道效能評估

每個廣播通道可建立效能分數：

S_c = \lambda_1 R_c - \lambda_2 L_c - \lambda_3 F_c

其中：

$R_c$ ：廣播後成功回訪率。
$L_c$ ：平均回訪延遲。
$F_c$ ：失敗率。
$\lambda_1,\lambda_2,\lambda_3$ ：權重。

系統可依網站與內容類型，自動選擇最有效的通道組合。

42. 自適應策略

例如：

新論文：IndexNow、Sitemap、RSS、WebSub。
小幅拼字修改：只更新 Sitemap。
產品價格變化：IndexNow、Webhook、Feed。
刪除頁面：IndexNow、Sitemap、Redirect 檢查。
重大首頁更新：所有通道。
只修改 CSS：不廣播。

策略函數可寫為：

\Pi(e,u,s) \rightarrow \mathcal{C}

其中：

$e$ ：事件類型。
$u$ ：頁面特徵。
$s$ ：網站狀態。
$\mathcal{C}$ ：應採用的通道集合。

第十四部分：開發階段

43. 第一階段：單站 MVP

功能：

一個網站。
手動提交 URL。
IndexNow。
Sitemap 生成。
SQLite。
廣播日誌。
基本儀表板。

44. 第二階段：自動變更偵測

功能：

GitHub Webhook。
Git commit 差異分析。
URL 對應。
內容雜湊。
事件去重。
失敗重試。
RSS／Atom。

45. 第三階段：多網站中樞

功能：

多網域。
多 API Key。
統一站點設定。
權限控制。
多站儀表板。
WebSub。
自訂 Webhook。

46. 第四階段：爬蟲遙測與分析

功能：

Log ingestion。
爬蟲辨識。
DNS 與 IP 驗證。
回訪延遲。
通道效能評估。
異常流量警報。
Crawl budget 分析。

47. 第五階段：公開平台化

功能：

第三方網站接入。
API 計費。
免費與付費方案。
Agent 訂閱市場。
內容變更事件流。
跨網站知識索引。
開放協議與 SDK。

第十五部分：限制

48. 系統不能保證的事情

此系統不能保證：

搜尋引擎立即爬取。
搜尋引擎立即收錄。
頁面獲得高排名。
AI 公司採用網站資料。
Common Crawl 一定收錄。
每個爬蟲都遵守 robots.txt。
所有 User-Agent 都是真實身份。
廣播越多效果越好。

49. 系統真正能改善的事情

此系統可以改善：

新頁面被發現的速度。
Sitemap 與 Feed 的一致性。
多網站索引通知管理。
URL 變更記錄。
刪除與重新導向通知。
廣播錯誤的追蹤與重試。
爬蟲回訪時間分析。
AI Agent 與知識平台接入能力。
網站內容生命週期的可觀測性。

結論

網站上線本身只是讓網站進入公共網路的可解析、可存取、可掃描與可索引狀態，並不等於網站會主動向所有搜尋引擎與爬蟲廣播。

真正可行的技術方向，不是製造大量重複請求，也不是建立無限頁面吸引爬蟲，而是設計一個事件驅動的「持續可發現性廣播器」：

\text{Content Change} \rightarrow \text{Structured Event} \rightarrow \text{Multi-Channel Broadcast} \rightarrow \text{Crawler Observation} \rightarrow \text{Adaptive Optimization}

這個應用的本質，是把網站從單純等待訪問的被動節點，提升為能夠持續發布內容變更訊號的主動式知識節點。

其最合理的設計原則是：

不為了廣播而製造變化，只廣播真正存在的變化。

最終，Continuous Discovery Beacon 可以成為一套跨網站、跨搜尋引擎、跨 AI Agent、跨知識平台的內容變更基礎設施，使網站中的每一次新增、修改、刪除與重組，都能被轉換為可驗證、可追蹤、可重試與可擴充的網路事件。

持續可發現性廣播器_概念與技術設計_v0.1