JavaScript SEO 終極指南(SEOer必看)

JavaScript 在近幾年來越來越興盛，主要的原因在於 JavaScript 能為網站帶來許多不同的特效，也為使用者體驗增加不少了效果。

而在美國，也有多達 80% 的電商網站使用 JavaScript 生成主要的內容，或是產生產品對應的連結，JavaScript 對於網站的必要性也是越來越大，所以與其為了 SEO 捨棄強大的 JavaScript，不如讓你的網站同時能擁有 JavaScript 也能做好 SEO。

就像 Google 的 John Mueller 所說：

The web has moved from plain HTML – as an SEO you can embrace that. Learn from JS devs & share SEO knowledge with them. JS's not going away.

— 🍌 John 🍌 (@JohnMu) August 8, 2017

並不是說，SEOer 一定要學會 JavaScript 這項程式語言，相反的，每位 SEOer 都必須去了解 Google 如何處理 JavaScript 所產生的內容，並且適當的解決相關問題。

– John Muller

Google 的搜尋引擎已經從早期的無法爬取 JavaScript 內容，到現在能夠渲染出 JavaScript 的頁面，Google 不斷優化著自己的搜尋引擎爬蟲，但仍有許多的不足是我們需要留意的。而許多在做 SEO 的行銷人也常常在問：『搜尋引擎真的能夠爬取 JavaScript 嗎？』

帶著這個疑惑，本篇從 Google 爬蟲原理出發，到如何建立友善爬蟲的 JavaScript 網頁。

從這篇文章中，你將會學到：

• Google 搜尋引擎如何爬取網頁內容
• 如何檢查網站的 JavaScript 問題
• JavaScript SEO 的最佳做法
• JavaScript SEO 常見問題有哪些

---

一、JavaScript 是什麼

講到 JavaScript 就要先講到同為網頁語言的 HTML 跟 CSS 語法，這三個語法各別為網頁的呈現起到不同的作用：

• HTML：網頁的骨架，就像人體、又或是汽車，先有了骨架後，才可以開始長肉。
• CSS：可以說是長在骨架上的肉，或是汽車上的顏色。
• JavaScript：類似控制器，像是汽車的引擎、煞車、油門，替網站增加更多的運作與特效。

HTML 將網站的架構建好；CSS 為各個部分著色、提供不同的呈現；而 JavaScript 替網頁呈現出不同的特效，並依據使用者呈現不同的效果。於是乎此三種網頁語言，讓網頁的呈現變的完整且方便有趣。

哪些內容可能是 JavaScript 產生的呢？

1. 主要內容
2. 導覽列
3. 內部連結
4. 商品評論
5. 分類篩選器

所以，如果這些內容在 JavaScript 上沒有處理好的話，很容易造成索引及排名上遇到困難。 

那如何檢查網頁上哪些內容是 JavaScript 所產生的呢

1. 透過 Chrome 擴充外掛檢查：

這邊介紹的工具叫做『Quick Javascript Switcher』，這個外掛可以直接開關網頁的 JavaScript 功能，只要你關掉 JavaScript 後，發現哪個部分的內容不見了，那很大程度就是那個內容是 JavaScript 所產生。

從下圖可以看到，當我們用外掛關掉 JavaScript 功能後，Pressplay 的主要內容消失不見了，那就代表說其中主要內容由 JavaScript 所產生。

2. 從開發者工具關閉

首先按下滑鼠右鍵找到『檢查』，你會進入開發者介面。

接著使用指令『Control + Shift + p』 (Windows) 或是『Command + Option + p』 (Mac)。

接著在指令中輸入 JavaScript，就會看到一個『Disable JavaScript』選項，點擊即可關閉 JavaScript，同理要再打開只需使用相同指令再點擊一次便可打開 JavaScript 功能。

為什麼網頁原始碼沒有 JavaScript 產生的內容！？

