Ngôn ngữ

Hướng dẫn SEO trên Gatsby

Cách tối ưu website Gatsby cho tìm kiếm qua các chế độ kết xuất, Metadata API, canonical, sitemap, robots.txt, dữ liệu có cấu trúc và kiểm tra HTML đã triển khai.

Xuất bản lần đầu: 26 thg 6, 2026 · Cập nhật lần cuối: 22 thg 8, 2026 · Advanced
Ngôn ngữ
AIĐược viết bởiAI v2
1 tín hiệu bằng chứng trên trang này

Gatsby có bốn phương thức kết xuất: SSG (mặc định — trang được kết xuất trước thành HTML tĩnh khi chạy gatsby build), DSG (tạo tĩnh trì hoãn đến yêu cầu đầu tiên), SSR (kết xuất phía máy chủ theo từng yêu cầu qua Gatsby Functions) và tuyến chỉ chạy phía máy khách (kết xuất hoàn toàn trong trình duyệt). Phần lớn trang Gatsby dùng SSG, nên trình thu thập dữ liệu nhận HTML hoàn chỉnh ngay lần tải đầu mà không phải chờ hàng đợi kết xuất — nền tảng SEO tốt hơn nhiều so với ứng dụng React thuần phía máy khách. Tuy nhiên, lợi thế đó không áp dụng cho mọi chế độ: trang DSG và SSR tạo HTML ngoài bước dựng và cần phép kiểm tra production riêng; tuyến chỉ chạy phía máy khách không nên được mặc định là cung cấp nội dung riêng theo tuyến trong HTML ban đầu. Dù dùng phương thức nào, Gatsby vẫn gửi toàn bộ môi trường chạy React (~200KB+) và hydrate phía máy khách — đây là chi phí Core Web Vitals, không phải vấn đề khả năng thu thập dữ liệu. Cách quản lý metadata hiện hành là Gatsby Head API tích hợp sẵn (v4.19+), hoạt động trên cả bốn phương thức và thay thế gatsby-plugin-react-helmet. Các lỗi thường gặp gồm canonical kép, trang nháp hoặc mồ côi lọt vào sitemap, thiếu văn bản thay thế, sitemap chỉ được tạo trên production, chưa quyết định rõ sitemap và phép kiểm tra production cho tuyến DSG/SSR/chỉ chạy phía máy khách, cùng rủi ro bảo trì chậm lại kể từ khi Netlify mua Gatsby năm 2023.

Tóm tắt — Gatsby có bốn tùy chọn kết xuất: SSG mặc định, DSG, SSR và route chỉ phía máy khách; chúng không đưa nội dung vào HTML thô theo cùng một cách. SSG tạo sẵn HTML tĩnh lúc build (gatsby build), trước yêu cầu đầu tiên của trình thu thập. DSG trì hoãn tạo trang đến yêu cầu đầu tiên; SSR tạo trang trên máy chủ cho từng yêu cầu; route chỉ phía máy khách không kết xuất nội dung riêng cho route trước khi trình duyệt chạy JavaScript. Mọi đường dẫn đều hydrate gói React đầy đủ (~200KB+), gây chi phí Core Web Vitals chứ không phải khả năng thu thập. Cách quản lý metadata hiện tại là Gatsby Head API tích hợp (v4.19+), hoạt động với cả bốn đường dẫn và thay thế gatsby-plugin-react-helmet. Các lỗi thường gặp gồm canonical kép, trang nháp/mồ côi lọt vào sitemap, sitemap chỉ có ở production, thiếu alt text trên GatsbyImage, dấu gạch chéo cuối không nhất quán và route DSG/SSR/chỉ phía máy khách chưa được kiểm tra production. Sau thương vụ Netlify mua Gatsby năm 2023, tốc độ bảo trì cũng giảm mạnh.

Bốn tùy chọn kết xuất của Gatsby và ý nghĩa đối với SEO

Google xử lý trang JavaScript qua ba giai đoạn: thu thập, kết xuất rồi lập chỉ mục. Kết xuất diễn ra trong một lượt riêng từ hàng đợi dùng Chromium không giao diện. Hướng dẫn của Google nói rõ vì sao không nên phụ thuộc vào bước này: “Server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript.” (bản dịch) «Kết xuất phía máy chủ hoặc kết xuất trước vẫn là lựa chọn tốt vì giúp website nhanh hơn cho người dùng và trình thu thập, đồng thời không phải bot nào cũng chạy được JavaScript.»

