# 持續可發現性廣播器
## 從網站上線、爬蟲發現到事件驅動式內容廣播應用
**文件類型：** 概念說明與技術設計文件
**版本：** 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. 爬蟲如何發現網站
搜尋引擎與資料爬蟲通常透過以下方式找到新網站或新頁面：
1. 已知頁面中的超連結。
2. 網站 Sitemap。
3. RSS 或 Atom Feed。
4. 搜尋引擎站長工具。
5. IndexNow 類型的 URL 通知協議。
6. 公開 GitHub 儲存庫與部署記錄。
7. 社群媒體、論壇與外部引用。
8. 憑證透明度記錄。
9. 網路掃描、子網域掃描與常見路徑探測。
10. 其他已知爬蟲或聚合器提供的資料。
爬蟲發現網站可形式化為：
$$
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 的主要目標為：
1. 偵測網站內容的真實變化。
2. 將變化轉換為標準化事件。
3. 向多個協議與平台發布通知。
4. 追蹤每次廣播是否成功。
5. 觀測不同爬蟲何時回訪。
6. 評估不同通知通道的效果。
7. 支援多網站、多網域與多內容類型。
8. 提供第三方 AI Agent 與爬蟲可訂閱的變更資料流。
---
# 第四部分：系統總體架構
## 11. 高階架構
```text
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：
```text
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 參數。
- 驗證 ``。
- 驗證重新導向鏈。
---
## 15. 事件生成器
標準事件格式可設計如下：
```json
{
"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"
]
}
```
### 事件類型
建議至少包含：
```text
created
updated
deleted
redirected
restored
metadata_changed
structured_data_changed
```
---
## 16. 事件佇列
事件佇列負責：
- 去除重複事件。
- 合併短時間內多次修改。
- 延遲發送。
- 錯誤重試。
- 指數退避。
- 優先級排序。
- API 頻率限制。
- 任務狀態追蹤。
- 失敗事件隔離。
可使用：
- Redis。
- PostgreSQL。
- SQLite，適合初期 MVP。
- RabbitMQ。
- Kafka，適合大規模。
- Cloudflare Queues。
- GitHub Actions 配合持久化資料庫。
初期可使用：
```text
SQLite + Python Worker
```
或：
```text
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 即時通知的通道之一。
範例：
```http
POST https://api.indexnow.org/indexnow
Content-Type: application/json
```
```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 引擎
系統應自動生成：
```text
/sitemap.xml
/sitemap-index.xml
/sitemap-pages.xml
/sitemap-papers.xml
/sitemap-products.xml
/sitemap-images.xml
```
每個 Sitemap 應只更新真正發生變化的 ``。
錯誤做法：
```xml
每天都改成今天
```
正確做法：
```xml
內容實際修改時間
```
Sitemap 本身是提示，不是收錄保證。
---
## 20. RSS 與 Atom Feed
對知識網站、論文網站與產品更新站，Feed 是低成本而穩定的發現通道。
建議提供：
```text
/feed.xml
/atom.xml
/papers/feed.xml
/products/feed.xml
/changes/feed.xml
```
每個項目至少包含：
- 標題。
- Canonical URL。
- 摘要。
- 發布時間。
- 更新時間。
- 作者。
- 分類。
- 唯一識別碼。
- 內容雜湊，可選。
---
## 21. WebSub
WebSub 可讓訂閱者收到 Feed 更新通知。
系統可提供：
```text
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 訂閱服務：
```http
POST /api/subscriptions
```
範例：
```json
{
"callback_url": "https://agent.example.com/hooks/content",
"topics": [
"papers",
"products"
],
"events": [
"created",
"updated"
],
"secret": "shared-secret"
}
```
事件發生後：
```http
POST https://agent.example.com/hooks/content
```
```json
{
"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` 發現文件
建議提供：
```text
/.well-known/discovery.json
```
範例：
```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. 變更資料流
提供：
```text
/changes.jsonl
```
範例：
```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"}
```
也可提供：
```text
/api/changes?since=2026-07-14T00:00:00Z
```
回傳：
```json
{
"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 的做法不可取。
例如：
```text
/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. 防止內部網址洩漏
廣播器只能提交公開網址。
應排除：
```text
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
```
系統應建立網域白名單：
```yaml
allowed_hosts:
- example.com
- www.example.com
- logic.example.com
```
---
# 第十部分：MVP 技術方案
## 33. 建議技術堆疊
### 後端
```text
Python 3.12
FastAPI
SQLAlchemy
SQLite or PostgreSQL
httpx
Pydantic
APScheduler or Celery
```
### 前端
```text
Astro
React
Tailwind CSS
Chart.js or ECharts
```
### 部署
```text
Docker
Cloudflare
GitHub Actions
Railway / Render / Fly.io / VPS
```
### 監控
```text
OpenTelemetry
Prometheus
Grafana
Sentry
```
---
## 34. MVP 目錄結構
```text
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
```sql
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
```sql
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
```sql
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
```sql
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
```sql
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. 建立內容變更事件
```http
POST /api/v1/events
```
```json
{
"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. 查詢事件狀態
```http
GET /api/v1/events/{event_id}
```
```json
{
"event_id": "evt_20260714_000001",
"status": "completed",
"deliveries": [
{
"channel": "indexnow",
"status": "success"
},
{
"channel": "sitemap",
"status": "success"
},
{
"channel": "websub",
"status": "success"
}
]
}
```
---
## 38. GitHub Actions 串接
```yaml
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. 中央服務
可建立：
```text
beacon.evemisslab.com
```
統一管理：
```text
evemiss.com
evemisslab.com
logic.evemisslab.com
agiright.org
eveglyph-editor.com
emlphosphor.com
thisoneisneok.com
```
每個站點部署完成後：
```text
GitHub Actions
│
▼
POST beacon.evemisslab.com/api/v1/deployments
│
├── 偵測變更 URL
├── 更新 Sitemap
├── 發送 IndexNow
├── 更新 RSS / Atom
├── 發送 WebSub
├── 通知 Agent Webhook
└── 紀錄爬蟲回訪
```
---
## 40. 多租戶模型
即使目前只有單一公司使用，也可預留多租戶設計：
```text
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、跨知識平台的內容變更基礎設施，使網站中的每一次新增、修改、刪除與重組，都能被轉換為可驗證、可追蹤、可重試與可擴充的網路事件。