之前，通常都是知識頁面獨霸的情況比較多，所以才會看到許多B2B的網站會寫一些「什麼是xxx」之類的知識型內容企圖攻佔排名。 而在9月20日之後，產品介紹或網站首頁出現在搜尋結果中的機率變得越來越高，原因其實很簡單： 使用者意圖 。 使用者需求排名(Needs Met rating) 回去看 Google guideline 的修改記錄，的確有修改過部分的 頁面品質 和 需求滿足 (Needs Met)之間的關係說明。(guideline包含Page Quality、Understanding Mobile User Needs、Needs Met) 再加上之前 Google Search on 宣布的那些東西，未來的SEO並不像過去讓內容完整、有用，讓網頁速度快速那麼簡單。 使用者意圖 如同一開始提到的，可能沒什麼內容可言的登陸頁面(landing page)，也會出現在搜尋結果第一頁，只因為它對使用者而言是有用的。 使用者搜尋某個關鍵字是想要求知、購買、前往、求職或其它意圖，網站管理員搞錯方向的話，可能再努力也不會讓公司獲利提升。 重覆內容的取捨 自從2019年Google為了搜尋結果多樣性，讓同網域的網頁最多(通常)只顯示2筆，讓重覆內容的問題更被放大。 重覆內容的網頁有許多解決辦法，像是從軟到硬性的方式： 群組化：網頁互連、製造相關性、網址階層化 映射：利用 canonical 標籤，讓頁面權重只給單一頁面 合併：內容集中到同一頁 群組化 利用超連結或階層讓爬蟲了解這些內容的相關性，由Google自己去判斷。像是在內文中加上某個詞的說明連結，或是把某個相關事物加上連結在另外一頁討論，可以吃到子目錄的好處。 映射(canonical) 可以將權重無痛交付給某一頁，但Google未必會如你的意只把指向的那頁顯示在搜尋結果中，它還是有可能會把其它頁面顯示在SERP中。 合併 合併勢必可以吃到「段落排名」的好處，甚至有人試圖把使用者搜尋旅程縮短至1~3頁。 這三種方法各有好壞，但最終仍要回到使用者意圖，填滿使用者不需要的內容用處不大，不是用了之後排名就一定會提升。 網站速度 其實一直都是SEO指標，只是會再看得更仔細。2021年5月之後，Google會將新的 Core Web Vitals納入網頁排名因素。 簡單理解 Core Web Vitals 的 LC...

你已經熟悉這個以消費者為觀察核心的 Google Analytics 4 介面了嗎？ 相信不少人應該跟我一樣，在導入 GA4 之後，第一件事就是想辦法趕快把自訂事件和轉換設定好，但要怎麼設定？事件標籤、事件動作怎麼都不見了？ 從 GTM 介面直接新增自訂事件 在beta版消失之後，GTM的自訂事件介面變得比較簡單。首先，代碼設定選擇「Google Analytics (分析)」裡面的「GA4 事件」。 接著，在評估 ID 欄位填寫你的GA4評估 ID。 如果你不知道「評估 ID」在哪裡，你可以在GA4介面的「管理」→「串流」→「網頁串流詳情」找到它。 之後，自己想一個「事件名稱」填入欄位中，這裡我們取名為「edm_link_click」，並在下方的參數欄位填入要追蹤的參數（參數名稱隨便取，這裡取名「link_text」是為了讓大家知道，如果已經有同名的GA4參數，旁邊會出現一個勾勾）。 我想要寫在網頁上 如果想要把事件寫在網頁上，跟以前的GA有點像，在要觸發的地方將事件名稱push進dataLayer： window.dataLayer.push({'event': 'edm_link_click'}); 接著，到GTM介面的觸發條件區域先建立「自訂事件」，事件名稱要跟上面的code一樣填寫「edm_link_click」，接著一樣在代碼設定裡新增GA4事件，「觸發條件」就是前面建立的自訂事件。 當然，dataLayer.push 跟以前一樣能push其它參數，官方的 例子 也有提到。 回到 GA4 介面 待 GA4 收到資料之後，點擊「報表」→「參與」→「事件」，查看自己在 GTM 設定的「edm_link_click」有沒有出現在資料當中。 點擊該事件進去看相關的詳細資料，這樣子一個基本的自訂事件就算大功告成了。（自訂維度出現在資料中的時間並不固定，有可能數小時，也有可能一週之後才出現） 而詳細的數據必需到左列的「探索」或是到 Looker Studio（舊稱Google Data Studio）自己拉維度和指標才行。 定義內部流量 進到「資料串流」，選擇你要設定的串流名稱。 點擊「更多代碼設定」。 點擊「定義內部流量」，設定你的IP。traffic_type 值用預...

