其實這件事大家心裡應該都有個底，但沒有百分之百的證據，而Google對於流量下降的解說有些許的更新，我們可以從中觀察出網站內的網頁是會互相影響的。 流量下降的解說更新 請記住，排名不是靜態的。Google的搜尋結果本質上是動態的，因為開放網路本身隨著新的和更新的內容而不斷變化。這種持續的變化可能會導致自然搜尋流量的增加或減少。 排名小幅下降 小幅下降是指頂部結果中的排名發生小幅變化（例如，排名從 2 下降到 4）。在 Google Search Console 中，可能會看到流量大幅下降，但曝光總數卻沒有大幅變動。 位置的小波動可能隨時發生（包括返回位置，而無需執行任何操作）。事實上，如果您的頁面已經表現良好，Google建議避免進行徹底的更改。 排名大幅下降 排名大幅下降是指您發現多種術語的排名前十的結果顯著下降（例如，排名從前 10 下降到第 29 位）。 在這種情況下，請對整個網站（而不僅僅是單一頁面）進行整體自我評估，以確保它有用、可靠且以人為本。如果您對網站進行了更改，則可能需要一段時間才能看到效果：某些更改可能會在幾天內生效，而另一些更改可能需要幾個月的時間。例如，Google的系統可能需要幾個月的時間才能確定某個網站現在正在產生長期有用的內容。一般來說，您可能需要等待幾週，再次在 Google Search Console 中分析您的網站，看看您的努力是否對排名位置產生了有益的影響。 請記住，Google無法保證您對網站所做的更改會對搜尋結果產生明顯影響。如果有更多高品質的內容，它的排名將會繼續在SERP中領先。 不實用內容的影響 再加上之前提到的，Google有在 實用內容和 Google 搜尋結果常見問題 中提到：移除不實用的內容，是否能提升我其他內容的排名？ 我們的系統主要是在網頁層級運作，以便盡可能顯示最實用的內容，即使該內容所在網站同樣代管不實用的內容也不例外。話雖如此，要是網站中有特別多不實用的內容，可能會讓網站的其他內容在 Google 搜尋中的成效降低，但影響程度不一。移除不實用的內容，可能有助於提升其他網頁的成效。 結論就如同開頭所說的，網站內的網頁是會互相影響的。

日本近期流行的「ライブ会場を沸る」或是稱為「フロアを沸かす」的迷音AI短片，是怎麼製作生成的？下面我們用英文和影片帶你一步一步做，完全不用動腦。 （続いて英語でステップバイステップで説明します。操作手順動画も用意しているので、頭を使わずに簡単にできます。） 操作步驟 steps: Enter to Viggle AI's Discord server (https://discord.gg/viggle). Select any of these rooms named "animate" and click to enter. Type "/" to bring up a list of commands. Select "animate" from the list of commands. Upload your image. motion_prompt: type "$lil_yachty_stage_entrance". background: select "From template". finetune: select "On". Hit Enter or click on the submit button to send the command. Wait for approximately 1 to 5 minutes for the AI animation to be generated. 日本語操作手順： Viggle AIのDiscordサーバーに入る(https://discord.gg/viggle)。 任意の「animate」ルームを選択して、クリックして入る。 "/"を入力して、コマンドのリストを表示し、「animate」を選択します。 コマンドのリストから「animate」を選択します。 画像をアップロードします。 motion_prompt: "$lil_yachty_stage_entrance"を入力します。 background：「From

