Static Site Generators

TL;DR — A static site generatorA build tool that pre-renders every page into static HTML files at deploy time, so the server delivers complete HTML without executing code per request — eliminating JavaScript rendering delays for search engine crawlers. builds your whole site into plain HTML files ahead of time. So when Google shows up, the content is already there in the page — no waiting for JavaScript to run. That’s the easiest possible setup for SEO. The catch: the site only updates when you rebuild it.

What a static site generator is

Most of the SEO trouble with JavaScript comes down to one question: is your content actually in the page when a crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. fetches it, or does it only appear after scripts run? A static site generator (SSG) sidesteps that question entirely.

An SSG takes your content (usually written in Markdown) and your templates, and — on your computer or a build server — turns every page into a finished HTML file before anyone visits. You then upload those plain HTML files to a host. When Google, Bing, or a reader requests a page, they get complete HTML on the first try. Evidence for this claim A static site generator builds source content and templates into static files before requests are served. Scope: Hugo as a representative static site generator. Confidence: high · Verified: 2026-07-14 Hugo documentation

Compare that to a typical JavaScript app, where the server sends a near-empty shell and the browser builds the page afterward. With an SSG, there’s nothing to build in the browser — it’s already done.

Why that’s great for SEO

• The content is in the raw HTML. No renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. step has to succeed for Google to see your text and links.
• It’s fast. Plain HTML files load quickly, which helps Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data..
• There’s less to break. Fewer moving parts means fewer ways for content to go missing from search.

The popular ones

There are six you’ll hear about most: Hugo, Jekyll, Eleventy, Hexo, Gatsby, and Astro. They all produce static HTML; they differ in what language they’re built in and how much extra JavaScript (if any) they send to the browser. Each has its own deep dive linked at the bottom of this page.

The one thing to watch

A static site is a snapshot. It shows whatever was true the last time you built it. If you change a price, fix a typo, or publish a post and forget to rebuild and redeploy, search engines keep seeing the old version. So the main discipline with an SSG is making sure changes trigger a fresh build. Evidence for this claim Changes to a statically generated site require a new build and deployment before the generated output changes. Scope: Astro static builds as a representative SSG workflow. Confidence: high · Verified: 2026-07-14 Astro: Deploy your site

Want the technical version — how SSGs differ from client-side frameworks and meta-frameworks, a side-by-side comparison of all six, and the build-freshness trap in detail? Switch to the Advanced tab.

TL;DR — An SSG pre-renders every route to static HTML at build time, so the content exists in the response before the first crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. request — no Web RenderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. Service, no renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. queue, no “Wave 2” delay. That’s the single biggest indexability advantage you can give a site. SSGs differ from CSR frameworks (which build the page in the browser) and from meta-frameworks (which can SSR per request). The six in this cluster — Hugo, Jekyll, Eleventy, Hexo, Gatsby, Astro — all ship static HTML; they vary in language, JS payload, and built-in sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing./image tooling. The real failure mode isn’t rendering, it’s build freshness: a static site is only as current as its last build, so changed content that doesn’t trigger a rebuild silently serves stale HTML to search engines. I run this site on Astro for exactly this set of trade-offs.

What “static” actually means

A static site generatorA build tool that pre-renders every page into static HTML files at deploy time, so the server delivers complete HTML without executing code per request — eliminating JavaScript rendering delays for search engine crawlers. runs your content and templates through a build step and emits a folder of finished HTML, CSS, and assets. The crucial part for SEO is when the HTML is produced: at build time, once, for everyone — not per request, and not in the browser. Google’s JavaScript guidance describes crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor., rendering, and indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. as distinct processing stages. An SSG removes client-side rendering from the critical path for its generated content because the HTML is already complete. Evidence for this claim Google processes JavaScript through crawling, rendering, and indexing, while pre-rendered HTML is present before client execution. Scope: Google Search JavaScript processing; indexing is not guaranteed. Confidence: high · Verified: 2026-07-14 Google: JavaScript SEO basics