更新於2021-02-17 在「Google Presents: Search On 2020」中，Google提到在現代大量的資訊裡，AI 如何以新的方式幫助人們理解世界，讓搜尋結果更貼近需求。 其中，Google 談到了BERT的運用程度、拼字檢查、子項目，與一種基於段落(passage-based)的索引方式。這裡就段落進一步討論…… 段落排名(passages ranking) 因為有時候搜尋的答案可能會藏在網頁段落的深處，而這個段落並不是該頁面的主題，導致這個頁面雖然有提到該解答，但不會出現在搜尋結果中。而Google最近在排名方面取得了突破：不僅可以索引網頁，還可以索引頁面中的各個段落。 Google通過理解特定段落的相關性，而不僅僅是整個頁面，就能找到被埋沒在網頁角落但更貼近使用者需求的資訊。而這項技術也在全世界的搜尋中使用，預計將改善(影響)所有搜尋結果的7％。 有無使用新系統的差異。圖片來自Google blog 聽起來像是網頁主題要從一致性轉向多樣性，但好在有人更進一步地對相關人士詢問詳情。 Google對於段落系統的說明 SEL 為此直接詢問Google的發言人： Google仍在為整頁編制索引，但是Google的系統在確定最相關的內容時會考慮段落的內容和含義，而以前Google主要是從整體來看整個頁面。 這更像是排名的變化：Google不會在頁面上索引各個段落，但是最好將其劃分為頁面上的內容，並為排名目的更好地顯示這些段落。 儘管主題仍然是重要因素，但除了主題之外與之稍有不同或總體上不太相關的內容，該新系統也有助於識別並傳遞給查詢有特別匹配的使用者。 「精選摘要」標識了Google確定與查詢相關的文檔中最相關的段落；而新系統通過理解段落來確定任何網路文檔的相關性。 這對於使用者正在尋找的特定訊息如果隱藏在頁面的單個段落中而不是該頁面的主要主題的查詢中很有幫助，Google的新系統可以將這一點放大，並將該頁面的排名提高。 新系統將於今年晚些時候開始推廣，並在美國以英語開始，而後推廣於全世界。 另外也有人詢問 Google 的 Martin Splitt 關於段落排名的優化問題，他的回答是：網站管理員其實不需要做任何事情，而標題元素(h1,h2,h3...)確實能傳達頁面不同部分的含義，...

在一般情況下，往下滑動(往上撥)的時候，網址列和底部選單會收起消失，反之往上滑動則會出現。 overflow hidden 但在某些情況下，網頁設計師會將 html 和 body tag 的 CSS 設定成 overflow:hidden。 這時候網址列和底部選單不管怎麼滑動都不會消失，造成部分內容被擋住看不到也點不到，記得要多留一些空白空間。

如果你的網頁跟我一樣在9/30突然在Google SERP 消失，在 search console 把該網頁「要求建立索引」就可以解決。 網頁在9/30出現異常 以下為Google 在twitter的解釋 : We are currently working to resolve two separate indexing issues that have impacted some URLs. One is with mobile-indexing. The other is with canonicalization, how we detect and handle duplicate content. In either case, pages might not be indexed.... If a previously indexed page has gone, it might be the mobile-indexing issue, where we’re failing to select any page at all to index. If the canonical issue is involved, URL Inspector may show the URL as a duplicate & the Google-selected canonical will be different from it…. There’s no action to take with these issues on the part of site owners. We apologize for the issues here and are working rapidly to resolve them. We’ll update this thread as each is corrected. 總之，就是講一些大家都知道的規範，然後對於出現此問題深表歉意，並正在迅速解決這些問題。 而大多數網頁的確也在這之後復原。 10月20日，Google再次回應， 說它們已修復99%出問題的網頁 。 要求建立索引 「要求建立索引」是在Google search console中一種提交網頁給Google的方式，...