一般來說，我們在檢查網頁中的 meta 標籤、H 標籤等內容時，最常做的就是從網頁原始碼中去查看，也就是『右鍵 > 檢查原始碼』所呈現的內容。

而這個文件就是 HTML 文件，但這份 HTML 文件僅僅代表瀏覽器在解析頁面時的最初訊息，而 JavaScript 所產生的內容並不在一開始的 HTML 文件上。

所以，檢查網頁原始碼無法知道 JavaScript 更新後的動態內容。

此時就要介紹一下 HTML 加工後的 DOM 了，這邊為了不複雜化讀者理解簡單敘述一下，當你『右鍵 > 檢查』出來的東西便是加工過的 DOM（如下圖）。DOM 裡面會隨著你與網站的互動，將 JavaScript 所產生的內容加上去。

那如何區分 HTML 原始碼跟加工後的 DOM 呢？

p.s. 如果 Google 爬取頁面時無法完整呈現 JavaScript 產生的頁面，它至少可以索引為加載過的 HTML 原始碼。

在確認並且知道哪些內容屬於 JavaScript 所產生的之後，再來就是理解 Google 怎麼爬取 JavaScript，並且優化你的內容讓網頁排名上升。

---

二、Google 怎麼爬取 JS 網站

對於搜尋引擎而言，JavaScript 一直是 Google 努力在改善爬蟲技術，讓搜尋引擎索引並排名的目標之一。雖然 JavaScript 為使用者帶來更良好的體驗及使用，但是對於搜尋引擎而言卻不是一件容易的事情，請記得：

Google 永遠不保證索引 JavaScript 的內容

根據 onely 網站調查指出，許多大品牌網頁上 JavaScript 之內容未被索引的情況：

• Nike 網頁上 JavaScript 所產生的內容有 22％ 未被索引
• H&M 網頁上 JavaScript 所產生的內容有 65％ 未被索引
• Yoox 網頁上 JavaScript 所產生的內容有 92％ 未被索引

你可以想像，Yoox 在國外是知名電商網站，每個月可以有高達 1400 萬的流量，但是網站由 JavaScript 產生的內容竟然由高達 92% 是 Google 不會索引到的，由此可知這樣對 SEO 的影響可以有多大，損失又可以有多多。

但同樣的，也有把 JavaScript 所產生的內容處理的很好的網站，allrecipes.com 以及 boohoo.com 的網站分別讓 JavaScript 所產生的內容，被 100% 及 99% 的索引了，所以，只要方法得當，我們也能讓 JavaScript 與 SEO 兼顧。

Google 爬取頁面的過程

在早期搜尋引擎只需要下載 HTML 檔便可完整了解網頁內容，但由於 JavaScript 技術的崛起及普及，搜尋引擎甚至需要像瀏覽器一樣，以便他們以使用者的角度查看網頁內容。

而 Google 處理渲染的系統，被稱為 Web Rendering Service (WRS)，中文可以翻譯成網頁渲染服務，後面以 WRS 代稱，而 Google 也給出了一張簡化的圖作為說明。

簡單說明 Google 爬取步驟，傳統爬取 HTML 檔頁面時，每項元素都很好爬取，整個索引並排名頁面的過程也迅速：

1. Google bot 下載 HTML 檔
2. Google bot 從原始碼中提取 url 網址，並快速訪問這些 url
3. Google bot 下載 CSS 檔案
4. Google bot 將下載下來的資源送到 Google 的 Indexer
5. Google 的 Indexer 檢索頁面

但如果今天是爬取 JavaScript 所產生的網站內容的話，Google 會怎麼爬取呢：

1. Google bot 下載 HTML 檔
2. Google bot 在原始碼中找不到連結，因為 JavaScript 未被執行
3. Google bot 下載 CSS 及 JavaScript 檔案
4. Google bot 使用 WRS（渲染器，Indexer 的一部分）解析、編譯並執行 JavaScript 檔
5. WRS 從外部 API、資料庫獲取資料（data）
6. Indexer 可以索引內容
7. Google 發現新的連結，並將其加入爬取排隊隊伍之中（Googlebot’s crawling queue）。至此，只是一般 Google bot 爬取 HTML 頁面的第二步而已。

