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

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

最近遇到一個要讓 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 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 設定網站的話...

什麼是 favicon？ favicon 是 favorites icon 的縮寫，中文通常稱為頁面圖示（page icon）或網站圖標（website icon）；簡單一點來說，就是瀏覽器最上面各分頁會出現的圖案。 像我這個網站的favicon 是位可愛的吸血鬼 favicon 除了可以用傳統的 ico 檔，也可以用 png 檔，甚至可以用 SVG 檔。 為何要特地用 SVG 檔？ 用一般圖檔就好了，何必要再創作一個 SVG 檔呢？因為 瀏覽器有 dark mode 的存在 ，這個模式可能會讓網頁的 favicon 看不清楚，這就是我推薦使用 SVG 檔的原因，因為我們可以很輕易地在 SVG 檔中塞 CSS 語法進去調色，別的檔案格式沒有這種能力。 看到一看就知道沒去背的白底 icon 會讓我很焦慮， 以下為簡單的例子： <svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" width="64px" height="64px" viewBox="0 0 64 64" enable-background="new 0 0 64 64" xml:space="preserve"> <style> path{fill:#2858aa;} @media (prefers-color-scheme: dark) {path{fill: #23A6DE;}} </style> <path d="example"/> </svg> 「 prefers-color-scheme : dark」就是在 dark mode 下呈現的樣貌，寫法跟 media query 一樣。我們可以在括號範圍內設定一個比較亮的顏色（fill: #23A6DE）才不會讓使用者看不清楚。 favicon HTML 設定 在 HTML 的 head 標籤裡照這樣設...

若你在優化任何非網站的網址(Office文件、PDF、留言、Email、Google 我的商家、SERP結構化資料如 FAQ 中的網址)，除了在網址使用 #id (錨點)之外，Scroll to Text Fragment 或許是另一個可以考慮的方式。 URL Scroll to Text Fragment 是什麼？ 它的功能是在網址中設定文字，使用者點擊網址進入網頁後，可能看到被強調的文字，並將畫面移動到該文字處，文字高度在畫面中間。這並不是什麼新功能，早在 chrome 80 以後就出現在以 chrome 為核心的瀏覽器之中了。 如何創建？ 複製醒目顯示文字連結 在 chrome 90 之後的版本，網頁上選取（反白）文字之後按右鍵，就會出現「 複製醒目顯示文字的連結 」的功能，點擊該功能產生的連結，貼到任何除了該連結頁面之外的地方，被點擊後就可以產生上一段文字提到的效果。如果沒有該功能，可能是被設定成關閉，網址列輸入 chrome://flags 並按下enter後，找到 Copy Link To Text 後就能開啟該功能（enabled）。 如何關閉？ 但是，在最新版本的 chrome 中， chrome://flags 已經找不到 Copy Link To Text 這個指令了，換句話說就是沒辦法關閉這個功能，還請注意。 文字反白之後右鍵即可看見該功能   連結的架構與DIY 若不想透過 chrome 附加的功能直接設定使用的話，自己也可以設計出這種特殊網址，方法與錨點類似，不過是加上「 #:~:text= 」 完整結構： https://example.com#:~:text=[prefix-,]textStart[,textEnd][,-suffix] 方法1 整段文字： 只使用 textStart 的話是最簡單的使用方式： #:~:text=文字 ，它會當成要 highlight 的所有文字，就像 {這個連接} 的範例一樣。 方法2 文字區段： 你也可以打上兩段文字： #:~:text=文字1,文字2 ，分別代表開頭和結尾，它會找尋這一區段的文字 highlight，這裡也用 {這個連接} 示範一次。 方法3 多段文字： 可以使用「&」區隔： #:~:text=文字1&text=文字2 。但是個人不建議這樣做，畫...

