JavaScript 執行與 SEO 問題：搜尋引擎如何爬取動態內容與常見解決方向

最近...嗯，其實一直以來啦，很多人都在問 JavaScript 跟 SEO 的關係。

特別是現在一堆網站都用 React, Vue, Angular 這些框架，整個網站就像個 App。感覺很酷，但 SEO 好像就...嗯，有點麻煩。😅

今天就來隨便聊聊這個話題吧。不用想得太複雜，就當作在群組裡閒聊。

所以，Google 到底看不看得懂 JavaScript？

先說結論：看得懂，但不是完美的。🤔

以前大家都會說「JS 做的網站對 SEO 不好」，這在幾年前是真的。但現在的 Googlebot 聰明多了，它內建了一個叫 Evergreen 的東西，基本上就是一個最新版的 Chrome 瀏覽器。所以理論上，你在 Chrome 上能看到的，它大部分也都能看到。

不過，事情沒這麼簡單。Google 處理有 JS 的網頁，大致上是三個步驟：抓取 (Crawl)、轉譯 (Render)、建立索引 (Index)。

抓取 (Crawl)：Googlebot 先來你家門口，拿走最原始的 HTML 檔案。
轉譯 (Render)：如果它發現這個 HTML 很空，需要跑 JS 才能生出內容，它就會把這個網頁丟到一個「待處理」的清單裡排隊。等輪到它的時候，再用那個像 Chrome 的東西去跑 JS，把完整的畫面畫出來。
建立索引 (Index)：最後，把畫出來的完整內容，存到它的超大資料庫裡，這樣大家才能搜到。

問題就出在第二步，「排隊等待轉譯」。這個過程會花時間，也可能出錯。如果你的 JS 太複雜、跑太慢，或是中間呼叫的 API 沒回應，Googlebot 可能等得不耐煩就先走了。結果就是，它只看到一個空白頁，重要的內容跟連結都沒了。這也就是所謂的「爬取預算 (Crawl Budget)」被浪費掉了。

嗯，這就是所謂的「客戶端渲染 (Client-Side Rendering, CSR)」的問題。也就是把一堆 JS 丟給使用者的瀏覽器去處理，對伺服器來說很輕鬆，但對 SEO 跟使用者初次載入的速度來說，風險比較高。

為了解決這個問題，就出現了好幾種不同的「渲染」方法。大家可以把它們想像成...上菜的方式不同。

不同渲染方式的比較 (口語版)
渲染方式	這是什麼？	優點 👍	缺點 👎	適合誰？
客戶端渲染 (CSR)	給你一包泡麵跟熱水，你自己泡。也就是說，把 JS 丟給瀏覽器自己跑。	開發快、伺服器輕鬆。第一次載入後，頁面切換很快，像 App。	SEO 風險高，Google 可能沒耐心等泡麵泡好。使用者第一次進來要等比較久。	比較適合不需要 SEO 的後台系統、會員專區，或互動性超強的應用。
伺服器端渲染 (SSR)	廚房直接煮好一碗麵給你。伺服器先把完整的 HTML 弄好再送出去。	對 SEO 最穩，Google 一來就看到完整內容。	伺服器會比較累，成本高一點。開發也比較複雜。	內容常常變動的網站，像是電商、新聞網站、部落格。
靜態網站生成 (SSG)	預先做好一堆便當放著，誰來就直接給。在網站上線前，就把所有頁面都產生好。	速度最快，對 SEO 也超好。因為都是現成的。	如果內容一改，就要全部重新做一次便當，比較麻煩。	內容不太常變的網站，比如公司官網、文件、個人作品集。
動態渲染 (Dynamic Rendering)	看人給餐。看到是真人就給泡麵自己泡 (CSR)；看到是 Googlebot 就給煮好的麵 (SSR)。	算是一種折衷方案，專門為爬蟲服務。	設定有點麻煩，而且 Google 其實把它當作一種過渡時期的解法，不是長久之計。	舊的大型 JS 網站，沒辦法馬上整個改寫成 SSR 時的臨時解藥。