Website Gatsby không phải lúc nào cũng là HTML tĩnh tạo lúc build. Gatsby hỗ trợ bốn đường dẫn kết xuất riêng, chọn theo trang hoặc template Evidence for this claim gatsby build writes production output, including generated HTML, to the public directory. Scope: Gatsby production builds. Confidence: high · Verified: Gatsby CLI: build :

  • SSG (Static Site Generation) — mặc định. gatsby build xuất HTML tĩnh đã kết xuất đầy đủ vào /public. Lần tải HTML thô đầu tiên của Googlebot đã có văn bản, liên kết và metadata. Đây là đường dẫn an toàn, rủi ro thấp mà phần lớn trang Gatsby dùng.
  • DSG (Deferred Static Generation). Việc tạo trang được trì hoãn đến yêu cầu đầu tiên, hữu ích cho website có rất nhiều trang ít lưu lượng khiến một lần build đầy đủ quá chậm. HTML chưa tồn tại trước yêu cầu đầu tiên, nên phải kiểm tra riêng hành vi yêu cầu đầu và cache.
  • SSR (Server-Side Rendering). Trang được kết xuất cho từng yêu cầu bằng dữ liệu tại thời điểm yêu cầu qua Gatsby Functions. Cần kiểm tra production về mã trạng thái, header cache, timeout và nội dung trình thu thập thấy khi phản hồi rỗng hoặc lỗi.
  • Route chỉ phía máy khách. Nội dung riêng cho route không có trong HTML ban đầu mà chỉ xuất hiện sau khi JavaScript chạy. Đây là thiết kế phụ thuộc JS, phù hợp với nội dung bị chặn/xác thực nhưng không phù hợp với nội dung cần được lập chỉ mục.

React hydration (ReactDOMClient.hydrateRoot()) chạy phía máy khách trên HTML do bất kỳ đường dẫn nào tạo ra, chỉ để thêm tính tương tác. Quá trình này giống nhau với mọi đường dẫn kết xuất và là mối quan tâm riêng với cách trang được tạo.

Ngược lại, ứng dụng React thuần phía máy khách phục vụ <div id="root"> trống và phụ thuộc vào trình duyệt hoặc bộ kết xuất để tạo trang. Phần lớn trang Gatsby mặc định gửi HTML có ý nghĩa; đó là lợi thế lập chỉ mục thực sự, nhưng thuộc về từng trang chứ không phải bảo đảm của framework. Tùy chọn kết xuất và công cụ hình ảnh không tự bảo đảm Core Web Vitals, lập chỉ mục hay thứ hạng; hãy xác minh đầu ra production của từng route.

Điểm đánh đổi chung của SSG, DSG và SSR nằm ở hiệu suất, chứ không phải khả năng thu thập dữ liệu: Gatsby gửi toàn bộ môi trường chạy React đến mỗi trang rồi hydrate lại trang đó. Phần dưới sẽ phân tích kỹ hơn vấn đề này và so sánh Gatsby với Astro.

Gatsby Head API so với gatsby-plugin-react-helmet

Đây là câu hỏi quan trọng nhất để xác định một dự án Gatsby SEO có đang triển khai theo cách hiện đại hay không: “are you doing it the modern way?” (bản dịch) «Bạn có đang làm theo cách hiện đại không?»

Cách cũ — gatsby-plugin-react-helmet. Trong nhiều năm, cách tiêu chuẩn để đặt <title>, mô tả meta và các thẻ head khác là dùng thư viện react-helmet cùng plugin này. Vai trò của plugin là cung cấp hỗ trợ SSR cho react-helmet — nếu không có nó, tiêu đề và thẻ meta chỉ xuất hiện sau khi JavaScript chạy, thay vì có sẵn trong HTML thô, khiến giải pháp mất đi mục đích SEO. Cách này vẫn hoạt động, nhưng có những vấn đề đã biết với React Hooks và cơ chế kết xuất đồng thời, cùng lỗi tiêu đề ở thẻ trình duyệt chạy nền mà bạn phải khắc phục bằng defer={false}.

Cách hiện đại — Gatsby Head API (v4.19+). Gatsby hiện có sẵn một cơ chế để thêm các phần tử head: xuất một hàm có tên Head từ bất kỳ tệp trang hoặc mẫu nào. Evidence for this claim Gatsby pages and templates can export a named Head function to add head elements. Scope: Gatsby Head API. Confidence: high · Verified: Gatsby: Head API 