dark mode 的CSS寫法一直以來都不是很方便，在偵測使用者作業系統是不是dark mode的時候，我們可以用prefers-color-scheme來另外寫一套CSS。現在多了另一種寫法 light-dark() 。 prefers-color-scheme prefers-color-scheme寫法如下，當然還有很多東西要考慮，例如border、hightlight…等等，但為了方便說明，只用文字和背景顏色舉例。 :root { --text-color: #333; --background-color: #eee; } @media (prefers-color-scheme: dark) { :root { --text-color: #efefef; --background-color: #222; } } 新的語法 light-dark() light-dark()可以搭配color-scheme使用達到自動偵測使用者作業系統是不是dark mode： :root { color-scheme: light dark; --text-color: light-dark(#333, #efefef); --background-color: light-dark(#eee, #222); } 除此之外，還可以用input讓使用者自己選擇要不要用dark mode： :root { /* 偵測使用者作業系統 */ &:has(input[name="scheme"][value="light dark"]:checked) { color-scheme: light dark; } /* 不用 dark mode */ &:has(input[name="scheme"][value="light"]:checked) { color-scheme: light; } /* 使用 dark mode */ &:has(input[name="scheme"][value="dark"]:

Google一直致力於減少無益和非原創內容，近期更是如此。 根據Google官方的評估，結合此次更新和先前的努力，搜尋結果中的低品質、非原創內容將減少40%。若再加上核心更新可能會有大量的排名波動：Google宣稱，由於這次更新相當複雜，相較於一般核心更新，排名的波動更大，因為不同系統會全面更新並相輔相成。 大規模內容濫用 Goole 試圖禁止那些使用自動化工具產生的內容來操作搜尋排名，無論是 AI 還是真人都抓。 例如，提供的內容假裝有答案，但其實對使用者沒有用。 網站聲譽濫用 即受信任的網站託管低品質的第三方內容，以利用託管網站的良好聲譽。 除此之外，Google 也稍微降低了「連結」的重要性。 不再強調連接「重要」 Google的SEO指南的內容有稍做修改： 舊版本：Google uses links as an important factor in determining the relevancy of web pages. 新版本：Google uses links as a factor in determining the relevancy of web pages. 為連結操作所建立的內容 強調內容如果是為了操作連結和其它排名訊號，是沒有用的。 我們姑且猜測這句話的意思是PBN（一個專門為連結到另一個網站並提高其自然搜尋可見性而創建的網站。這個想法是「饋送」網站將連結資產傳遞回主網站，這將提高其權威性，從而提高其排名能力）。 與傳出連結相關的新訊號 任何意圖操縱 Google 搜尋結果排名的連結都可能被視為垃圾連結。這包含任何操縱指向您網站的連結或從您網站發出的連結。 結論 Google除了注意到AI工具的濫用之外，也對於連結好壞的判定更嚴格，甚至不惜降低重要性。 除了劣質的反向連結之外，刻意操作的反向連結和濫用的內部連結也會被Google抓出來重新審視。至於方法和判斷基準，還是那句老話：「對使用者有用、可解決使用者問題」。而反向連結也是很理想的看法：內容很優質，自然會有人分享你的網頁。 以上內容，我想我們可以濃縮成「使用者意圖」與「不要濫用排名訊號」。在AI技術越來越發達的現在，真正能提供使用者想要的訊息或解方的網頁內容，才是最重要的。 相關連結 Google處理搜尋中的垃圾內容、低

你維護的網站的網頁數是否有上千頁或上萬頁？如果答案是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的興起。其實不止如此，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 字串加密與解密簡單的寫法： // 加密函数 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'; 實際使用範例 // for example $tempVariable = 'oh nyo!'; $tempVariableEncrypt = encryptFunction($tempVariable, $encryptionKey); // mmdpiTHs1NnuNZrk7zxnWA== $decryptBack = decryptFunction($tempVariableEncrypt, $encryptionKey); // oh nyo! 這個方法可以簡單運用在存入資料庫，與取出資料庫的資訊給具有權限的人。

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的修正： const params = new Proxy(new URLSearchParams(window.location.search), { get: (searchParams, prop) => search

創造有用又可信任的內容，也就是我們常聽到的 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 和 replaceState，與後端互動的語法則是 jQuery 的 ajax。 Googlebot 會抓取無限滾動的內容嗎？ 答案是：會。 至於會抓到多深？根據我自己的觀察，可以抓到至少兩篇無限滾動後出現的文章，Google 還蠻厲害的。 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 regexp = new RegExp(botPattern, 'i'); var userAgent = navigator.userAgent; if (!regexp.test(userAgent)){ // infinit

如果你的網站客群是全世界，那麼在 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 也不失為一個好選擇。

最近才在上方的網址列發現站內搜尋這個功能…… 網址列站內搜尋功能展示 操作方法 只要在網址列輸入該網域後，再空一格就會出現站內搜尋的功能；而且，就算是使用 Google CSE 的站內搜尋網站也會出現。但是，並不是每個網站都能這麼順利出現這個功能。 輸入後出現的搜尋結果頁面 網站實裝猜測 我自己原本猜測是跟 WebSite 這個結構化資訊或使用者本身常不常去有關，但就算有設定也常去了，也不見得百分之百會出現這個功能，所以 chrome 的依據到底是什麼其實沒那麼肯定。 站內搜尋結構化資料 站內搜尋的結構化資料範例如下，其本上每個網站只有 url 和 target 欄位值不一樣而已，但要注意只需加在網站首頁就好了，不要每一頁都加。 { "@context": "https://schema.org", "@type": "WebSite", "url": "https://test.example.com", "potentialAction": [{ "@type": "SearchAction", "target": "https://test.example.com/search?q={search_term_string}", "query-input": "required name=search_term_string" }] } 你也可以看 Google 寫的 網站連結搜尋框 ，基本上大同小異。 有了這個設定，說不定還能在 SERP 出現搜尋欄，雖然一樣是不一定會出現，但怎麼想都賺。 Firefox 的建議網頁 順帶一提，如果使用一樣的方式在 Firefox 網址列操作的話，跟 Chrome 不同，會出現「建議網頁」。 Firefox 網址列的建議網頁

如果你在改善網站速度，對這句話想必一定很眼熟（沒錯，就是 PageSpeed Insights），但到底什麼是 next-gen？簡單來說就是 WebP、AVIF、JPEG2000、JPEG XR 等格式的圖片。 WebP WebP 目前是這四種格式中支援度最廣的格式，且支援去背和透明度。 它除了 IE11 之外，基本上都支援；而 safari 則要看版本夠不夠新（macOS 11）。 WebP 的瀏覽器支援度 另外，它有一個很像的名詞叫 WebM 影片格式： WebM 是一個由 Google 資助的專案（WebP 也和 Google 有關），目標是構建一個開放的、免著作權費用的影片格式檔。該影片格式能提供高品質的影片壓縮以配合 HTML5 使用。（ wiki ）用途基本上一樣是為了改善網頁載入速度。 AVIF Netflix 聲稱 AVIF 將會是下一代的圖像編碼演算法，並稱它對於他們的影音串流媒體網站而言，是取代 JPEG 格式的最佳選擇。 不過，相較於 2010 年就出現的 WebP，2019 年才誕生的 AVIF 支援度在2023年之後才追趕上來。 AVIF的瀏覽器支援度 JPEG 2000 JPEG 2000 比前兩者更早出現，副檔名是 .jp2 或 .j2c，跟 AVIF 一樣在當年被吹捧成下一代圖像的壓縮標準，但至今幾乎沒有網站在用，也只有 safari 有支援，其它瀏覽器完全不想理它。 JPEG2000 的瀏覽器支援度 JPEG XR、JPEG XL JPEG XR（JPEG extended range）是基於由 Microsoft 所開發的 HD Photo 的圖像格式，所以……基本上只有 IE9~IE11 和舊版本的 Edge 支援。 IE 專屬的 JPEG XR JPEG XL 則發表於 2017 年，但就目前為止的支援度是慘不忍賭，完全沒有瀏覽器支援。 實際運用 基本上，還是要靠 HTML 的 picture 來使用最安全，或者是寫程式判斷瀏覽器支援度，然後載入相對應的圖片格式。個人認為，目前使用 WebP + jpg/png/gif 的應對方式就夠了，頂多再加個 AVIF，但效益如何就自己判斷了。 再來就是 server 端有沒有設定宣告的問題。舉例來說，如果你是用 web.config 設定網站的話