在 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 操作 這個影響不大，只是當使用者鍵盤操作的時候，畫面會有一瞬間滑向該連結的效果出現。

justify-content flex-start center flex-end stretch space-around space-between space-evenly align-items (use align-self when one item) flex-start center flex-end stretch baseline align-content (容器需要給高度才有作用) height: auto height: 26rem flex-start center flex-end stretch space-around space-between space-evenly 1 height:7.5 2 height:10 3 height:auto 4 height:auto 5 height:auto 並沒有用到 flex-direction 和 order 等等的屬性，所以沒有寫在裡面。 又或者，你可以在 codepen 操作： See the Pen CSS flex by cj ( @cjzopen ) on CodePen . 希望這些簡易的按鈕能對你有幫助。

在 parent 為 flex 的情況下，裡面放了許多圖片(img)，當視窗寬度小於這些圖片時，子層的圖片高度不會因為你下了 height:auto 而改變，造成圖片被拉長。 為什麼圖片會被拉長？ 因為 safari 預設的 flex 狀態和別人不太一樣，它的預設狀況為 stretch。 因此，parent 再加上 align-items:flex-start 就能解決這個只有 safari 版型會出狀況問題。 .d-flex{ display:flex; flex-wrap:wrap; } img{ width:25%; height:auto; } <div class="d-flex"> <img width="200" height="200" src="" alt=""> <img width="200" height="200" src="" alt=""> <img width="200" height="200" src="" alt=""> <img width="200" height="200" src="" alt=""> <img width="200" height="200" src="" alt=""> <img width="200" height="200" src="" alt=""> <img width="200" height="200" src="" alt=""> <img width=...

此功能新增在「Rendering」的最下面，可以模擬的模式有： ✨Blurred vision。 ✨Protanopia：無法感知任何紅光。 ✨Deuteranopia：無法感知任何綠光。 ✨Tritanopia：無法感知任何藍光。 ✨Achromatopsia：除了灰色陰影之外，無法感知任何顏色。 另外，他們也把「Audits」頁籤改名為「Lighthouse」，因為有太多人找不到 Lighthouse 在哪裡了 LMAO。 而表單元素外觀的更新……立意良善，基本上設計師依舊會設計自己想到的樣式。 提外話，Edge 的 DevTool 介面則有中文版本，且連更新訊息也是中文的👍。 Edge 的 DevTool 更新後的 bug svg favicon 裡面的 prefers-color-scheme 語法失效，造成瀏覽器上面的頁籤讀不到其中的語法。(同年 6月20日 chrome 已修正這項錯誤) <link rel="icon" href="/favicon.svg" type="image/svg+xml"> <!-- the svg file --> <svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" width="64" height="64" 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="M35.241,20.173c2.321-0...

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...

什麼是 emoji？ emoji 為日文 絵文字 えもじ 的發音，存在很久了，近年因 SNS (社群網路)和聊天軟體的發達，出現頻率越來越高，再加上各家瀏覽器的支援，讓 email 和網頁也能很簡單地加上 emoji 與使用者互動，但必需注意 emoji 在每個瀏覽器的外觀皆不大相同。 而另一個「顔文字」屬於字元表情，例如 ( ͡° ͜ʖ ͡°)，雖然也有相同的效果，但不在這次的討論範圍內。 emoji 查詢網站： https://getemoji.com/ 以前的 emoji 在 SERP 原本的 SERP 是除非使用者在搜尋欄加上 emoji，才會出現網頁中的 emoji，要不然它會自動把其過濾掉；也因為如此，就算加上 emoji，Google bot 也是直接跳過，不會錯判其語意。 現況的改變，其好處在哪裡？ 以這個頁面來說，網頁原始碼的 title 中存在 😆 ，搜尋結果並不會將它過濾掉。不確定它是不是 Google 暫時性的測試（ 事後證明為測試，現在已不包含， ）。 這是吸引更多使用者視線的方法之一， 但現在必需要在使用者搜尋時，關鍵字包含 emoji 才會顯示在 SERP 中（不只圖案，「emoji」這個字也可以）。 而 emoji 對 SEO 有任何影響嗎？答案是沒有任何影響。