This is why static sites are the safest possible architecture for getting indexed. The content is in the first byte of the response. There’s no parity gap between raw and rendered HTML, no dependency on the renderer succeeding, no stateless-Chrome quirks to design around.

SSG vs. client-side rendering vs. meta-frameworks

Three architectures, three different moments the HTML comes into existence:

• Static site generation (SSG). HTML is built once, at build time, before any request. Served as flat files (often from a CDN). Content is in the raw HTML. This is Hugo, Jekyll, Eleventy, Hexo — and Gatsby and Astro in their default static mode.
• Client-side rendering (CSR). The server sends a minimal shell; JavaScript builds the page in the browser at request/runtime. Content depends on rendering succeeding. This is a default-CSR React or Vue SPA — the riskiest setup for SEO (see JavaScript SEOMaking sure search engines can crawl, render, and index content that depends on JavaScript.).
• Meta-frameworks (SSR / hybrid). Frameworks like Next.js, Nuxt, and SvelteKit can render HTML per request on the server (SSR), pre-render some routes (SSG), or mix both. Content is in the HTML, but produced at request time, which adds server cost and latency you don’t have with a pure SSG.

The line blurs at the edges — Gatsby and Astro are sometimes called meta-frameworks because they’re component-based and can do more than emit flat files. But in their bread-and-butter mode they’re static generators, and that’s how you should treat them for SEO. The mental model that matters: the earlier the HTML exists, the less can go wrong before a crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. sees it. SSG is the earliest.

The six generators, compared

All six produce indexable static HTML. Here’s how they differ on the axes that actually affect an SEO decision:

A few things worth pulling out of that table:

• JS payload is the SEO-adjacent differentiator. Hugo, Jekyll, Eleventy, and Hexo ship essentially no JavaScript unless you add it. Gatsby rehydrates a full React bundle on the client — still indexable (the HTML is static), but it carries a Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. cost the others don’t. Astro splits the difference with islands architecture: static HTML by default, JavaScript only for the specific interactive components (“islands”) that need it.
• Build speed scales differently. Hugo (Go) is famously fast and handles tens of thousands of pages comfortably. The Node-based generators are slower at large scale, and Gatsby’s build times have historically been its biggest complaint.
• Sitemaps and image optimization are mostly solved everywhere — but Hugo and Astro give you the most out of the box, while Jekyll/Eleventy/Hexo lean on (well-maintained) plugins.
• Gatsby’s release cadence has slowed noticeably. The project isn’t archived and still ships patches, but as of July 2026 its GitHub repo shows only a handful of commits over the trailing 90 days and one minor release since February. That’s worth weighing against a more actively-developed option if you’re picking a generator today, on top of the hydrationActivating server-rendered HTML in the browser by attaching JavaScript handlers./CWV cost above.

Why I built this on Astro

I built this site — and patrickstox.com — with Astro, and the reasoning is straight out of this page. I wanted to author in Markdown/MDX with real components, but I did not want to pay the JavaScript tax on every page just to get them. Astro’s default is zero client-side JS: the pages you’re reading ship as static HTML, and the only JavaScript that loads is for the handful of interactive pieces (like the lens tabs and the quiz). That gets me the indexability of a classic SSG and good Core Web VitalsWeb Vitals is Google's initiative (launched May 2020) for unified page-experience quality signals. Core Web Vitals — LCP, INP, and CLS — are the subset used in ranking; the rest (TTFB, FCP, TBT, Speed Index) are diagnostic, not ranking factors., without giving up a component-based authoring experience. If I needed blistering build speed across a huge content set with zero interactivity, Hugo would be the obvious call; for a React data layer, Gatsby. For this — a content-heavy site with a few interactive flourishes — Astro is the right trade.

The one real gotcha: build freshness

Everything above is the upside. Here’s the catch that bites people.