看到一篇 談論1997年至今的 UX 發展 的翻譯文章，原文的作者是Mark Hurst，看完之後心有戚戚焉，推薦給大家一起看，力道雖然沒有「 真正發生過的恐怖IT故事 」強，但也一樣是很無奈的現況。 KORONE FALCON PUNCH 文章從1997年至今分成3個10年去描述 UX 產業的變遷。 UX 的定義已經從原本的 user experience，漸漸被 user exploitation 取代，網站不再以便利性為目標，而是網站擁有者的目的為目標：試圖以各種方式誘導或阻止使用者在網站上做某些事情。 就像中文的「設計」一樣，英文可以翻譯成 design，也可以翻成 calculating。 真實案例 該文用 Amazon Prime 和紐約市疫苗網站為例子： The cancellation procedure is long, and consists of six separate pages. On each separate page, the consumer is nudged toward keeping their Prime membership, even though they have began a procedure to end the agreement. ...This uncertainty is further strengthened by having to scroll through the page, which is full of text and graphics to show how cancelling the membership will mean the loss of many benefits. In the single biggest public health crisis in the world, New York can't build a usable vaccine website. The telephone - 1950s technology - is our best option, after 25 years of web development. Shameful. 從 UX 設計領導者 Amazon 帶頭墮落，默默道...