chrome80, firefox75……以上，基本上各大知名的瀏覽器都可以支援。而雖然說是 3 種語法，但其實 clamp 可以被其它兩者取代。 font-size 的使用案例 Sass / SCSS 它的開發環境目前還不支援(2020-06)，所以若要用 Sass / SCSS 開發的話目前可以寫成： font-size: m#{i}n(m#{a}x(9vw,2.5rem),5rem); For Exmaple 這些語法可以用在 width、font-size、甚至是 grid 的 repeat()……等等的地方，例如： .example{ font-size:16px; /* if not support */ font-size: clamp(min, default, max); font-size: max(default, min); width: min(99.2px * 10, 100%); left: min(30%, calc(100% - 220px)); font-size: max(value1, value2, min); /* value1 and value2 are different unit. */ /* clamp() is not a necessity */ font-size: max(min(0.5vw, 0.5em), 1rem); } English bold 中文粗體 See the Pen CSS clamp()、max()、min() by cj ( @cjzopen ) on CodePen .

精選摘要的力量 網頁若佔據精選摘要的話，過去有「比排名第1名還多更多曝光與點擊機會的第0名」之稱，顯見它的利益有多大。 如何讓網頁成為精選摘要？ Google 並沒有提供這種功能。依照官方的說法，他們會根據使用者的搜尋要求來判斷網頁是否適合呈現為精選摘要。但可以從一些方法著手，讓自己的網頁稍微容易出現。 影片或歌詞 只要搜尋歌名就常常可以看見的精選摘要類型。 條列項次 有時使用者在查什麼情況下會發生什麼事，或者做某件事的步驟時，精選摘要就會出現副標和條列項次。 「是」的力量 一段話是精選摘要最常出現的格式，有時候還會包含一張圖片。簡短、明確、有力的一段話非常重要，且最好接在 h1 之後。 這段話常常有明確的答案，所以用字就很重要，例如「是」、「可」之類的用詞就非常明確有力，另外最好放在同一個 <p> 之中。 不超過三欄的表格（並非精選摘要） 有時使用想查詢例如產品規格的比較或是產品效益，精選摘要就會出現這種表格。但要注意 table 不要超過三欄，且盡量不要有表頭（thead），至少我沒看過很多欄位的精選摘要。 當然還有其它不常見的類型，例如直接顯示解答（不會顯示網頁）的類型，或是很像一段話的 段落排名 類型。 精選摘要的改變 以前不止出現在第0名，還常常重覆出現於第1名或第2名的位置，但這在 2020 年初的時候就改掉了，也跟 Google 的「同網站通常最多出現2次」的政策呼應。但這很明顯影響原本的覆蓋率，勢必對點擊率有重大衝擊。 另外，它也從原本的第0名變成「真正的第1名」，把第 10 名的網頁擠到第 2 頁。 精選摘要的隱憂 網頁成為精選摘要其實不見得完全是一件好事，為何那麼說？因為原本的知識圖譜與精選摘要就有出現 0 點擊搜尋的現象，使用者可能會看到自己想要的答案就離開了，連網頁連結都不會點，這對於要銷售產品或曝光廣告的網站來說，確實不是什麼好事。 所以，精選摘要也要看情況去追求，而不是盲目地覺得變成精選摘要的自己很厲害……是很厲害沒錯，畢竟獲得 Google AI 的認可，但好處其實見仁見智。 相關連結： Google 精選摘要的運作方式 精選摘要和您的網站