A static site is only as current as its last build. The HTML is a snapshot frozen at build time. Change a price, correct a fact, publish a post, update a title tagThe title tag is the HTML title element in a page's head that specifies the document's title. It's the primary source for the SERP title link and a confirmed light ranking factor — but since August 2021 Google doesn't always show it verbatim. — none of it reaches search engines until you rebuild and redeploy. There’s no live server assembling the page from a database on each request, so there’s nothing to pick up your change automatically. Evidence for this claim Static build output remains a snapshot until the project is rebuilt and redeployed. Scope: Astro static build workflow as a representative example. Confidence: high · Verified: 2026-07-14 Astro: Build and deploy

In practice this means:

• Content edits must trigger a build. If you author in a headless CMSA headless CMS decouples content storage and editing (the backend) from how that content is rendered and delivered (the frontend), serving content over an API instead of a built-in templated 'head'. Its SEO outcomes come almost entirely from how the separate frontend renders pages. or Git, wire up a webhook so a publish kicks off a deploy. A manual-only build process is how stale prices and “ghost” 404s sneak into the index.
• Frequently-changing data is awkward. Inventory, prices, live counts — if it changes faster than you rebuild, the static copy lags. That’s where incremental builds, scheduled rebuilds, or a hybrid (a meta-framework with SSR/ISR for the volatile routes) earn their keep.
• Time-sensitive pages need a cadence. If “today’s deals” is baked at build time, the build has to run at least daily, or the page lies.

None of this is a dealbreaker — it’s a discipline. The whole reason SSGs are great for SEO (HTML decided ahead of time) is the same reason you have to be deliberate about re-deciding it when content changes.

Where to go next: the static site generators cluster

This hub is the map. Each generator below is its own deep dive — language, JS payload, sitemap/image tooling, the framework-specific SEO gotchas, and how to keep builds fresh:

• Hugo SEOHugo SEO is the practice of optimizing sites built with Hugo, the Go-based static site generator. Hugo outputs finished HTML at build time, so content is in the raw HTML on the first fetch — but that alone doesn't guarantee good Core Web Vitals or rankings, and canonicals, taxonomy duplication, and aliases-vs-301s still need hands-on configuration. — Go-powered, zero-JS, blazing builds; the auto-generated sitemap, built-in image processing, and managing huge content sets.
• Jekyll SEOJekyll SEO is the set of technical and on-page practices for optimizing sites built with Jekyll — the Ruby static site generator that powers GitHub Pages. Jekyll outputs flat HTML with no rendering delay, so the SEO work is configuration: jekyll-seo-tag for metadata, jekyll-sitemap for sitemaps, clean permalinks, and a manual robots.txt. — the original SSG and the GitHub Pages default; jekyll-seo-tag, jekyll-sitemap, and the plugin-on-GitHub-Pages limitation.
• Eleventy (11ty) SEO — JavaScript-based, zero-JS output; generating sitemaps from templates and eleventy-img for responsive images.
• Hexo SEOHexo SEO is the practice of optimizing sites built with Hexo, the Node.js static site generator. Hexo outputs pure static HTML at build time, so content is crawlable on the first fetch — but sitemaps, robots.txt, meta descriptions, canonicals, and structured data all depend on plugins and theme configuration. — the Node blog generator; sitemap/feed plugins, theme JS, and permalink/canonical hygiene.
• Gatsby SEOGatsby SEO is the set of practices for getting a Gatsby site found and ranked. By default, Gatsby pre-renders HTML at build time (SSG), putting content in the raw HTML on the first fetch — but Gatsby also supports DSG, SSR, and client-only routes that don't all work that way, and it ships a full React bundle, so canonical tags, sitemaps, and Core Web Vitals still need deliberate work. — React-based static generation; the hydration/CWV trade-off, gatsby-plugin-image, gatsby-plugin-sitemap, and build-time data sourcing.
• Astro SEOAstro SEO is the practice of optimizing sites built with the Astro web framework for search. Astro prerenders to static HTML by default, so content is in the raw HTML on first crawl for that route — no rendering queue — which makes it a strong starting point for SEO, though the default can be overridden per route and doesn't guarantee crawlability or rankings on its own. — zero-JS by default, islands architecture, @astrojs/sitemap, astro:assets, View Transitions, and Server Islands fallback behavior.

