你維護的網站的網頁數是否有上千頁或上萬頁？如果答案是YES的話，一定會存在History SEO這個問題，因此會有人提出許多意見。 什麼是History SEO？ History SEO並不是一個官方正式的名詞，你可以想成網站長久維護下來產生的重覆內容、錯誤資訊、已經沒有在經營的產品……等等所產生的SEO負面問題。 另外，爬蟲的效能也有限，這也是為什麼網頁速度很重要的原因，速度越慢，爬蟲每天在你的網域爬到的頁面數量就越少。因此，也有人會有網站瘦身的想法。 為何要重視這個問題？根據 Google的常見問題 之中，有一段話寫得很明確： 移除不實用的內容，是否能提升我其他內容的排名？ 我們的系統主要是在網頁層級運作，以便盡可能顯示最實用的內容，即使該內容所在網站同樣代管不實用的內容也不例外。話雖如此，要是網站中有特別多不實用的內容，可能會讓網站的其他內容在 Google 搜尋中的成效降低，但影響程度不一。移除不實用的內容，可能有助於提升其他網頁的成效。 常見的例子就是官方新聞稿或是blog文章，這些網頁可能代表著整個企業的歷史軌跡，刪除是不被高層主管允許的，所以不得不留下來。因此產生一些改善做法： 1. 更新內容 我認為這是最有效的方法，不但不用再新增頁面，也能讓舊內容因更新而起死回生，如果主管同意的話。 2. 網頁合併 相似內容且意圖相同的網頁可以考慮合併，但此種方法的困難點除了轉址之外就是主管同意的可能性很低，畢竟合併也代表有網頁會被刪除。 3. canonical 將相似或相同意圖的網頁用canonical指向同一個網頁，可以解決許多問題，但這樣做其實不正確，如同下面 John Mueller 所說的一樣，不如直接重定向。 且做起來非常耗費時間，你必須決定哪些網頁需要canonical到別的頁面，而那個目標頁面又是哪一頁。而且，有一些人認為（未必正確），太多canonical指向的那個目標頁面，會讓爬蟲覺得好像沒有那麼重要，或是刻意操作。 4. noindex 不讓這些網頁出現在搜尋結果中。 5. unavailable_after 設定日期，讓爬蟲知道這個頁面在設定的日期之後就已經不重要了，這個設定也不會在日期之後出現在搜尋結果中。使用方法可以參考Google的 說明文件 。 6. robots.txt 有些人...

什麼是主題群集？有什麼好處？ 主題群集（Topic Cluster）是為了讓網站關鍵字優化和結構更完整的SEO策略，又稱為內容叢集或pillar-and-cluster，通常會選取一個主要關鍵字編寫網站的核心主題，內容提到許多次要關鍵字，而這些次要關鍵字也編寫與其相關的內容主題網頁（支柱內容，Pillar Content），並和主要關鍵字的頁面建立內部連結。就像在建造房子一樣，梁柱越多越穩固，也間接提升了網站的可信認度與權威度。 主題群集的做法行之有年，在2017年就已經由HubSpot Research率先提出。主題群集能避免將大量主題塞在同一頁中，分散和歸類各種主題形成支柱內容，優化網站內容架構，讓使用者閱讀起來方便一點。 再簡單一點來說，核心主題、相關的補充內容（支柱內容）與讓它們互相連結起來的超連結，這三樣東西就是主題群集的一切。 為什麼主題群集越來越重要 因為SGE（2024年中改稱為AI Overview）的興起。其實不止如此，Bing Chat（Copilot）和 Gemini 的興起也會影響。 SGE（Search Generative Experience）是Google的「生成式搜尋體驗」，它能讓使用者能簡單又快速地了解某個人事物，並提供相關連結，讓使用者能因其需求選擇要不要點擊進去更深入地探索問題。除此之外，SGE因其對話式的架構，讓使用者可以繼續詢問相關問題。 這是不是和主題群集很像？不論是相關連結或是繼續詢問，都跟支柱內容有異曲同工之妙。 結論 主題群集的SEO做法行之有年，能對網站SEO優化是大家所公認的，內容寫的好，將會為網站在該領域建立領導地位與權威性的形象，無論如何做了都不會吃虧，還有機會提高獲得SGE青睞的機率。另外，也不要輕忽零搜尋量關鍵字的重要性。 「適度地」延伸網站的支柱內容，並在這些頁面深入探討這些次要主題，也許是情境，也許是知識，讓自己的網站架構就像是座堡壘一樣。