export const Head = () => (
  <>
    <title>Page Title</title>
    <meta name="description" content="..." />
  </>
)

API này nhận các prop hữu ích — location.pathname, params, data (từ truy vấn GraphQL của trang) và pageContext — đồng thời loại bỏ các thẻ trùng nhau nếu chúng có cùng prop id (thẻ sau cùng được giữ lại). Tuy vậy, việc chạy đồng thời hai cơ chế quản lý thẻ head khác nhau (Head API cùng một lệnh gọi react-helmet còn sót lại) vẫn có thể gây xung đột dù đã có tính năng loại bỏ trùng lặp. Head API chỉ hoạt động trong tệp trang và mẫu, không hoạt động trong các component tùy ý. So với react-helmet, nó không cần gói bên thứ ba hay lớp bọc Provider, đồng thời giữ thứ tự thẻ ổn định khi React 18 kết xuất luồng. Hãy dùng Head API cho mọi dự án mới và lập kế hoạch chuyển đổi các dự án hiện có.

Head API hoạt động theo cùng một cách trên cả bốn phương thức kết xuất — SSG, DSG, SSR và tuyến chỉ chạy phía máy khách đều hỗ trợ xuất một hàm Head. Điểm khác biệt là thời điểm kết quả của hàm này xuất hiện trong phần HTML mà trình thu thập dữ liệu có thể tải: với SSG, nó được đưa vào ngay khi dựng trang; với DSG và SSR, nó được tạo ở lần yêu cầu đầu tiên hoặc ở từng yêu cầu; còn với tuyến chỉ chạy phía máy khách, nó hoàn toàn không có trong HTML ban đầu. Đừng cho rằng “I added a Head export” (bản dịch) «Tôi đã thêm một hàm xuất Head» đồng nghĩa với “this is in the raw HTML for every route” (bản dịch) «Nội dung này có trong HTML thô của mọi tuyến». Hãy kiểm tra đầu ra thực tế trên môi trường sản xuất (view-source: hoặc curl) cho từng phương thức mà mỗi tuyến sử dụng, thay vì chỉ kiểm tra một trang đại diện.

Lỗi “meta tags in DevTools but not in source” (bản dịch) «Thẻ meta có trong DevTools nhưng không có trong mã nguồn». Đây là một triệu chứng kinh điển của lỗi Gatsby SEO: tiêu đề và thẻ meta xuất hiện trong Chrome DevTools nhưng lại không có trong view-source:. Nguyên nhân là DevTools hiển thị DOM đã được hydrate (sau khi JavaScript chạy), còn chế độ xem mã nguồn hiển thị HTML thô. Nếu thẻ chỉ xuất hiện trong DevTools, component SEO đang được kết xuất phía máy khách thay vì được đưa vào đầu ra tĩnh của Gatsby — thường vì nó được dùng như một component thông thường, thay vì làm hàm Head của trang hoặc nằm trong hàm đó. Luôn xác minh trong HTML thô, không chỉ trong DevTools.

Kết nối component SEO với lớp dữ liệu GraphQL

Lớp dữ liệu của Gatsby dùng GraphQL; đây là cách bạn đưa metadata vào các trang.

  • useStaticQuery lấy các giá trị mặc định dùng cho toàn trang web từ siteMetadata (tiêu đề, mô tả, siteUrl) được định nghĩa trong gatsby-config.js.
  • Truy vấn GraphQL ở cấp trang truyền thẳng prop data vào hàm xuất Head — không cần thêm bước kết nối nào.
  • Mẫu triển khai tiêu chuẩn là prop || giá trị dự phòng trong siteMetadata: dùng giá trị riêng của trang nếu có, nếu không thì dùng giá trị mặc định của trang web.

Một hàm xuất Head nhận dữ liệu trang có dạng như sau:

export const Head = ({ data }) => (
  <>
    <title>{data.post.title}</title>
    <meta name="description" content={data.post.excerpt} />
  </>
)

Sitemap: gatsby-plugin-sitemap và những điểm dễ mắc lỗi