Every topic above is nested under this hub and lives in the sidebar too.

For the broader context — how Google renders JavaScript, the parity and interaction failure modes, and which rendering mode to pick when you do need JS — see the parent JavaScript SEOMaking sure search engines can crawl, render, and index content that depends on JavaScript. hub.

AI summary

A condensed take on the Advanced version:

• An SSG pre-renders every page to static HTML at build time — content exists in the response before the first crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. request. No Web Rendering ServiceTurning HTML, CSS, and JavaScript into the final visual page and DOM., no renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. queue, no “Wave 2” delay. The safest architecture for indexability.
• Three architectures by when the HTML exists: SSG (build time, safest), CSR (in the browser at runtime, riskiest), meta-frameworks/SSR (per request on the server, content present but with latency/cost).
• All six generators ship indexable static HTML. They differ in language, JS payload, and built-in sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing./image tooling:
  • Hugo (Go) — zero JS, fastest builds, built-in sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing. + image processing.
  • Jekyll (Ruby) — zero JS, GitHub Pages default, plugin-driven.
  • Eleventy (Node) — zero JS, flexible, plugin-driven.
  • Hexo (Node) — zero JS by default, blog-focused, plugin-driven.
  • Gatsby (React) — hydrates a React bundle (CWVGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. cost), strong image tooling, but its release cadence has slowed markedly as of mid-2026.
  • Astro (any framework) — zero JS by default via islands, official sitemap
    • astro:assets.
• JS payload is the SEO-adjacent differentiator — Gatsby carries a React bundle; Astro’s islands ship JS only where needed; the rest are zero-JS.
• Patrick built this site (and patrickstox.com) on Astro — components without the JS tax: static HTML + good Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data..
• The one real gotcha is build freshness: a static site is only as current as its last build. Wire content edits to a rebuild webhook; use incremental/scheduled builds or a hybrid SSR/ISR route for fast-changing data.

Official documentation

Primary-source documentation — from the search engines and from each generator.

Search engines — renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. & static HTML

• Understand the JavaScript SEO basics — the crawl → render → indexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. phases that a static build lets you skip for content.
• In-Depth Guide to How Google Search Works — where renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. sits, and why pre-rendered HTML is lowest-risk.

The generators

• Hugo documentation — and the sitemap template and image processing docs.
• Jekyll docs — plus jekyll-seo-tag and jekyll-sitemap.
• Eleventy (11ty) docs — and eleventy-img.
• Hexo docs — and the hexo-generator-sitemap plugin.
• Gatsby docs — and gatsby-plugin-image and gatsby-plugin-sitemap.
• Astro docs — plus @astrojs/sitemap and astro:assets / images.

Quotes from the source

On-the-record statements from Google and from the generators’ own teams, plus a note from my own writing.

Google — renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. is a separate step

• “During the crawl, Google renders the page and runs any JavaScript it finds using a recent version of Chrome.” — the step an SSG removes from the critical path by shipping finished HTML. Jump to quote
• “RenderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. is important because websites often rely on JavaScript to bring content to the page, and without rendering Google might not see that content.” — i.e., if the content is already in the static HTML, rendering can’t cost you visibility. Jump to quote

Astro — static by default

• “By default, Astro pages, routes, and API endpoints will be pre-rendered at build time as static pages. However, you can choose to render some or all of your routes on demand by a server when a route is requested.” Jump to quote

Hugo — speed

• Hugo bills itself as “the world’s fastest framework for building websites” — the build-speed advantage that matters at large content scale. Source

Patrick Stox (my own work — JavaScript SEO: A Definitive Guide)

• “Any kind of SSR, static rendering, and prerendering setup is going to be fine for search engines.” — static generation is the low-risk end of that spectrum.

Static-site SEO checklist

A quick pass to confirm your SSG setup is search-friendly — and staying fresh:

• Important content is present in View Source (raw HTML), not just after JS runs — the whole point of an SSG.
• An XML sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing. is generated on every build and submitted in Google Search Console and Bing Webmaster ToolsMicrosoft's free portal for monitoring and improving how a site appears in Bing search — the peer to Google Search Console, plus IndexNow instant indexing, richer backlink data, and keyword volumes. Because Bing's index also feeds Microsoft Copilot, it doubles as a window into AI-search visibility..
• Each page has unique, build-time <title> and meta descriptionThe meta description is an HTML head tag — `<meta name=\"description\" content=\"…\">` — that suggests a short summary of the page for the search snippet. It's not a Google ranking factor, and Google rewrites it the majority of the time, but a good one can still lift click-through. (via the generator’s templating or an SEO plugin/integration).
• Canonical tagsA rel=\"canonical\" annotation — in the HTML <head> or an HTTP Link header — that tells search engines which URL is the preferred version of duplicate or near-duplicate content. are set and point to the live, final URLs (not localhost or a preview domain).
• Images are optimized at build time (responsive sizes, modern formats) — use the generator’s built-in tooling or image plugin.
• Any client-side JavaScript (Gatsby’s React bundle, Astro islands, theme JS) isn’t hiding primary content behind interaction.
• JS/CSS assets are not blocked in robots.txt.
• Content edits trigger a rebuild + redeploy — a CMSA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms./Git webhook fires a deploy automatically.
• Time-sensitive or frequently-changing pages have a scheduled rebuild cadence (or are served via SSR/ISR instead of static).
• Old URLs from a previous build aren’t left as orphaned static files — clean the output dir / handle removals so deleted pages 404 or 410.
• The deployed build matches the latest content (spot-check a recently changed page in production, not just locally).

Static site generators — cheat sheet

The six at a glance

When the HTML exists (and why it matters)

Fast facts

• SSG = no Web RenderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. Service in the critical path → no “Wave 2” delay for content.
• Gatsby hydrates a React bundle (CWVGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. cost); Astro ships JS only for islands; Hugo/Jekyll/Eleventy/Hexo are zero-JS by default.
• Gatsby’s release cadence has slowed as of mid-2026 — check its GitHub activity before betting a new build on it.
• Hugo (Go) is the speed champion at large scale.
• The one trap: build freshness — a static site shows its last build. Wire a rebuild webhook to content edits.
• Fast-changing data (prices, inventory) → incremental/scheduled builds or hybrid SSR/ISR.

Which rendering path fits?

The build → deploy → verify framework

• Build: enumerate intended routes and generate complete HTML, metadata, canonicals, and structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding..
• Deploy: publish the new artifact atomically so HTML, assets, sitemapsA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing., and redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. stay in sync.
• Verify: compare source HTML and the production response with the content version that triggered the build.

Static HTML solves renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. dependence; it does not solve stale builds, missing routes, broken deploy hooks, or client-side metadata that never reaches source HTML.

Check whether key content exists in source HTML

curl -sS https://example.com/page/ | grep -F 'Expected visible heading'

For a URL list, fail CI when a production route is missing or lacks a title:

while IFS= read -r url; do html=$(curl -fsSL "$url") || { echo "FETCH FAIL $url"; continue; }; printf '%s' "$html" | grep -qi '<title>[^<]' || echo "TITLE FAIL $url"; done < urls.txt

Run this in DevTools Console to compare a rendered page’s title, canonical, and heading:

({title: document.title, canonical: document.querySelector('link[rel="canonical"]')?.href, h1: document.querySelector('h1')?.textContent.trim()});

Tools for static output

• Raw vs. Rendered HTML Checker shows whether important content and head signals are already present in the initial HTML.
• HTTP Status Checker checks generated routes, redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't., and missing pages in batches.
• HTTP Header Checker inspects cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency. and deployment headers across redirects.
• A framework’s build log and deployment manifest are the source of truth for which routes were generated successfully.

Prove the static deployment works

Source-HTML test