可以發現，為了渲染出頁面，Google 多許多步驟。再來講一下渲染過程中，Crawler、Processing、Renderer 及 Index 之重要節點。

---

三、Google 爬取 JavaScript 過程中重要節點

Crawler（爬蟲）

首先，crawler 會先向伺服器發送一段請求(request)，伺服器會丟出內容的檔案及其標頭(header)，然後 crawler 將它儲存起來。

而由於 mobile-first indexing 的關係，發送請求的可能大多都是來自手機版的爬蟲(mobile user-agent)，從 Google Search Console 上可以檢查到，你可以透過網址審查或是涵蓋範圍來知道現在是電腦版索引還是手機版優先索引的狀態。

然後有些網站會使用 user-agent detection，偵測使用者來到自己網站時，是用手機還是桌機、瀏覽器是什麼、瀏覽器版本的不同資訊，再根據這些資訊給使用者相對應的資訊，例如今天偵測到使用者是用手機版本的 chrome，便呈現手機版的頁面給使用者看。

需要注意的是，有些網站遇到爬蟲時可能會設定禁止該爬蟲爬取頁面，或是禁止特定地區 ip 的使用者查看頁面，這時候就要小心如果網頁沒設定好的話，很有可能爬蟲是看不到你的內容的喔。

記得從幾個方面測試看看 Google 爬蟲能否順利看到你的頁面：Google Search Console 的網址檢查器、手機友善測試工具以及複合式結果測試工具。

補充：從爬取過程那張圖可以看到，Google 將爬取後產生的頁面稱之為 HTML，但實際上，為了建構頁面內容，Google 其實爬取並儲存了相關所需的資源，像是 CSS 檔案、JS 檔案、API 端點、XHR requests等相關資源。

Processing（處理）

在 Processing 的過程中其實是非常複雜且處理很多事的，這邊重點講述 Google 處理 JavaScript 的過程。

1. 遵循限制性最高的要求

什麼是限制性最高的要求，就是假設今天 Google 渲染(render)出頁面後，原本 meta robots 的資訊是 index 被加入了 noindex，那麼 Google 將不會索引其頁面，甚至其它尚未被渲染的頁面，因為 JS 產生 noindex 這類的語法，則可能導致頁面無法被渲染。

2. 處理資源及連結（Resources and Links）

Google 並不像使用者那樣瀏覽頁面，Processing 的過程中有個很重要的工作便是檢查頁面上的連結（link）以及建構該頁面所需的檔案。

這些連結被拉出來，加到等待爬取的排隊序列中（crawl queue），反覆執行找連結、連結排隊、爬取連結，便是 Google 本身爬取整個網路世界的方式。

Google 透過 <link> 屬性，將建構頁面所需的資源，像是 JS、CSS 檔案拉出來。但是頁對頁的連結需要以特定的形式所呈現，才能被 Google 所抓取，那就是以 <a href=”連結”>的形式。

<a href="/good-link">能被爬取的連結</a>
<span onclick="changePage('bad-link')">不能被爬取的連結</span>
<a onclick="changePage('bad-link')" >不能被爬取的連結</a>
<a href="/good-1ink" onclick-"changepage('good-link')">能被爬取的連結</a>

如果你的連結是 JavaScript 所產生的話，那必須等到頁面被渲染後，爬蟲才能爬到。但有個風險就是，不一定頁面上的內容全數都能被成功渲染，有可能因為檢索預算不足的情況下渲染不到你的連結，所以務必留意連結的部分。

3. 刪除重複內容（Duplicate elimination）

Google 傾向將重複頁面刪除，或者是降低重複頁面的爬取優先級別。許多 JavaScript 所產生的網頁，都會有個 app shell models，可以想像他是最小化的HTML、CSS 及 JS 所組成，用戶可以在不同需求下再載入所需要的內容。