Cài đặt gatsby-plugin-sitemap rồi cấu hình trong gatsby-config.js. Có một số điểm dễ gây nhầm lẫn:

  • Plugin tạo sitemap-index.xml, không phải /sitemap.xml. Hãy gửi URL của tệp chỉ mục trong Google Search Console — đừng gửi /sitemap.xml rồi kỳ vọng URL đó tồn tại.
  • Plugin chỉ chạy trong bản dựng production. Nó không làm gì cả khi bạn chạy gatsby develop. Để kiểm thử, hãy chạy gatsby build && gatsby serve. Nhiều báo cáo “my sitemap is missing” (bản dịch) «Sitemap của tôi bị thiếu» thực chất chỉ có nghĩa là “I never ran a production build.” (bản dịch) «Tôi chưa từng chạy một bản dựng production.»
  • createLinkInHead: true theo mặc định tự động thêm tham chiếu đến sitemap vào phần head của HTML.
  • Plugin luôn loại trừ /dev-404-page, /404 và /offline-plugin-app-shell-fallback.
  • Google bỏ qua <priority> và <changefreq> — tài liệu của plugin nêu rõ điều này. Thay vào đó, hãy tập trung cung cấp giá trị <lastmod> chính xác.
  • entryLimit mặc định là 45 000 URL cho mỗi tệp.

Bạn phải tự loại trừ bản nháp. Gatsby dựng mọi nội dung nó tìm thấy, vì vậy nội dung nháp sẽ đi thẳng vào sitemap nếu bạn không lọc. Hãy lọc trong gatsby-node.js bằng điều kiện GraphQL (e.g. loại trừ mục không có ngày xuất bản), không phải bằng cách ẩn nội dung trong một component React — đến lúc đó trang đã được dựng và liệt kê.

Các tuyến DSG, SSR và chỉ chạy phía máy khách cần một quyết định rõ ràng về sitemap. gatsby-plugin-sitemap phản ánh những gì plugin có thể thấy tại thời điểm dựng. Trang SSG khá đơn giản — nó tồn tại dưới dạng tệp tĩnh nên đương nhiên có thể được đưa vào sitemap. HTML của trang DSG chưa tồn tại ở thời điểm dựng (nó được tạo ở yêu cầu đầu tiên), trang SSR không bao giờ có một tệp HTML cố định, còn tuyến chỉ chạy phía máy khách ngay từ đầu đã không có nội dung riêng theo tuyến để lập chỉ mục. Đừng mặc định rằng các tuyến này có trong sitemap (hoặc nên có) chỉ vì tuyến tồn tại. Hãy quyết định cho từng trang xem nó có thuộc sitemap hay không, rồi xác minh rằng sitemap-index.xml được tạo ra thực sự phản ánh quyết định đó thay vì một phỏng đoán tại thời điểm dựng.

robots.txt: gatsby-plugin-robots-txt

gatsby-plugin-robots-txt tạo robots.txt tại thời điểm dựng. Chi tiết hữu ích cho SEO là khả năng nhận biết môi trường: plugin đọc process.env.GATSBY_ACTIVE_ENV, sau đó đọc process.env.NODE_ENV, nên bạn có thể áp dụng quy tắc khác nhau cho từng môi trường. Trường hợp sử dụng kinh điển là chặn trình thu thập dữ liệu trên các bản triển khai xem trước hoặc theo nhánh của Netlify, để URL staging không vô tình được lập chỉ mục trong khi môi trường production vẫn cho phép thu thập dữ liệu.

URL canonical và lỗi canonical kép

Có hai cách khả thi:

  1. gatsby-plugin-canonical-urls thêm một <link rel="canonical"> vào mỗi trang. Đặt stripQueryString: true để /blog?tag=foo và /blog không bị coi là hai trang đã canonical hóa riêng biệt — đây là lựa chọn được khuyến nghị cho hầu hết trang web.
  2. Head API, tự đặt URL canonical từ location.pathname:
export const Head = ({ location }) => (
  <link rel="canonical" href={`https://example.com${location.pathname}`} />
)

Lỗi canonical kép. Đây là một lỗi đã biết và rất dễ gặp: nếu bạn dùng gatsby-plugin-canonical-urls đồng thời với thẻ canonical của react-helmet, trang sẽ xuất ra hai thẻ <link rel="canonical">. Hãy chọn một cơ chế duy nhất. (Nếu bạn dùng react-helmet, gatsby-plugin-react-helmet-canonical-urls là lựa chọn có nhận biết helmet; nếu dùng Head API, hãy đặt canonical tại đó và bỏ plugin.)