v3版本 $msg = array(); $secret = 'your_secret_key'; $gRecaptchaResponse = isset($_POST['g-recaptcha-response']) ? $_POST['g-recaptcha-response'] : null; $ip = $_SERVER['REMOTE_ADDR']; $domainName = $_SERVER['HTTP_HOST']; include_once ("recaptcha/src/autoload.php"); $recaptcha = new \ReCaptcha\ReCaptcha($secret); $resp = $recaptcha->setExpectedHostname($domainName) ->setExpectedAction('homepage') ->setScoreThreshold(0.5) ->verify($gRecaptchaResponse, $ip); if ($resp->isSuccess()) { // $msg['ending']=$resp->toArray(); } else { $errors = $resp->getErrorCodes(); $msg['ending']='recaptchaFail'; $msg['recaptcha']=$errors; echo json_encode($msg); exit(); } 其中，autoload.php是 官方在github 給的檔案： /* An autoloader for ReCaptcha\Foo classes. This should be required() * by the user before attempting to in...

網路上有許多機器人驗證的替代方案，這裡介紹與 Google reCAPTCHA 寫法幾乎一樣的 Turnstile 給大家嘗試看看。 下面的寫法給各位參考： 後端PHP傳送與接收資料 與 Google 一樣，將query「response」與「secret」丟過去就可以了（範例多了「remoteip」，這個不一定要有）。 // captcha.php $captcha = $_POST['cf-turnstile-response']; $secretKey = 'your_secret_key'; $ip = $_SERVER['REMOTE_ADDR']; $url_path = 'https://challenges.cloudflare.com/turnstile/v0/siteverify'; $data = array('secret' => $secretKey, 'response' => $captcha, 'remoteip' => $ip); $opts = array( 'http'=> array( 'method'=> 'POST', 'content'=> http_build_query($data) ) ); $query = stream_context_create($opts); $result = file_get_contents($url_path, false, $query); echo json_encode($result); // 如果你想在後端直接判斷有沒有成功 $array = json_decode($result, true); $success = $array['success']; if($success){ // 驗證成功 }else{ // 驗證失敗 } 後端PHP這樣寫沒有問題，但資料回傳到前端JavaScript問題就出現了。 前端JavaScript接收Object $.ajax({ type: ...

若你的網站違反 Google AdSense 的廣告政策，你的 Google AdSense 介面會出現警告，也會收到 email，並要求你必需在期限內「申請審查」。 也因為如此，我的某些網頁在 SERP 中消失了（它並不會告訢你哪個網頁有問題，只會說網域），這讓我必需立即著手改善，但我該怎麼做？ 判斷違規的原因 首先，我去 政策中心 找尋可能的原因，但還是無法判斷。之後，重新讀一次它在信中提到的可能原因：「試圖讓使用者誤點擊」，所以我把側邊工具欄的廣告全部都刪除了。 結果 在申請審查時，表單會叫你填「做了什麼改善」、「範例網頁」等等的欄位，我當然是填了「刪除工具列的廣告」。而在兩天之後，審查通過了，原本在 SERP 消失的網頁也神奇地復活了。 AdSense審查通過的通知信 疑問 讓我驚訝的是，我以為這樣子的違規逞罰頂多是不讓網站出現廣告，或是網站排名下降而已；但我錯了，是網頁直接消失，而且是消失一週之後才通知我違反廣告政策……。 其實，我在網站工具列放廣告已經放好幾年了，現在才說我違規，而且刪掉那裡的廣告還真的讓我過關了……大開眼界。 你可能會說，這說不定是 Google 核心更新在搞事。但官方公告開始更新的日期是在我審查通過後的三天，所以不太可能。

PHP simple encryption and decryption functions php 字串加密與解密簡單的寫法，這裡使用的是 openssl_encrypt 這個語法： // 加密函数 function encryptFunction($data, $key) { $encryptedData = openssl_encrypt($data, 'AES-256-CBC', $key, 0, substr($key, 0, 16)); return $encryptedData; } // 解密函数 function decryptFunction($encryptedData, $key) { $data = openssl_decrypt($encryptedData, 'AES-256-CBC', $key, 0, substr($key, 0, 16)); return $data; } // 因為上面寫了 openssl_encrypt() 至少要16 byte，所以這裡的key至少要16個字 $encryptionKey = 'abcdefghijk123457'; 因為寫了 substr($key, 0, 16) 抓取 $key 的 1~16 位置的文字，所以 $key 沒有16個字的話會報錯，你可以視自己的需求改變長短。 實際使用範例 // for example $tempVariable = 'oh nyo!'; $tempVariableEncrypt = encryptFunction($tempVariable, $encryptionKey); // mmdpiTHs1NnuNZrk7zxnWA== $decryptBack = decryptFunction($tempVariableEncrypt, $encryptionKey); // oh nyo! 這個方法可以簡單運用在存入資料庫，與取出資料庫的資訊給具有權限的人。

這篇文章的後端轉址，基本上是以 PHP 為主。 PHP header()重新導向新網址 使用header()語法宣告301 我們可以先跟搜尋引擎的爬蟲宣告這是 301 頁面，之後再轉址。相較於直接重定向轉址，這對爬蟲來說會比較友善，等於是說這一頁被淘汰了，它才不會一直花費效能來這一頁。 另外，宣告 301 也能告知爬蟲，重新導向的網址內容是優於原本網址的版本。 header("HTTP/1.1 301 Moved Permanently"); header("Location: https://example.com/"); exit(); 又或者我們可以這樣寫： header("Location: https://example.com/", TRUE, 301); exit(); 使用http_response_code()語法宣告301 寫法如下： http_response_code(301); header("Location: https://example.com/"); exit(); 轉址 301、302、不宣告，差在哪裡？ 301 狀態碼是「永久轉址」的意思，表示網頁已永久遷移至新的位置。如同前面所述，爬蟲就不會一直白白浪費效能。 302 狀態碼是「暫時轉址」的意思，因為某些原因，暫時轉址到其它頁面。可以告訴爬蟲，未來這個頁面還會再恢復使用。 不宣告直接刪除就跟404找不到頁面差不多意思，會造成使用者體驗不佳；而直接轉址的話，基本上會被視為301；最糟糕的情況是不宣告也不刪除，就直接把原來的內容複製到另一頁，或是在別的頁面更新原內容，這有可能會造成「重複內容」的情況發生。 標準網址含有追蹤碼怎麼辦？ 有時候，Google會將含有追蹤碼的網址當成標準網址，原因是主要的參照網頁的網址有追蹤碼的關係，這會造成SERP的網址也包含追蹤碼，來源媒介會不準確。 若使用JavaScript轉址到你要的標準網址，Google會將其視為轉址修正，但不確定是 301 還是 302： const params = new Proxy(new URLSearchParams(window.location.search), { get: ...

創造有用又可信任的內容，也就是我們常聽到的 EEAT（經驗、專業知識、權威性和可信度），並顧慮到網頁要以人為出發點撰寫內容。 Google在近期的更新（包含核心更新）都不斷地強調「實用的內容」，到底什麼是實用的內容，他們給出了一些 問題 給網站管理者參考…… 你的SEO是搜索引擎優化還是搜索引擎優先？ 或者有人稱之為「最佳化」…… 網頁是給使用者觀看和使用的，你的最終目的畢竟是轉換，而不是為了獲得搜索引擎排名而製作的搜索引擎優先內容，請不要忘記這一點。試著問自己網站內容的撰寫方式，避免自己走火入魔： 內容主要是為了吸引搜索引擎爬蟲而製作的嗎？ 是否在許多不同主題上製作了大量內容，希望其中一些內容在搜索結果中得到良好的排名？ 是否大量使用「自動化工具」來製作各種主題的內容？ 總是在總結別人說的話而沒有增加更多價值？ 創造的內容只是因為它們看起來很流行，而不是為了現有的觀眾寫這些東西嗎？ 是否會讓讀者需要再次搜索才能從其他來源獲得更好的資訊？ 迷信網頁內容要達到特定的字數？ 在沒有任何真正專業知識的情況下撰寫某些主題，且主要是因為你認為自己會獲得搜索流量？ 內容是否是在回答一些實際上沒有正確答案的問題？ 創造以人為本的內容 網站是否有現有或預期的受眾，他們會認為內容對他們很有用嗎？ 內容是否清楚地展示了第一手的專業知識和深度（例如，來自實際使用產品或服務或訪問某個地方的專業知識）？ 網站是否有主要目的或重點？ 有人會覺得他已經足夠理解某個主題，並帶著這些知識幫助實現他的目標嗎？ 使用者是否會覺得他們獲得了令人滿意的體驗？ 內容的品質 相信大家都知道內容的品質是SEO最著重的部分，除了問自己下列問題之外，還可以考慮讓你信任但與網站無關的其他人提供誠實的評估： 內容是否提供原創訊息、報告、研究或分析？ 內容是否完整或全面地描述某個主題？ 內容是否提供了有用的分析或有趣的訊息？ 如果內容借鑒了其他來源，它是否避免單純地複製或重寫這些來源，而是提供實質性的附加價值和原創性？ 主標題或頁面標題是否提供了內容或該段落的描述性、有用的摘要？ 主標題或頁面標題是否避免寫得很誇大或震驚？ 你認為有人會加入書籤、與他人分享或引用嗎？ ...

之所以稱為「短語關鍵字」的原因在於，它通常是一個單字或一個詞。 短語關鍵字的SEO重點 首先，要找出搜尋流量相對較多的詞，我們不可能思考「零流量關鍵字」，那是長尾關鍵字其中之一的工作；另外，還需要知道大部分的使用者為什麼會搜尋這個字。因此，我們可以歸納出四個重點目標： 流量 表面上的搜尋原因 相關搜尋原因 潛在搜尋原因 這裡要注意千萬不要被「流量」衝昏頭，它只佔了其中一個原因，而不是全部，必需要是與網站本身有關或真正能帶來轉換的字詞。以下我用「cim」這個短語關鍵字來舉例。 表面上的搜尋原因 我們可以從SERP中很快知道，它是什麼意思佔了很大的比重，因此我們可以在寫文章時，提及這個字的意思，並可以考慮往外延伸至「由來」、「演變」或相似詞的「比較」。 相關搜尋原因 另外，可以看排名較後面的網頁在說什麼、「相關搜尋」或是查看「其他人也問以下問題」的區塊來擴充文章篇幅和深度。例如，「cim工程師的徵才網頁」，在文章中就可以提及工程師們面臨的問題與挑戰。 Google的autocomplete 其他人也問的區塊，有人稱其為PAA（people also ask） bing也有相關搜尋可以參考 Google相關搜尋區塊 潛在搜尋原因 而在SERP前後排名與內容的多方思考之後，我們可以推論，使用者潛在的真正搜尋原因，是想要知道「cim的工作內容」，我們就可以在文章中加入這個重點內容，最後再加上近況與未來的結論，這樣就是一篇很好的文章。 Google 從以前就一直在宣導 有用內容 的重要性，所以推測出使用者的潛在原因是很重要的步驟。 繼續強化標題與可讀性 而 title 當然也要從cim這個字擴充，最好有提到「什麼」和「工程師」這兩個詞。 如果可以的話，再畫一、兩張原創的圖片後放在文章中更好，才不至於讓使用者看一篇密密麻麻只有文字的文章。 當然，還要充實你自己（也就是作者與網站本身）。如果你代表公司寫文章，記得到 wiki 介紹自己的公司，也請記得充實作者頁面，增加相關性質的文章，讓你的文章可信度增加。 方法 最後，如果你還有餘力與能力的話，一定要寫出「解決方案」，畢章歸納別人說過的話大家都辦的到，能夠解決使用者問題的網頁，才算是真正有價值的網頁！

我們只要用很古老以前就存在的 border-image-source 和比較新的漸層語法 conic-gradient 互相結合就可以辦到。 簡單的漸層邊框範例 #example-card{ width: 200px; height: 200px; border: 20px solid hsl(80 100% 50%); border-image-slice: 1; border-image-source: conic-gradient( from 0deg, hsl(80 100% 50%), hsl(200 100% 60%), hsl(80 100% 50%) ); } EXAMPLE 因為 conic-gradient 的關係，這裡只要注意不要用在 IE 和舊 edge 就可以了。如果還是很擔心，其實用 linear-gradient 也可以。 邊框圓角 大家都知道，漸層屬性的CSS是寫在「xxx-image」底下（這裡是 border-image），而此屬性的 border-radius 會失效。因此，若要實現圓角就必須使用其它方法實現，這裡我們用擁有裁切功能的 clip-path。 clip-path: inset(0 round 24px); inset 的意思是內部裁切，0 是貼合主體，這樣就能簡單實現外邊框圓角。

最近遇到一個要讓 blog 文章無限滾動的要求，也就是說使用者在滾動到網頁下緣的時候，JavaScript 會自動戴入一篇相關的新文章在網頁中，目的是讓使用者繼續觀看相關的內容，增加在網頁的互動時間。 我使用的語法是 Intersection Observer API 和 History API（replaceState），與後端互動的語法則是 jQuery 的 ajax。 Googlebot 會抓取無限滾動的內容嗎？ 答案是：會。 至於會抓到多深？根據我自己的觀察，可以抓到至少兩篇無限滾動後出現的文章，Google 還蠻厲害的。 Google 的 JS SEO 的注意事項 Google 清楚表明他們的爬蟲基本上 不會去偵測 click 和 scroll 事件 ，所以在呈現無限滾動時，切記不要使用 scroll 事件去寫 JavaScript。 SEO 出現問題 就在我把程式碼寫上去之後一、兩天，網站的所有文章都開始出現一些 SEO 的問題，甚至到了不得不處理的地步，因為各網頁的排名有很明顯地下降（至少我這種寫法確實會影響 SEO，或許存在著對 SEO 更安全的寫法）。 CLS 無限滾動後出現的內容很明顯會造成網頁的區塊位移，我想這大家應該都可以理解，但業主認為這是小問題。而對於業主的「目標」，我也不否認這是可以忽略的問題。 載入時間 若無限滾動後出現的文章容量大小不大，這不會是什麼問題，但就是有容量很大的文章。 我不知道無限滾動後才出現的內容算不算在 Google 的載入時間中，所以我只能說無限滾動可能會讓載入時間受到影響。 結構化資訊錯誤 因為有許多文章使用例如 FAQ 的結構化資訊（FAQ 規定一個網頁只能出現一次），所以理所當然地，Google Search Console 馬上就發出了錯誤訊息通知。 這個問題對我來說是無法無視的，因為這會讓被認定為有語法錯誤的文章的 FAQ 結構不會出現在 SERP 之中。 解決方法 目前是在外面包一層用來偵測 search bot 的程式碼來規避。短期看起來是有效的，因為網頁又回到原本的排名。 var botPattern = "(/bot|google|baidu|crawler|spider|duckduck|crawling|bing)"; var re...

如果你的網站客群是全世界，那麼在 Google Search Console 的國際地理定位選項可能會影響網站在搜尋結果 SERP 的排名表現。 網站如何指定國際目標？ 該功能在「舊版工具和報表」之中，點開就可以看到「 指定國際目標 」。點擊進入後，在第二個頁籤（國家/地區）可以選擇要不要開啟與定位在哪裡。 而第一個頁籤「語言」，可以檢查網站的 hreflang 標記有沒有錯誤。 但是，如果網站的域名是 .tw 結尾，那麼該系統會自動幫你的網站定位為「台灣」，連選擇的權利都沒有。 地理定位如何影響網站排名？ 在 Google 的 SEO Office Hours 影片 中，有人問 John Mueller 為何一個較小的姊妹網站，排名比他們的主要新聞網站還要好。 John Mueller 回答可能是 Search Console 的國際定位設定的問題： 「我注意到的一件事是您在 Search Console 中設置了巴基斯坦的地理定位。我不知道這是否是設計使然，又或是您刻意設定的。如果您想製作一個國際通用的英文新聞網站，那麼關閉地理定位可能是有意義的。在搜尋方面，如果你想定位巴基斯坦以外的國家，比如一般的英語新聞網站，那麼我肯定會關掉它。因為它會較為專注於巴基斯坦的搜尋，然後稍微少關注其他國家。」 結論 所以，以 John Mueller 說的話，再加上該功能的設定特性，在一開始買網域名稱的時候，就已經要確定網站的定位了！？ 是要專注在一個地方經營，還是往全世界經營；如果主要目標是在台灣的排名，選擇 .tw 網域或指定地理位置很好；但它可能會對其他國家/地區的排名產生較不利的影響（曝光會少一些），在一開始就要想清楚。

matchMedia 的易用性 JavaScript 語法中的 matchMedia 瀏覽器相容性很高，IE10 以上都支援，所以基本上不用擔心什麼 polyfill。 而 matchMedia 的用法就像寫 CSS 的 media query 或 HTML 的 picture 一樣： var xsMQ = window.matchMedia('(min-width: 480px)'); var mdMQ = window.matchMedia('(min-width: 992px)'); 變數 xsMQ 和 mdMQ 是 boolean 值 ，因此，可以用判斷式來做想做的事。 matchMedia 與 change 事件結合 我們都知道 resize 有效能問題，需要用 debounce 或 throttle 解決，而如果把上述的 matchMedia 判斷式寫成 function，更可以用 change 事件 做到 resize 可以做的事！ function mediaQueryStep(){ if(xsMQ.matches){ if(mdMQ.matches){ // big size：do something... }else{ // between big and small size：do something... } }else{ // small size：do something... } } xsMQ.addEventListener('change', mediaQueryStep); mdMQ.addEventListener('change', mediaQueryStep); mediaQueryStep(); 所以，在一些media query 沒有每改變 1 pixel 就會觸發某事件的情況下，matchMedia 也不失為一個好選擇。