但這有一個問題就是，app shell models 只有最簡單少量的內容及原始碼，所以很有可能被 Google 誤判為重複性內容，也造成其頁面能夠被渲染的優先級下降，正確的內容無法被索引，以及錯誤的頁面被排名。

4. 緩存(caching)及其它

Google 下載頁面 HTML、CSS、JS 檔並渲染後，就會將其緩存。並且還有其它許多事情是 Google 會同時處理的，並不止於這些，但處理頁面的部分重點就在上述幾項。

Render queue （渲染序列）

接下來許多頁面即將被渲染， 所以在渲染排隊中，根據 Google 早期的說法，由於檢索預算的優化，渲染頁面並檢索會是比較後期的事，俗稱第二波索引(two waves of indexing)，但其實在近期 onely 的 Bartosz Goralewicz 與 John 及 Martin 講述到，第二波索引的影響其實越來越小，Google 在等待渲染的中位數時間也只有 5 秒鐘，可見 Google 在渲染並索引這一塊下了相當大的功夫，未來渲染也將與檢索能夠同步進行。

Renderer（渲染器）

還記得前面說的食譜與料理嗎？頁面在渲染前的 DOM 跟渲染後的 DOM 就像料理的食譜，以及做好的烤雞一樣，簡單講 DOM 就是像圖中那樹狀圖所呈現。

料理前的食譜是不會改變的，所以渲染前的頁面原始碼一樣不會因觸發 JavaScript 而改變，所以可以想像 Renderer 就是一個主廚，料理食譜並且產生一道料理（JavaScript 渲染出來的頁面），Renderer 為的就是去渲染出 JavaScript 相關內容。

要知道光是可以爬取整個網路世界成千上億的資料便是不容易，還要將其內容渲染出來耗費資源非同小可，根據 onely 指出，為了讓 JavaScript 內容被爬取、渲染並且索引，耗費的資源是一般 HTML 頁面的 20 倍，一定要格外小心。讓我們看看渲染器中有哪些重要的東西吧。

圖片來源：onely

1. 快取資源（Cache Resource）

Google 相當重度依賴快取，它會快取各種檔案，檔案快取、頁面快取、API requests 等，在被送到渲染器前就會先快取起來。因為不太可能每準備渲染一頁，Google 就下載一次資源，所以優先快取好的檔案資源就能快速渲染頁面。

但這也帶來幾個問題，有可能 Google 會快取到舊的檔案、舊版本的資源，導致在渲染頁面時出現錯誤。如果有這種狀況出現記得做好版本控制或是內容指紋，讓 Google 可以知道你更新了新的內容。

2. 沒有特定逾時時間（No Fixed Timeout）

很多網上謠傳渲染器只會用 5 秒渲染你的頁面，但其實並不然，Google 渲染時可能會加載原有快取的檔案，會有 5 秒的這一說法，主要是因為網址審查工具相關工具，檢測頁面時需要獲取資源所以需要設立合理的逾時時間。

There's no fixed timeout since rendering time can be quite different with cached resources. I'd double-check with the mobile-friendly test; if it works there, it should work for indexing too.

— 🍌 John 🍌 (@JohnMu) May 24, 2018

為了確保內容完整呈現，Google 沒有特地設定逾時時間，但為了爬蟲爬取及使用者體驗，更快的速度一定是更好的。

3. 渲染後，Google 看到了什麼？

這邊要提到一個很重要的點是，Google 並不會主動與網頁上的內容做互動，所以有些 JavaScript 的特效，需要使用者點擊或觸發的特效，是不會被 Google 所觸發，不會點擊更不會滾動頁面。

所以早期你們一定有聽過一個說法，不要使用瀑布流網頁的原因就是如此，因為 Google 不會捲動你也面的情況下，就無法觸發 JavaScript 所產生的內容，但 Google 也不笨喔，為了克服瀑布流，他們直接把機器人設定成一台超長版手機，這樣可以直接渲染出指定長度的內容。