Dấu gạch chéo cuối URL. Trang Gatsby có thể truy cập được cả khi có lẫn không có dấu gạch chéo ở cuối. Component <Link> của Gatsby dùng định tuyến History API phía máy khách, nên bỏ qua chuyển hướng 301 phía máy chủ mà bạn thường dùng để chuẩn hóa dấu gạch chéo cuối URL. Hãy chọn một dạng, thực thi nó ở cấp máy chủ lưu trữ/CDN và giữ URL canonical nhất quán với dạng đó.

Image SEO: gatsby-plugin-image

gatsby-plugin-image thực sự là một trong những điểm mạnh của Gatsby. Plugin cung cấp hai component:

  • StaticImage — dành cho hình ảnh có đường dẫn đã biết và được viết cố định tại thời điểm dựng.
  • GatsbyImage — dành cho hình ảnh động lấy từ GraphQL.

Plugin tự động tạo nhiều kích thước, định dạng WebP/AVIF, tải trì hoãn và các điểm ngắt (750/1080/1366/1920px). Nó cũng tạo ảnh giữ chỗ (làm mờ, dùng màu chủ đạo hoặc SVG đồ theo nét) để dành sẵn không gian và ngăn Cumulative Layout Shift — một chỉ số Core Web Vitals. Nhờ kích thước được đặt trước, bạn tránh được CLS; các định dạng hiện đại cùng tải trì hoãn cũng giúp cải thiện LCP.

Điều duy nhất plugin không làm là viết văn bản thay thế. Lần nào bạn cũng phải tự thực hiện việc này — thiếu văn bản thay thế trên GatsbyImage là một trong những sơ suất Gatsby SEO phổ biến nhất. (Bạn đang chuyển từ gói gatsby-image cũ? Có sẵn một codemod: npx gatsby-codemods gatsby-plugin-image.)

Dữ liệu có cấu trúc (JSON-LD)

JSON-LD là định dạng dữ liệu có cấu trúc Google ưu tiên. Trong Gatsby hiện đại, cách gọn gàng để thêm định dạng này là dùng một thẻ script qua Head API:

export const Head = ({ data }) => (
  <script type="application/ld+json">
    {JSON.stringify({
      "@context": "https://schema.org",
      "@type": "Article",
      "headline": data.post.title,
    })}
  </script>
)

gatsby-plugin-next-seo cung cấp các component JSON-LD dựng sẵn nếu bạn không muốn tự viết. Cần làm rõ một nhầm lẫn thường gặp: gatsby-plugin-manifest không phải là plugin dữ liệu có cấu trúc — nó tạo tệp manifest cho ứng dụng web PWA (biểu tượng, màu chủ đề), hoàn toàn không liên quan đến schema.

React bundle và Core Web Vitals

Đây là điểm yếu thực sự của Gatsby so với các trình tạo trang không gửi JavaScript.

  • Hydration toàn phần (mặc định trong Gatsby 1–4) hydrate toàn bộ cây React và gửi môi trường chạy React nặng 200KB+ đến mỗi trang. HTML đã được kết xuất trước nên điều này không ảnh hưởng đến khả năng thu thập dữ liệu, nhưng chắc chắn ảnh hưởng đến tốc độ tải và CWV.
  • Hydration từng phần (Gatsby 5, thử nghiệm) chỉ hydrate các component được đánh dấu "use client", còn phần còn lại giữ nguyên dưới dạng HTML tĩnh; nhờ đó giảm lượng JavaScript được gửi và trực tiếp cải thiện TTI cùng CWV. Những hạn chế là đáng kể: chỉ hoạt động trong bản dựng production, vẫn ở giai đoạn beta và không tương thích với emotion, styled-components cùng gatsby-plugin-offline.

Điểm cần ghi nhớ: tải trọng JavaScript của Gatsby là vấn đề về hiệu suất, không phải về khả năng lập chỉ mục. Googlebot vẫn kết xuất JavaScript để đánh giá các tín hiệu trải nghiệm trang, nên gói mã có thể làm giảm CWV dù nội dung vẫn được lập chỉ mục tốt.

So sánh Gatsby và Astro về SEO

Nếu hôm nay bạn đang chọn một framework tĩnh, đây là phép so sánh quan trọng nhất đối với SEO.