Test to run: fetch representative production URLs with curl or Render Gap. Expected result: primary content, title, canonical, and links appear in raw HTML. Failure interpretation: the route is client-rendered or the build omitted data. Monitoring window: immediate after deploy. Rollback trigger: important templates ship empty or incomplete source HTML.

Publishing-freshness test

Test to run: publish a controlled content change and compare its CMSA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms. timestamp, build log, deploy artifact, and live HTML. Expected result: the change triggers one successful build and reaches production. Failure interpretation: the webhook, build, cache, or deployment chain is stale. Monitoring window: the normal publish SLA. Rollback trigger: production mixes old HTML with new metadata or assets.

Route-completeness test

Test to run: compare intended canonical URLsHow search engines pick one canonical URL among duplicates and consolidate signals onto it. with generated/deployed routes and batch-check statuses. Expected result: every intended route returns its planned status. Failure interpretation: dynamic path discovery or build configuration missed routes. Monitoring window: every build. Rollback trigger: canonical pages become 404s or redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. unexpectedly.

Test yourself: Static Site Generators

Five quick questions on why static site generatorsA build tool that pre-renders every page into static HTML files at deploy time, so the server delivers complete HTML without executing code per request — eliminating JavaScript rendering delays for search engine crawlers. are easy mode for SEO — and the one thing that can still trip you up. Pick an answer for each, then check.

Resources worth your time

My related writing

• JavaScript SEO: A Definitive Guide — renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM., DOM parityWhether the rendered DOM matches what you expect the raw HTML to become., and why static/prerendered output is the low-risk end of the spectrum.
• The Beginner’s Guide to Technical SEO — where renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. architecture fits in the bigger picture.

My speaking

• How Search Works (SlideShare) — my walkthrough of crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor., rendering, indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed., and ranking. (My standing disclaimer applies: “This is my understanding of systems… not going to be 100% complete or accurate.”)

From around the industry

• web.dev — Rendering on the Web — the Chrome team’s canonical explainer of SSG vs. SSR vs. CSR and the trade-offs between them.
• Google Search Central — JavaScript SEO basics — the crawl → render → index phases a static build lets you skip for content.
• Jamstack — the architectural movement (pre-rendered markup served from a CDN) that static site generatorsA build tool that pre-renders every page into static HTML files at deploy time, so the server delivers complete HTML without executing code per request — eliminating JavaScript rendering delays for search engine crawlers. are the engine of, with a generators directory.
• Astro — Why Astro? — the clearest statement of the “static HTML, zero JS by default, islands for interactivity” model.
• Hugo — the Go-based generator built around build speed at large content scale.
• Smashing Magazine — Static site generator coverage — practitioner articles on choosing and using SSGs.

Static Site Generator

A build tool that pre-renders every page into static HTML files at deploy time, so the server delivers complete HTML without executing code per request — eliminating JavaScript rendering delays for search engine crawlers.

Related: JavaScript SEO, Rendering, Astro SEO

Static Site Generator

A static site generator (SSG) is a build tool that processes templates, content files, and data sources at deploy time to produce a complete set of static HTML files. Unlike server-side renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. (where HTML is generated on each request) or client-side renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. (where the browser builds the page from JavaScript), SSGs generate all pages once and serve them as plain files.

For SEO, static generation is the safest rendering approach: search engine crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. receive complete HTML with no JavaScript execution required, no render queue delay, and no risk of timing out on slow or complex scripts. Pages indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. from static HTML typically match what users see exactly, eliminating the parity gap that client-side rendering introduces.

Popular static site generators include Hugo (Go-based, very fast builds), Jekyll (Ruby, GitHub Pages native), Eleventy (JavaScript, flexible), Hexo (JavaScript, blog-focused), Gatsby (React-based, GraphQL data layer), and Astro (component islands, ships zero JavaScript by default). Next.js and Nuxt support SSG mode alongside SSR and ISR, making them meta-frameworks rather than pure SSGs.

Related: JavaScript SEO, Rendering, Astro SEO

Changelog