網頁教學

實體SEO的起點，是一個大多數最佳化建議至今仍然略過的事實：搜尋引擎早就不再比對字串了。它們比對的是事物。一個頁面拿到什麼分數，並不取決於它是否含有某個詞組，而取決於系統是否相信這個頁面談的是詞組背後的那個概念，以及系統對於那個概念究竟是什麼有多少把握。 這個區別決定了重複關鍵字究竟對你有幫助，還是完全沒有作用。在比對字串的系統裡，重複是一種訊號。在比對實體的系統裡，重複只是雜訊，真正會推動結果的，是機器能不能辨識出你是什麼。 判斷你是否以實體身分存在的測試： 搜尋你的公司名稱，看看在沒有人追問的情況下，搜尋引擎主動端出了關於你的哪些資訊。如果它只回傳首頁，其他什麼都沒有，那麼你只是一串它找得到的字元。如果它回傳了描述、所在地、類別...

有排名卻從不被引用，是把搜尋引擎最佳化做對了、卻眼睜睜看著它什麼都沒帶來的那種很具體的挫折感。排名來了。曝光在漲。點擊卻沒有跟上，而且把標題標籤重寫多少次都不會有變化。 這不是你最佳化上的失敗。這是當結果頁不再是一份連結清單、而變成一個答案時必然會發生的事。而且它現在已經是常態，不是一個值得拿去診斷的異常。 我們自己的數據，取自 Search Console，統計範圍是截至 2026 年 8 月初的 28 天： 本站有 531 個查詢字詞排在前十名，帶來 28,847 次曝光，卻只換到 161 次點擊。這就是 0.56% 的點擊率，而第四到第十名在過去通常能拿到 2% 到 8%。這 531 個查詢字詞裡，有 452 個一次點擊都沒有...

llms.txt 現在到底有沒有用？誠實的答案是：在可測量的範圍內幾乎沒有用，而那些告訴你這個檔案對 AI 能見度至關重要的人，通常是在向你推銷東西。一邊這樣說，一邊又建議你發布一份，這個立場並不舒服。所以這篇文章先把數字攤開來，之後再解釋這項建議本身。 檔案本身是個合理的想法。它是放在網站根目錄下的一份 markdown 索引，告訴語言模型你發布了什麼、內容在哪裡，就像 robots.txt 告訴爬蟲哪些內容可以抓取一樣。想法沒有問題。問題出在它原本要服務的那些公司身上，它們幾乎沒有採用。提出一份規範，和真的出現讀取它的一方，完全是兩回事。 伺服器日誌真正顯示的情況： Ahrefs 對 137,000 個網域的分析發現，2026 ...

要不要封鎖 AI 爬蟲，往往被當成技術題來問，但它其實不是。封鎖本身只是幾行設定，在 robots.txt 裡補幾條規則，或在網路層打開一條規則，十分鐘就結束了。真正難的地方在於決定你到底想不想這麼做，而這個決定完全屬於生意層面：你是在兩件事之間取捨，一邊是保護內容不被拿去訓練模型，另一邊是讓自己繼續出現在人們現在用來取代搜尋結果清單的那些答案裡。 網路上多數建議都是先選邊，然後只替自己那一邊辯護。誠實的講法是另一種：正確答案會隨商業模式而不同。一家靠頁面瀏覽量維生的媒體，跟一家靠詢價維生的服務公司，本來就應該得出完全相反的結論。如果兩者答案一樣，那才代表有人算錯了。 這筆交易一句話就講得完： 封鎖 AI 爬蟲可以擋下內容被吸收，但...

Cloudflare Queues 解決的是每個無伺服器應用遲早都會撞上的那個問題：一個請求抵達，觸發了一段使用者本來不該等待的工作。寄出確認郵件、把上傳的圖片改尺寸、把記錄同步到第三方服務。這些工作的共同點是：它們必須發生，但並不需要在使用者按下按鈕的那一刻發生。在傳統伺服器上，你把這類工作交給一個背景工作行程就好。可是在 Workers 上，請求處理完就結束，根本沒有可以交出去的常駐行程。 常見的幾種繞道做法，比看起來更糟。把工作放在請求裡同步做完，等於讓使用者去等一家郵件服務商的回應。向另一個 Worker 丟出請求卻不等待它，只要發起方的呼叫先結束，這個工作就丟了。這兩種做法都撐不過服務商的一次故障。 佇列真正給你的是什麼：...