Khía cạnhGatsbyAstro
JavaScript gửi đến trình duyệt200KB+ (toàn bộ môi trường chạy React)~5KB (chỉ các đảo tương tác)
Mô hình kết xuấtSSG → SPA (hydration toàn phần)SSG → MPA (mặc định không hydrate)
Tốc độ dựng (40 trang)2–3 phútDưới 10 giây
Hệ sinh thái plugin SEOTrưởng thành (gatsby-plugin-*)Đang phát triển
Ảnh hưởng đến ngân sách thu thập dữ liệuCao hơn (Google phải kết xuất nhiều JavaScript hơn)Thấp hơn
Tương lai của frameworkChưa chắc chắn (thuộc sở hữu Netlify, hoạt động chậm lại)Tích cực, đang phát triển

Cả hai đều kết xuất trước HTML có thể lập chỉ mục — ở điểm này chúng ngang nhau. Khác biệt nằm ở chi phí JavaScript: các đảo của Astro chỉ gửi một phần nhỏ lượng JavaScript; một bài so sánh của Vaihe mô tả lợi ích này là “Reduced JavaScript execution conserves crawl budget and accelerates page scanning.” (bản dịch) «Giảm lượng JavaScript phải thực thi giúp bảo toàn ngân sách thu thập dữ liệu và tăng tốc quá trình quét trang.» (Có một lưu ý lịch sử theo chiều ngược lại: tại thời điểm so sánh, tính năng xử lý ảnh của Astro chưa tự động thêm chiều rộng/chiều cao nên phát sinh cảnh báo Lighthouse — hãy kiểm tra tài liệu Astro hiện tại vì vấn đề này có thể đã được giải quyết.)

Để có bối cảnh so sánh rộng hơn cho toàn lĩnh vực, hãy xem trung tâm về trình tạo trang tĩnh.

Nhìn thẳng vào quỹ đạo bảo trì của Gatsby

Tôi sẽ không tô hồng vấn đề này, nhưng cũng không cường điệu nó thành thảm họa.