在 html 下 scroll-behavior: smooth 的好處如同它的語意，若使用者點擊頁面的描點超連結時，不會讓使用者「瞬移」，而是會產生如同在 JavaScript 寫 scroll animation 一樣的體驗，對使用者的操作相對友善。但當使用者在進入頁面時，網址就帶有描點(#)，可能會事得其反，破壞使用者體驗。 CSS 的載入方式 如果是傳統的直接載入或內嵌方法就可以跳出不用看了，但若是在 load 之後才用 JavaScript 載入，就有可能造成初始畫面位置並非描點的位置。比如出現下列這種情況： <link rel="preload" href="style.css" as="style"> <script> window.addEventListener("load", function() { var prload_css = document.querySelectorAll('link[as="style"]'); var i = 0; for (i; i < prload_css.length; ++i) { prload_css[i].rel='stylesheet'; } }); </script> 網址可能帶有 #title，預期讓使用者一開始看到 #title 元素在畫面之中，但 load 前後 #title 的位置不一樣，產生進入頁面且載入後，畫面往下滑動到比預期更下面的地方，讓 scroll-behavior: smooth 變成使用者體驗的殺手。 accesskey 操作 這個影響不大，只是當使用者鍵盤操作的時候，畫面會有一瞬間滑向該連結的效果出現。

Core Web Vitals（CWVs；網站使用體驗核心指標） Google 發表新的網站品質評估指標 Core Web Vitals ，目的是提供具有代表且一致性的網站品質數據，這些指標分別為：LCP、FID、CLS 與2022年新增的 INP。但在2024年，FID將正式被INP取代。 因為評估網頁速度體驗的方法百百種，而且很難把 UX 數據量化，而因為 CWVs 會成為 Google 搜尋排名 SEO 的因素之一，一些網頁檢測工具勢必會跟上這次提出的標準。 指標的檢測標準。圖片來自 blog.chromium.org 什麼是 LCP？ LCP是最大內容繪製元素(Largest Contentful Paint)，視窗可見範圍內最大內容元素的渲染時間。根據 LCP API 考慮的元素類型有： img 元素 在 svg 裡面的 image 元素 有 poster image 的 video 元素 使用 CSS url() 載入圖片的元素 包含文字節點的 Block-level 元素 什麼是 CLS？ CLS是累計版面配置位移(Cumulative Layout Shift)，可以想成頁面載入時的穩定度。CLS 會測量在頁面整個生命週期中發生的每個意外排版位移（layout shift），並將所有單獨排版位移的分數加總，分數在0到1之間。比如使用者才剛閱讀完一句話，突然上面跑出廣告把剛才閱讀的文字往下擠，或是想點擊取消按鈕，卻在下一秒位移按到確定，造成非常糟糕的使用體驗，都會讓分數增加。 什麼是 FID？ FID是首次輸入延遲(First Input Delay)，用戶首次與頁面互動（點擊連結、輸入欄、下拉選單、按鈕或 JavaScript 驅動的元件）到瀏覽器能夠回應該互動的時間。而當量測工具無法測量 FID 時，可以換成評估與 FID 關係密切的 總阻塞時間（TBT） 指標，因此優化 TBT 也可直接提高 FID 的品質。 但在 INP 出現之後，基本上就被其取代了，Google也宣布將在20...

行動裝置預設阻擋 icon font 勢必會成為趨勢，除非你也有處理未載入時的畫面呈現，或有沒有icon對使用者的 UX 都沒有影響(這裡要捫心自問，既然有沒有 icon 都可以，為何還要放icon)，否則只會有更多 browser 跟進如 firefox focus 這樣的瀏覽器或套件出現，就跟使用者主動安裝 adblock 是相同的道理。 Font Awesome 的升級 若你是使用 Font Awesome 且沒有時間處理這個問題，官方剛好有出一個快速解套的解決方案，讓開發者無痛從 4 升級到 5： Upgrading from Version 4 。 但這必需多載入  v4-shims.css  和  v4-shims.js ，對使用者而言就是多兩個 request ，所以有時間的話，還是全面改寫成正常的第5版會比較好，也就是不需要用CSS載入字體檔，只有JavaScript的版本(用JS產生SVG)。 就算第4版現在大部分的情況都能正常顯示，但由於 CSS 檔案肥大(因為包含字體檔)，加上沒有 font-display: swap; 的語法，通常都會拖慢載入速度。所以，放棄需要載入字體檔的icon，投入 svg 的懷抱吧！ 造成排版位移 網站若有使用其它字體 (例如 Google font) 的人都知道，就算有 font-display:swap 解決載入前後文字閃爍的情況，還是無法解決載入前後字體位移的問題，因為每種字體的大小與定位都有些微的不同。這個影響雖然不大，Google 強調的 CLS 看似也不把它當作問題，但這個問題確實存在。 還能更好 而前面提到直接貼<svg>的方式，難道第5版還不夠好嗎？ 在 chrome 的 Lightinghouse 測試中，有無載入第5版的 Font Awesome 速度分數最多可以差到20分，Time to Interactive (TTI)更可以相差到 8 秒之多，若又選用有載入字體的CSS，分數又會差更多。所以才又提了直接放<svg>的方法，既少了一個 request，又不用載入 Font Awesome，TTI 也從 12 秒降到 4 秒，但開發上會麻煩很多。 在考慮使用者體驗和 SEO 的當下，網頁的載入當然是越快越好，但開發...

Meta Description (網頁描述) Meta Description  為搜尋結果中，網站標題下方的敘述說明，能讓使用者初步瞭解你的網站大概擁有什麼內容，這應該大家都知道。而如果你有在經營 Facebook 粉絲團的話，「品牌故事」就會是你的 Meta Description。 提外話，請不要把你的產品命名為 AirJordanShoe ，這樣使用者在搜尋 air、jordan、shoe 這三個任一關鍵字時， AirJordanShoe 並不會被搜尋結果 match。 濫用 常常在工作中被要求，或是偷看別人家網站原始碼時會遇到，把網頁描述當 Meta Keywords 使用，或是混在一起用 (這裡就不提把 一整群 keywords 塞在 title 的網頁了)，大哥別鬧啦，小學生都會造句了，寫一段包含某些字的話很難嗎？ 別忘了 網頁描述的功能：「 讓使用者初步瞭解你的網站大概擁有什麼內容 」。你能想像使用者看你的網頁描述是一堆沒有組織的單詞會做何感想嗎？ 濫填關鍵字說明 誤導、欺騙 這點其實很少，大多是農場網站，其實短網址的詐騙更嚴重。 網頁描述的未來 所以 Meta Description 到底會不會步入 Meta Keywords 的後塵，在未來的某一天被google視為垃圾訊息？我們從兩點google對於網頁描述的政策來看吧。 自動產生 google對於沒有設定 或他們認為不好的 網頁描述之網頁，有可能會從網站內容中 截取後取代原本的網頁描述。 加長搜尋結果頁的網頁描述 從160字元增加到320字元，中文字的話一個字佔2~4個字元。 很顯然，因為網頁描述對 UX 來說太重要了，若將它視為垃圾訊息只會打google自己的臉。但也因為如此，對於網頁描述的評審機制將會越來越完善，說不定加到320字元只是截取技術改善前的暫時性措施，所以濫用關鍵字的網站在未來是不會得到好處的。 在之後不久，推論得到證實，Google馬上又改回160字元。 ----------------------------------------- 追記 而在2019年，google不斷強調Meta Description與網站排名並無直接關聯，只會影響「點擊意願」。換句話說，要先...