Elementor 與自訂佈景主題之爭，通常被當成品味問題來吵，偶爾還被當成部落身分來吵。它兩者都不是。它是一個成本問題，而且形狀可以預測：頁面建構器把成本從建置階段挪到了網站的營運週期裡。這筆交易划不划算，取決於兩個幾乎沒人擺到檯面上的數字，一是網站有多少頁面，二是這些頁面多久改動一次。 爭論遲遲沒有結論，是因為雙方都在用軼事說話。有人說建構器很慢，另一個人貼出一張綠色的 Lighthouse 分數，什麼也沒有定下來。效能確實是一項真實成本，但它只是一張更長帳單上的一行，同一張帳單上還有授權續約、外掛堆疊、內容編輯吞吐量、無障礙整改，以及最後把內容重新取出來的價格。 Elementor 不是一個糟糕的工具。對一大類網站來說它就是正...
網站優化
網站優化指南、技巧與最佳實踐 — 提升效能、速度與使用者體驗。面向開發者與技術團隊。
「Drupal 很慢」這個名聲，絕大部分來自主機代管，而它幾乎總是一個採購決定，不是軟體問題。網站被認真地做了出來，然後上線在一個以「幾個 PHP 檔案的形象網站」定價的方案上。結果就是：一套帶著正經算繪管線的內容管理系統，跑在一個自己改不了的記憶體上限裡，跑在一個自己控制不了的作業碼快取上，還沒有一個能執行自身工具的命令列。 人們心裡拿來對比的是 WordPress，而這個對比是錯的。WordPress 幾乎在任何環境下都能勉強跑得動，是因為它的市占率逼著主機商把它做成幾乎在任何環境下都能勉強跑得動。Drupal 的前提不同：它假定你有較新的 PHP、較新的資料庫、真正的快取後端、一個命令列，以及一套把程式碼庫當成建置產物、而不是...
Drupal SEO 的名聲並不完全配得上它的實力。隨便問一圈，總有人會告訴你 Drupal 開箱即用就很適合搜尋，而說這話的人往往是拿十五年前對另一個平台的記憶在做比較。一套原裝的 Drupal 11 安裝，既沒有中繼描述欄位，也沒有 XML 網站地圖，URL 變更時沒有自動轉址，而且在編輯手動輸入別名之前，內容一直在 /node/123 上回應。 這不是在批評這個專案。核心刻意把自己的範圍維持得很小，把一切帶有立場的東西推給貢獻模組，而這正是大型 Drupal 網站能比多數平台調得更精細的原因。但這也表示開箱即用這個說法承擔了非常多的分量，也表示一個 Drupal 網站的搜尋表現，幾乎完全取決於第一天裝了哪些模組，以及有誰把它們...
CMS 遷移屬於少數幾類專案：技術面可以做得毫無差錯，結果卻仍然是一場災難。網站按期上線，外觀更好看，載入也更快，流量卻掉了一半，原因是幾百條網址換了形狀，而沒有人去做那張對照表。技術驗收一項項全過，商業結果卻是負的。 掉掉的流量並不是新平台造成的，而是斷裂造成的：以前能回應的網址現在不再回應，以前認得出來的頁面現在看起來像全新的，多年累積在舊網址上的歷史也失去了去處。而且排名往往不是上線當天就掉下去，而是在接下來的幾週裡慢慢往下沉，所以上線當天看起來一切正常，並不能說明任何事情。 決定結果的只有一個判斷：你要保留 URL 結構嗎？ 如果保留，遷移基本上就是一件內容與範本的工作，風險有限。如果不保留，每一條變動過的網址都需要一條指向...
多語言 SEO 通常被講成一個翻譯問題，外加一點技術標記。但把這個網站用十二種語言營運下來，也就是英語、阿拉伯語、德語、法語、匈牙利語、義大利語、日語、韓語、羅馬尼亞語、越南語，再加上中文的兩種書寫形式，我們很清楚地看到：翻譯才是簡單的那一半。 難的那一半在於，你在英語裡習以為常的每一條規則，都有一個依文字系統而變的版本，而你原本並不知道它存在。長度上限不一樣。結構會跑掉。數字會被一個想幫忙的譯者寫成國字，從那一刻起就不再和原文對得上。這些問題在有東西去檢查之前，一律看不見。 真正讓它跑得起來的是自動化，不是努力。 在任何內容上線之前，有十一項獨立檢查會從頭到尾掃一遍：語言涵蓋率、原文與各譯文之間的結構一致、數字一致性、標題層級順...
在多數已經經營了一段時間的網站上，內容更新是報酬率最高的一項工作，而它之所以不受歡迎，正是因為做完之後沒有任何東西可以拿出來宣布。修改一篇已經有排名的文章，感覺像是在做維護。發布一篇新文章，感覺像是在往前走。數字通常不同意這種感覺。 原因在於，一個已經存在的頁面早就累積了那些昂貴的東西：外部連結、檢索紀錄，以及與一組搜尋字詞之間被驗證過的關係。新頁面從零開始，什麼都沒有，要花上好幾個月才能掙到舊頁面早已擁有的東西。而改進舊頁面，是直接疊加在這份累積之上。 會讓整件事白做的錯誤，是只改日期，別的什麼都不改。 這種做法夠常見，值得把話講明白。一個把新鮮度納入考量的檢索系統，比較的是內容而不是時間戳記，一個日期動了、實質卻原封不動的頁面，...
程式化 SEO 指的是用一套模板加一份資料集大量生成頁面：每個城市一頁、每個產品組合一頁、每一種參數組合一頁。如果用的是真實的資料集，它是這個領域裡效率最高的做法之一。如果用的是同義詞詞典和洗稿工具，它就正是搜尋引擎花了二十年學著辨認的東西。 差別不在技術。兩條路都會大量產出模板頁面。差別在於每一頁是否包含只有這一頁才能回答的東西，而這是關於你手上資料的問題，不是關於你內容流程的問題。換句話說，這個問題的答案在資料庫裡，不在編輯台上。 區分兩者的檢驗方法： 把模板拿掉，看看一頁上還剩下什麼。如果剩下的是真正不同的事實、不同的價格、不同的資料集、不同的計算，這一頁就有存在的理由。如果剩下的是同一段文字換了個地名，...
內容修剪是搜尋最佳化裡最違反直覺的一件事，因為所有本能都在說，頁面越多流量就該越多。發布內容讓人覺得是在累積資產。刪除內容讓人覺得是把別人花錢買來的成果丟掉。於是刪除一再被往後延，最後只剩下一堆越疊越高的頁面。 讓刪除真正發揮作用的機制，是你自己的頁面彼此在競爭。當你有兩個頁面瞄準同一個搜尋意圖，本來會集中在一個頁面上的訊號就被劈成兩半，而必須在兩者之間做取捨的檢索系統，最後甚至可能一個都不選。解法不是把兩個都做得更好，而是別再同時擁有兩個。 在刪掉任何東西之前，先看清每個頁面各自在做什麼。 一個沒有點擊的頁面，可能仍然承接著一條傳遞權重的反向連結，也可能每月只有一位訪客，卻把這位訪客變成比網站其餘部分加起來還值錢的詢價。流量單獨拿...
資料庫效能的排查工作，通常從有人提議換一台更大的執行個體開始，又通常以這樣一個發現收場：每次載入頁面時，有一條查詢都在對 400 萬列做循序掃描。瓶頸從來就不是硬體，瓶頸是執行計畫。 這個模式重複得夠穩定，值得當成預設假設寫下來。當應用很慢而資料庫又很忙時，原因幾乎都是少數幾條特定的查詢，而不是整體容量不足；把機器換大，只能把問題掩蓋到資料表再次長大的那一刻為止。 動手改之前，先量。 憑猜測去最佳化一條查詢，正是團隊花掉整整一週新增索引、結果寫入變慢而讀取一點也沒變快的原因。任何資料庫都能告訴你哪些語句消耗的總時間最多。從那裡開始，修掉排在最前面的那一條，然後再量一次。這樣反覆兩三輪，事故通常就結束了。 資料庫效能始於找出那條查詢總...
實體SEO的起點，是一個大多數最佳化建議至今仍然略過的事實：搜尋引擎早就不再比對字串了。它們比對的是事物。一個頁面拿到什麼分數，並不取決於它是否含有某個詞組，而取決於系統是否相信這個頁面談的是詞組背後的那個概念，以及系統對於那個概念究竟是什麼有多少把握。 這個區別決定了重複關鍵字究竟對你有幫助，還是完全沒有作用。在比對字串的系統裡，重複是一種訊號。在比對實體的系統裡，重複只是雜訊，真正會推動結果的，是機器能不能辨識出你是什麼。 判斷你是否以實體身分存在的測試： 搜尋你的公司名稱，看看在沒有人追問的情況下，搜尋引擎主動端出了關於你的哪些資訊。如果它只回傳首頁，其他什麼都沒有，那麼你只是一串它找得到的字元。如果它回傳了描述、所在地、類別...