Netlify mua lại Gatsby Inc. vào tháng 2 năm 2023. Gatsby Cloud đã ngừng hoạt động và khách hàng được chuyển sang Netlify; Netlify tuyên bố thương vụ này sẽ “not impact Gatsby JS.” (bản dịch) «không ảnh hưởng đến Gatsby JS.» Kể từ đó, hoạt động phát triển chậm lại rõ rệt. Một thảo luận cộng đồng được đọc rộng rãi trên GitHub (#39062) cho rằng Gatsby trên thực tế đã bị bỏ rơi — rất ít commit, không hỗ trợ React 19, lộ trình năm 2024 không được thực hiện và dịch vụ telemetry đã đóng cửa. Những người bảo trì mô tả trạng thái hiện tại là chỉ sửa lỗi bảo mật, cập nhật một số dependency và xử lý các lỗi dễ khắc phục.

Điều đó có ý nghĩa gì với đội ngũ SEO. Với một trang Gatsby hiện có, đây không phải tình huống khẩn cấp — trang vẫn dựng được, vẫn được lập chỉ mục và vẫn hoạt động. Rủi ro là hệ sinh thái suy yếu theo thời gian: SEO phụ thuộc vào các plugin (gatsby-plugin-sitemap, image, canonical-urls), còn những plugin lâu năm (e.g. gatsby-source-shopify đối mặt với việc API bị ngừng hỗ trợ) cuối cùng có thể hỏng theo những cách âm thầm làm suy giảm khả năng lập chỉ mục. Với một dự án mới, hãy cân nhắc nghiêm túc yếu tố này — Astro và Next.js là những framework mà người dùng đang chuyển sang.

Danh sách kiểm tra production: xác minh từng phương thức kết xuất

Một phiên gatsby develop cục bộ, hay thậm chí nhật ký gatsby build không có lỗi, không chứng minh được trình thu thập dữ liệu thực sự nhận gì. Vì các tuyến SSG, DSG, SSR và chỉ chạy phía máy khách tạo HTML theo những cách khác nhau, hãy kiểm tra hành vi production theo từng phương thức thay vì cho rằng một trang đại diện bao quát tất cả:

  • Nội dung HTML thô. Với mỗi phương thức kết xuất đang dùng, hãy tải một URL production thực bằng curl -s <url> hoặc view-source: — không dùng DevTools — rồi xác nhận nội dung, tiêu đề và thẻ meta mà trình thu thập dữ liệu sẽ thấy thực sự có mặt.
  • Metadata (đầu ra của hàm Head). Xác nhận các thẻ do hàm xuất Head tạo ra nằm trong HTML thô của phương thức đang xét. Đây là điểm DSG/SSR khác SSG nhiều nhất: thẻ có trong mã nguồn ở cả hai trường hợp, nhưng chỉ một lần tải từ production mới chứng minh chúng đã đi vào phản hồi.
  • Trạng thái HTTP. Kiểm tra mã trạng thái phản hồi trên production, đặc biệt với các tuyến SSR và DSG — một trang kết xuất tốt ở máy cục bộ vẫn có thể trả về 500 trên production ở yêu cầu đầu tiên hoặc khi chịu tải, theo cách bản dựng không bộc lộ.
  • Hành vi bộ nhớ đệm. Đầu ra SSG là tệp tĩnh với cách lưu đệm dễ dự đoán. DSG lưu đệm sau yêu cầu đầu tiên — hãy xác nhận yêu cầu thứ hai vừa nhanh vừa đúng, không chỉ yêu cầu đầu. Phản hồi SSR phụ thuộc vào header bộ nhớ đệm và lớp lưu trữ; hãy xác minh nội dung cũ hoặc nội dung theo yêu cầu không được gửi nhầm cho khách truy cập.
  • Hành vi khi lỗi và khi dữ liệu rỗng. Với trang SSR và DSG dựa vào dữ liệu lấy tại thời điểm yêu cầu hoặc yêu cầu đầu tiên, hãy kiểm tra trình thu thập dữ liệu thấy gì nếu việc lấy dữ liệu thất bại hoặc trả về rỗng — trạng thái lỗi chưa được xử lý không phải là trang bạn đã kiểm thử cục bộ với dữ liệu tốt.
  • Tạo sitemap và loại trừ URL. Xác nhận lại rằng việc này chỉ diễn ra trong bản dựng production (gatsby build && gatsby serve, tuyệt đối không phải gatsby develop), và những mục bạn dự định loại trừ — bản nháp, tuyến chỉ chạy phía máy khách, hay bất kỳ nội dung nào bạn quyết định không liệt kê — thực sự vắng mặt trong sitemap-index.xml được tạo ra, chứ không chỉ vắng mặt trong ý định của bạn.

Không mục nào trong số này là tùy chọn đối với từng phương thức kết xuất — một gatsby build chạy thành công chỉ chứng minh đầu ra SSG, không chứng minh hành vi của DSG, SSR hay tuyến chỉ chạy phía máy khách.

Những lỗi Gatsby SEO phổ biến

  1. Vẫn dùng gatsby-plugin-react-helmet — đây là cách cũ; hãy chuyển sang Head API.
  2. Thẻ meta có trong DevTools nhưng không có trong mã nguồn trang — component SEO đang kết xuất phía máy khách; hãy kiểm tra view-source:, không phải DevTools.
  3. Nội dung nháp có trong sitemap — lọc bản nháp bằng GraphQL trong gatsby-node.js, không phải trong component React.
  4. Trang mồ côi từ src/pages — Gatsby tự tạo tuyến cho mọi tệp ở đó; tệp cũ vẫn được dựng và đưa vào sitemap.
  5. Thẻ canonical kép — cả gatsby-plugin-canonical-urls và react-helmet đều chạy.
  6. Dấu gạch chéo cuối URL không nhất quán — định tuyến phía máy khách của <Link> bỏ qua chuyển hướng dấu gạch chéo cuối URL ở phía máy chủ.
  7. Không loại chuỗi truy vấn khỏi canonical — hãy đặt stripQueryString: true.
  8. Bỏ sót văn bản thay thế trên GatsbyImage — component không tự tạo nội dung này.
  9. Gửi /sitemap.xml — tệp thực tế là /sitemap-index.xml.
  10. Kiểm thử sitemap trong gatsby develop — sitemap chỉ được tạo khi chạy gatsby build.
  11. Bật/tắt noindex bằng trạng thái React — Google có thể đã xử lý HTML thô; và khi thấy noindex trong HTML thô, Google có thể bỏ qua hoàn toàn bước kết xuất. Hãy giữ quyết định noindex trong HTML tĩnh hoặc header máy chủ.

Để tìm hiểu nền tảng kết xuất JavaScript phía sau tất cả những vấn đề này, hãy xem trung tâm JavaScript SEO cấp trên.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.