可是一般需要 JavaScript 觸發的內容無法被 Google 渲染出來了喔，所以一定要特別注意，連結也不要出現 JavaScript 所產生之連結。

圖片來源：Ahrefs

---

四、如何打造 JavaScript 友善的網站

前面我們說到 JavaScript 現在越來越重要，也是越來越多網站使用的技術，所以與其完全避開使用 JavaScript，不如打造一個既能滿足開發者需求，又能爭取排名的 JavaScript 網站，讓來看看有哪些重要因素吧。

1. 可被爬取(Crawlability)：確保你的網站能保持良好的結構被爬取，並且爬蟲也能找到有價值的內容。
2. 可被渲染(Renderability)：確保頁面上的內容可以被渲染。
3. 爬取預算(Crawl budget)：Google 花了多少資源及時間渲染你的頁面

你的 JavaScript 內容對搜尋引擎足夠友善嗎？

首先檢查你要知道，你的網頁在 Google 眼中長的如何，那到底有哪些常見檢查方法，這些方法正確嗎？

1. 透過網址審查工具

Google Search Console 的網站審查工具可以呈現渲染後的頁面，其它官方的工具包含 AMP 測試工具、複合式搜尋結果測試等官方檢測工具，皆能呈現出渲染後的樣貌，這邊以手機友善測試工具為例。

可以看到螢幕截圖的畫面，顯示出 Google 渲染出的畫面，可以試著去看螢幕截圖，重要內容是否能夠被渲染出來。

渲染後的螢幕畫面

另一方，你可以從檢查工具的原始碼中查看內容是否有被渲染出來，直接搜尋內容、H 標籤等方式確認。

檢查重要元素有無渲染出來

記得從渲染後的 HTML（DOM – the rendered code）檢查：

• 主要內容是否可以呈現
• 推薦文章或推薦商品可以渲染出來嗎
• Google 還有沒有辦法看到其它重要元素

2. site 指令+關鍵字檢查

site 指令一般而言，大多用來檢查頁面在 Google 之收錄狀況，那如果說你直接『site:網址』後發現頁面有被 Google 收錄，你就能用這個方法檢查，因為 Google 其實會根據關鍵字修改搜尋結果頁頁上的 Description，所以當你輸入一段內文時，Google 其實很有可能根據你這一段內文呈現在 Description 上給你看。

以 pressplay 頁面為例，pressplay 上的課程簡介其實就是用 JavaScript 去產生的，下圖中可以看到，當我們將 JavaScript 功能關閉時，就會發現內容只剩下下面那一段，那麼要確認 Google 是否有索引到主要內容便可用『site 指令+關鍵字』做檢查。

只有上面紅框文字非 JavaScript 產生

而在連老師『每月給你SEO最新趨勢』這堂課中會發現，只要將 JavaScript 功能關掉，主要內容便只剩下其中紅框這一段，再來，複製一段 JavaScript 產生內容的文字『每年服務客戶橫跨12大產業，我們了解你的產業問題，資深SEO專家團隊陪你洞悉新·SEO』+ site:網址試試看。

透過關鍵字+網址的方式檢查

有沒有發現，其實 JavaScript 產生的內容 Google 是有渲染出來並且索引到的，但如果要更準確的檢查，建議還是要從官方的網址測試工具查看。

註：網址審查工具：Google Search Console 網址審查工具、結構化測試工具、複合式搜尋結果測試工具、AMP 測試工具、手機友善工具測試等。

Google 無法索引我的網頁怎麼辦

剛剛前面有提到，透過網址審查工具首先檢查 Google 渲染頁面的狀態為何，如果渲染未出現主要內容，那麼就可能導致內容無法被索引，你需要透過網址審查工具中的更多資訊，查看是否有資源遭到阻擋。

更多資訊中會告訴你哪些資源遭到封鎖

所以，先確保內容是否能被正確渲染後，再確保能否被索引，接著才能優化內容競爭排名。