Cloudflare Hyperdrive 之所以存在，是為了處理一個非常具體、也一點都不炫目的問題：一個在 200 座城市裡執行的 Worker，去跟某一座城市裡的那一個 Postgres 資料庫對話，會比同一道查詢從緊鄰這台資料庫的伺服器發出來得慢。不是慢一點點，而往往是慢上好幾倍，而且原因跟查詢本身怎麼寫完全無關。 當一個無伺服器應用顯得遲鈍時，多數人的第一直覺是怪查詢規劃器，或是再加一個索引。但在跟某個區域資料庫溝通的 Workers 上，查詢本身通常沒有毛病。真正出問題的是連線。 Hyperdrive 真正修好的東西： 建立一次資料庫連線的代價，而且這筆代價要在每一個請求上重新付一遍。一條 Postgres 連線在第一列資...

電商的 GEO 比內容型 GEO 範圍更窄，而且在某個具體的地方反而更簡單：一個要回答商品問題的助理，想要的是可以直接講出口、不必繞圈子的事實。價格、有沒有貨、尺寸、相容清單、退貨期限。這些要嘛以機器可讀的形式存在於你的網站上，要嘛就不存在，而不存在的東西沒辦法被引用。 所以這與其說是寫作問題，不如說是資料問題。大部分工作落在商品 feed 與標記上，而不是落在銷售文案上，這跟這個領域裡其他所有題目的重心正好相反。 決定能不能被採用的，是準確度而不是完整度。 一個系統講出了你的價格卻講錯了，它就產生了一個糟糕的答案，而避免糟糕答案最省錢的辦法，就是不再使用不可靠的來源。過期的庫存與價格資料是被剔除最快的一條路，而且跟排名處罰不同，沒...

沒有人能用當年衡量搜尋引擎最佳化的那一套來衡量 GEO，原因不是工具不夠用，而是結構本身變了。舊指標全都建立在一個前提上：會有人點擊。當年排名值得知道，是因為排名可以預測流量，而流量可以預測營收。可是當答案不需要一次造訪就被直接送到使用者面前時，這條鏈子在第一個環節就斷了，而它下游的每一個數字仍然照常回報，好像什麼都沒有發生。 危險的地方正在這裡。排名看著正常。工作階段數看著還撐得住。儀表板是綠的，可你真正在意的那一塊正在歸零，而標準報表裡沒有任何一欄是為了把這件事告訴你而設計的。 要盯的訊號是曝光在漲而點擊持平，而且必須按查詢字詞逐條去看，不能只看整站彙總。 在彙總數字裡它是隱形的，因為幾個正常成長的頁面就足以把它蓋過去。在本站，...

多門市 SEO 在幾乎每一家嘗試的企業身上都以同一種方式跑偏。有人寫了一個不錯的服務頁，按門市數量複製一遍，把城市名換掉，然後發布十二個百分之九十五雷同的頁面。感覺像是把規模做起來了。它的行為卻是重複，而且往往把每個據點都壓住，而不是幫上任何一個。 這種本能可以理解，因為圍繞同一項服務寫出十二個真正不同的頁面，既難又貴。可這條捷徑產出的，是搜尋引擎沒有理由在其中偏愛任何一個的頁面，於是它挑一個，排名還不穩定，其餘的一概不理。 能解決大半問題的那條規則： 一個門市頁必須包含只對這家門市成立的東西。不是把城市名塞進一段通用文案，而是真實的人員、真實的停車、真實的營業時間、真正涵蓋的區域，以及真的在附近做過的活。如果換成另一家門市，頁面上...

白牌網站開發，是設計或行銷代理把一個建站專案賣給自己的客戶，再由一家獨立的技術夥伴以代理的名義、隱身完成交付的安排。它之所以存在，是因為一家小代理的帳和一支常設工程團隊的帳對不上。客戶的活是一陣一陣來的，開發者的薪水卻是每個月都要發，這兩件事之間的缺口，正是那些趕在需求之前招人的代理被拖垮的原因。 這個模式做得好會很好，砸起來也很難看，而你拿到哪一種，取決於合作約定的程度遠大於程式碼本身的品質。 你真正在做的那筆交換： 你讓出毛利，換來在不背薪水的前提下說接的能力。對一家以設計為主的代理，這通常是筆划算的交換，因為另一條路要麼是推掉活，要麼是對著還沒簽下的機會先招人。它變成一筆壞交換的時刻，是當開發成為你賣的主要東西，因為那時你外包...