我是怎麼篩選和維護這份網址列表的
大部分網址導航活不過兩年。原因不是沒人做，而是沒人維護：鏈接死了沒人發現，描述抄自官網標語等於沒寫，分類越加越多最後自己都找不著。
這篇寫一下本站的做法，順便也能當作整理自己收藏夾的參考。
收錄標準：寧缺毋濫
一個站點要進列表，必須同時滿足四條：
一、還活著。 不是"域名還能打開"，而是最近一年有實質更新。很多工具站頁面還在，但功能早就壞了。
二、在自己的領域排得上號。 同類裡如果已經有明確的第一梯隊，第五名就沒有收錄價值。用戶要的是"該用哪個"，不是"有哪些"。
三、普通人能用。 需要企業郵箱、需要審批、需要聯繫銷售才能試的，不收。
四、不碰紅線。 盜版、破解、賭博、成人內容一律不收；任何形式的代理、加速、翻牆類服務也不收——這是硬性的，本站只做"有哪些好網站"這一件事。
按這四條篩下來，最初列的四百多個候選站點砍掉了將近一半。
描述：只寫一句，但必須有信息量
這是最花時間的部分。
反面例子（抄官網標語）：
Notion —— 一個全新的工作空間。
這句話讀完你還是不知道它是幹什麼的。
正面例子：
Notion —— 筆記、數據庫與知識庫合一的工作臺。
一句話要回答的是：它是什麼類別的東西，以及它跟同類比強在哪。寫不出這句話，通常說明我自己也沒真正用過，那就不該收錄。
具體的寫法約定：
- 控制在 15 到 25 個字，太長在卡片裡會被截斷
- 不用"強大""領先""最好"這類形容詞，它們不傳遞信息
- 能給具體數字就給（"15GB 免費空間"比"空間充足"有用）
- 提到侷限性也沒關係（"數量精簡"本身就是有效信息）
分類：先定數量上限，再往裡塞
分類失控是導航站的通病。做法是先定死上限：不超過 20 個一級分類，不做二級分類。
超過上限時不加新分類，而是合併舊的。比如"雲盤"和"備份工具"合成"雲盤存儲"，"圖庫"和"設計工具"合成"設計素材"。
另一條原則是按用戶的目的分，不按技術屬性分。用戶想的是"我要找圖"，不是"我要找基於 CDN 的靜態資源分發平臺"。所以 Unsplash 進"設計素材"，而不是按它的技術棧歸類。
每個分類控制在 10 到 18 個站點：少於 10 個說明這個分類沒必要獨立存在，多於 18 個說明該拆或該砍。
死鏈檢查：定期跑一遍
鏈接會以驚人的速度腐爛。業界的經驗數據是，五年後大約四分之一的鏈接會失效——服務關停、被收購後域名重定向、或者乾脆改了路徑。
維護上的做法：
- 每季度批量請求一次全部鏈接，記錄狀態碼
- 301/302 重定向要人工看一眼跳去了哪：跳到新域名就更新，跳到某個集團的營銷首頁說明服務已經沒了，直接刪
- 403 不一定是死鏈，很多站點會拒絕自動化請求，需要人工打開確認
- 連續兩次檢查失敗的直接移除，不留著佔位
刪掉一個站點的時候，如果它有明確的繼任者，就在同分類裡補上；如果整個品類都消失了，那就讓分類變小，不硬湊。
為什麼用 JSON 存數據
所有鏈接存在一個 links.json 文件裡，構建時生成靜態 HTML。這樣做的好處：
- 加站點只改一個文件，不碰任何頁面代碼
- 數據和展示分離，將來想換個界面，數據原樣搬過去就行
- 可以寫腳本批量處理——死鏈檢查、去重、統計，都是幾行代碼的事
- 版本管理清晰，用 git 一看就知道這次加了什麼
對應的壞處是每次改完要重新構建。但對一個每週更新一兩次的站點來說，跑一次 node build.js 的成本可以忽略。
為什麼堅持靜態生成，而不是前端動態加載
有個更省事的做法：頁面加載後用 JavaScript 請求 JSON，再把卡片渲染出來。代碼更短，改數據都不用重新構建。
但這條路有個致命問題：搜索引擎抓到的是一個空殼頁面。爬蟲看到的 HTML 裡沒有任何站點名稱和描述，等於這些內容對搜索引擎不存在，整個站的收錄會非常糟糕。
所以本站選擇在構建時就把所有卡片渲染進 HTML。用戶看到的和爬蟲看到的是同一份內容，每個分類還有獨立的 URL 和標題。搜索"某某分類 網站推薦"能搜到，靠的就是這一點。
前端 JavaScript 只負責錦上添花的部分：搜索框篩選、滾動高亮、移動端菜單。關掉 JS，頁面照樣能看能點。
如果你想整理自己的收藏夾
同樣的方法可以縮小到個人使用：
- 定一個上限，比如 100 個鏈接，超了就必須刪
- 每條寫一句自己的話，寫不出來的說明你沒在用，刪掉
- 每半年清一次，打不開的、一年沒點過的，直接刪
- 分類按"我什麼時候會用它"來分，不按網站類型分
收藏夾的價值在於能快速找到，不在於收了多少。這一點和做導航站是一樣的。
本站目前收錄 17 個分類、200 多個站點，數據每次更新都會在頁面底部標註日期。發現死鏈或者想推薦站點，歡迎告訴我。