Google 未能索引你網頁的原因：

• 渲染時逾時：是否載入時耗費資源過大，導致使用者及 Google 都無法渲染頁面
• 是否資源遭到阻擋：檢查 Robot.txt 文件，確認 Google 是否渲染時資源遭受阻擋
• Google 渲染時遇到問題：透過網址審查工具檢查頁面詳細狀況
• 重複頁面問題：是否有其它重複頁面導致內容無法被索引
• Google 無法發現該頁面：沒有內部連結，或是 Sitemap.xml 無該頁面導致 Google 無法發現
• 其它……

了解 Google是否能渲染你的內容，是否能正確索引，然後再爭取排名，一步步找出問題並解決它。 

---

五、渲染方式的不同：向 Google 展示 JavaScript 內容的不同方式

你以為你的頁面對 Google 來說只是渲染出來，然後查看內容、收錄並且排名嗎？其實沒那麼簡單，網頁渲染的呈現方式還能分為客戶端渲染（Client Side Rendering）、伺服器端渲染（Server Side Rendering）、混合式渲染等方式。

SSR（伺服器端渲染），通常對於 Google bot 以及使用者而言，能夠接受到完整的 HTML 檔案，內容也已經呈現好了，用食譜及料理的比喻說明，就是 Google bot 及使用者皆拿到做好的蛋糕。

CSR（客戶端渲染），近幾年來越來越流行的渲染方式，對於 Google bot 及使用者而言，最初拿到的頁面幾乎是空白的 HTML 檔案，隨著使用者的操作，JavaScript 非同步的產生並下載內容。用料理與食譜來比喻，Google bot 及使用者都只拿到了一份食譜，後面呈現端看使用者如何烘培蛋糕（操作網站）。

但是，Google bot 並不像使用者一樣，會有許多花裡胡哨的操作，Google bot 不會滾動、不會點擊更不會跟網站進行互動，所以如果你是全 CSR（客戶端渲染）的頁面一定要注意，解決方法如下。

1. 伺服器端渲染（SSR）

敞偌你的頁面因為 JavaScript 渲染問題導致頁面無法被索引，那強烈建議將重要頁面或是網站改成伺服器端渲染。

2. 動態渲染（Dynamic Rendering ）

有時候當然不可能說改全 SSR 就有辦法全部修改，於是動態渲染就變成當今蠻重要的一種渲染方式，能同時做到 CSR 想呈現的效果，又能同時達到 SEO 排名。

從下圖可以看到，網頁使用了全 JavaScript 所產生的內容，但是提供給 Google bot 的是另一靜態 HTML 頁面，很好的解決了 Google 爬蟲無法查看渲染頁面的問題。

動態渲染方式

以下三種服務可以很好的幫助你實現動態渲染功能：

• Prerender.io
• Puppeteer
• Rendertron

Google 官方文件也提供了轉譯原理、說明及方式，推薦大家看看。而下圖是各種渲染 JavaScript 的方法，其實大部分對於 Google 來說都是渲染的出來的，比較難的還是在 CSR（客戶端渲染）的部分，所以如果你是 CSR 建議導入動態渲染喔。

不同渲染方式的優缺點

---

六、如何建構一個友善 SEO 的 JavaScript 網站

其實這個小節的內容有部分你可能過去就知道了，但因為 JavaScript 的關係仍有部分不同。

允許 Google 爬取

如果連網頁都不能爬取、渲染的 JavaScript 資源都無法讀取的話，就不用說要排名囉，記得 Robots.txt 檔案不要禁止渲染相關資源，在 Robots.txt 檔案中加入以下指令：

User-Agent: Googlebot
Allow: .js
Allow: .css

On-page 優化

基本上 on-page 上的重要元素應該都要能夠被呈現出來，記得透過網址審查工具仔細檢查是否都有出現：

• Title/Description
• H 標籤
• 主要內容
• meta robots 標籤
• alt 標籤

JavaScript 網站最常出現的一個狀況是重複 Title/Description 被重複使用，記得可以從 Google Search Console 中的涵蓋範圍查看，又或者透過 Screaming Frog 等工具確認。

網址的點擊

前面雖然都有提到，但這邊還是正式說明一下，在 2018 年的 Google I/O 大會上便說到，因為 Googlebot 並不會去點擊、滾動或是與網頁做互動，所以如果你的連結是以 onclick 的方式呈現的話，將不會被 Googlebot 所爬取。



對 Google 而言，好連結與壞連結

同樣的，在導覽列上、分頁上、內容上一樣切記要使用 <a href> 的方式去呈現連結，才能確保 Google 會發現並爬取你的連結。

網址的更新

對於部分網頁採用 SPA（Single Page Application）方式所呈現的網頁，在更新網頁時，必須使用 History API，對於較早期的開發者而言，在更新網頁 Url 時採用的是片段（fragement）的方式，那網址就會變成我們常見的錨點，如下：

<a href=”#/products”>Our products</a>

但以『#』這種形式的連結對於 Google 來說並不會抓取喔！雖然早期開發出一種連結形式，將『#』取代成『#!』，但這種方式已經過時了，網址也會變得相當醜。

但是透過 History API 的方式就能讓網頁資訊變動時，連結才會變換成 Google 可爬取的形式，完整介紹可參考 Google 官方文件。

錯誤頁面

因為 JavaScript 框架是客戶端而非伺服器端，所以像是當 SPA 頁面產生錯誤時，並沒有辦法傳遞出 404 狀態碼到伺服器中，此時請採取以下其中一種方式解決：

• 使用 JavaScript 轉址到你原本就設定好 404 狀態碼及頁面不存在訊息之頁面
• 將錯誤頁面加上 noindex 標籤，並在頁面上呈現 『404 頁面錯誤』資訊，這樣子頁面就能被視作軟 404（soft 404）的狀態。

Sitemap

我們可能因為使用 JavaScript 產生了網站的許多內容，並沒有辦法說一次到位，解決所有 JavaScript 產生的 SEO 問題，此時 Sitemap.xml 有著重要的角色，就是告知 Google 網站重要的頁面有哪些，對於你提交的頁面，Google 可能會優先爬取。

但同時，你也必須確保 Sitemap 上的所有頁面連結沒有以下問題：

• 重複內容
• 被 canonical 指到別的頁面
• 404 錯誤頁面
• 301 轉址到其它頁面
• 空白頁面
• 等等…

這樣 Sitemap 才能真正的發揮他的作用，讓 Google 知道你重要的頁面。

總結

JavaScript 所產生的內容，已經不像過往幾年 Google 爬蟲完全無法理解，隨著開發技術的進步 JavaScript 也成為網頁開發的重要元素，所以不要急著排斥它。

記得首先，讓 Google 能夠渲染出你的頁面；其次，確認 Google 有順利索引你的頁面；接著，按著你一般優化 SEO 的方式，排除重複內容、優化內容，加強關鍵字排名。

這看似簡單的幾個步驟就花了很大一個篇幅在說明了，所以一起努力建立一個友善 SEO 的 JavaScript 網站吧！

參考資料：

• 瞭解 JavaScript 搜尋引擎最佳化 (SEO) 基礎知識
• 修正會影響搜尋體驗的 JavaScript 問題
• 導入動態轉譯
• Rendering on the Web
• JavaScript SEO: What You Need to Know
• The Ultimate Guide to JavaScript SEO (2020 Edition)
• JavaScript and SEO: The Difference Between Crawling and Indexing
• Making JavaScript and Google Search work together
• Rendering SEO manifesto – why JavaScript SEO is not enough
• JavaScript vs. Crawl Budget: Ready Player One
• Everything You Know About JavaScript Indexing is Wrong
• Static vs. Server Rendering
• Deliver search-friendly JavaScript-powered websites (Google I/O ’18)
• JavaScript SEO – How Does Google Crawl JavaScript