Static Site SEO: Jamstack, SSG, and Getting Found

TL;DR: Static site SEO starts with a meaningful advantage: important content can arrive as pre-rendered HTML instead of waiting for JavaScript. But Astro, Hugo, 11ty, Gatsby, Jekyll, and static Next.js exports do not automatically solve canonicals, metadata, structured data, redirects, internal links, or client-rendered widgets that hide content from crawlers. Judge the deployed HTML, not the framework label.

What static sites actually get for free

A static-site generator such as Astro, Hugo, 11ty, Jekyll, Gatsby, or Next.js in static-export mode runs templates and content during the build. It emits HTML files plus the CSS, JavaScript, and assets needed by each page. The hosting layer can serve those files without querying a database or rendering the page for every request.

That matters because Google processes pages through crawling, rendering, indexing, and serving. Our guide to how Google indexing works explains those stages in detail. The static-site advantage is simpler: if the copy and links are already in the downloaded HTML, Google does not need JavaScript to discover them.

“Keep in mind that 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.”

That is Google Search Central’s wording in Understand the JavaScript SEO basics. It is also the strongest argument for static site SEO: pre-rendering removes a dependency. It does not manufacture relevance, authority, useful writing, or coherent architecture (I would happily delegate all four to a build command).

Static files are easy to cache at CDN edges, too. Removing per-request rendering eliminates one source of latency and failure. Google’s Web Vitals documentation defines “good” performance as LCP within 2.5 seconds, INP of 200 milliseconds or less, and CLS of 0.1 or less. Those thresholds are assessed at the 75th percentile, separately for mobile and desktop traffic.

Do not translate this into “static sites automatically pass Core Web Vitals.” A 3 MB hero image, render-blocking fonts, third-party scripts, and a large hydration bundle can still ruin LCP or INP. Static architecture gives you room to perform well. It does not enforce an asset budget.

Nor does speed make an irrelevant page rank. It is infrastructure, not a substitute for demand, content, or links.

The view-source test catches the biggest Jamstack SEO failure

A static site can still be a JavaScript application wearing a static shell.

Astro islands, React widgets, client-fetched product grids, review components, comments, and “load more” lists may populate only after hydration. If SEO-relevant content arrives through a browser-side API request, it is absent from the initial response. You are back in JavaScript SEO territory even though the deployment contains HTML files.

Google describes the app-shell problem directly: “the initial HTML does not contain the actual content,” so Google must execute JavaScript before it can see the generated content. Its documentation also says a page may remain in the rendering queue “for a few seconds, but it can take longer than that.” Some bots cannot execute JavaScript at all.

Open the deployed URL and use view-source. Do not rely on the Elements panel in DevTools because that shows the DOM after scripts have changed it. Search the source for the headline, several distinctive sentences, important links, product details, and image alt attributes.

If they are missing, move the data into the build. Fetch it during generation and render the article, list, reviews, or product information into the emitted HTML. Keep browser JavaScript for interaction rather than primary content. Our framework guide explains how to keep Next.js, React, and Nuxt content on the correct side of this boundary.

I have failed this test on pages that looked perfectly complete in Chrome. The browser had fetched the data quickly enough that nothing appeared wrong during review, while view-source contained little more than a root element and script references. A green deployment checkmark is not an indexing test (nor, unfortunately, is “works on my machine”).

This is the distinction I care about most across static sites we inspect at SEOJuice. Framework choice gets a lot of attention, but the crawler receives an HTTP response, not your architectural intentions.

The SEO work your generator leaves with you

Generate and inspect the XML sitemap

Sitemap behavior varies by generator. Hugo generates sitemap.xml by default; its documentation even includes a section on disabling sitemap generation, which is the tell that it is enabled unless you switch it off.

A minimal valid sitemap has one url block per page:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/</loc>
    <lastmod>2026-07-19</lastmod>
  </url>
</urlset>

Astro takes a different approach. Its sitemap documentation says that @astrojs/sitemap needs the deployed site URL before it can generate a sitemap. Once configured, the integration adds sitemap index and sitemap files to the output directory.

For other generators, check the current documentation and plugin ecosystem rather than assuming a sitemap exists. The test is not whether a dependency appears in your package file. The test is whether the deployed sitemap loads, returns the right content type, and contains the production URLs you actually want indexed.

Then inspect a sample. Look for staging hosts, non-canonical slash variants, parameter URLs, missing sections, and pages that should be excluded. A sitemap can be syntactically valid while describing the wrong site.

Astro deserves extra attention because its configured site URL is also useful for constructing absolute URLs. Our Astro SEO checklist covers sitemaps, canonicals, and island-specific problems in more depth.

Build canonicals from the production URL

Static-site generators generally do not decide canonical URLs for you. Your layout must create a canonical for every indexable page using the production base URL and the page’s normalized path. A staging domain or localhost value baked into production points search engines at the wrong version.

Relative canonicals are another avoidable ambiguity. Build absolute URLs, then define one policy for trailing slashes, index files, and URL casing. Your canonical, internal links, sitemap entries, and redirect rules should agree.

We moved SEOJuice from seojuice.io to seojuice.com in January 2026. The visible navigation was the easy part. The real migration surface included canonical tags, sitemap entries, internal links, structured-data URLs, asset references, and host-level redirects. One old hostname embedded in a shared template can be copied into every generated page before anyone notices (a wonderfully efficient way to scale a mistake).

I do not trust a universal canonical component copied between frameworks. Base paths, slash behavior, URL helpers, and environment variables differ. Inspect the final HTML at the final URL. Templates are implementation details; deployed output is what crawlers receive.

Stop shipping one title across the whole site

Page titles, meta descriptions, Open Graph fields, and social tags usually come from front matter passed into a shared layout. If the front matter is absent or the fallback is too broad, hundreds of pages can inherit one generic title.

Make essential metadata explicit in the content model. Give each indexable page a unique, descriptive title and a relevant description. Define fallback logic for predictable cases, but do not let a site-wide brand string silently become every page’s title.

Then crawl the built site for duplicates, blanks, malformed tags, and unexpectedly long values. Static generation creates consistency, including consistent defects.

Add structured data to the actual page

Google Search Central defines structured data as “a standardized format for providing information about a page and classifying the page content.” Google recommends JSON-LD and says the markup should be placed on the page it describes.

The object must match the visible content and include all required properties to be eligible for enhanced presentation in Search. Eligibility is not a guarantee of a rich result. Schema clarifies meaning for machines; it does not force Google to decorate a result.

Generate structured data from the same source as the visible page wherever possible. Duplicating product names, prices, dates, and author information in separate manual fields creates drift. Validate representative page types after deployment, not just the JSON-LD template in isolation.

Author the unglamorous basics

You still need a correct robots.txt file, useful image alt text, coherent heading levels, descriptive anchors, and internal links. Static generation does not prevent orphan pages. A URL can exist in the output directory and sitemap while remaining disconnected from the paths users and crawlers follow.

From what we see across sites using SEOJuice, this is often where the clean architecture stops helping. The site builds quickly and serves quickly, but related pages are not connected, metadata coverage is uneven, and old content sits several layers away from any current page. None of those defects needs a framework migration. They need maintenance.

Tedious work, mostly. Still consequential.

Redirects belong at the host or CDN

A purely static deployment has no server-side application router running for each request. Redirects therefore belong at the hosting or CDN layer, not in a client-side component.

Netlify’s documentation says its redirects engine processes the first matching rule from top to bottom and uses 301 by default. Ordering matters. A broad wildcard above a specific migration rule can intercept the request first.

Vercel exposes redirects, clean URLs, and trailing-slash behavior as project configuration. Cloudflare Pages also supports an _redirects file, but its default is 302 rather than Netlify’s 301. Set the status explicitly when you mean a permanent move (I had to check that difference twice; identical filenames encourage the wrong assumption).

Keep the redirect map beside the source and test old URLs after deployment. Cover renamed pages, consolidated articles, domain variants, protocol changes, and your chosen trailing-slash policy. Test the returned status and destination, including redirect chains.

A client-side router that sees an old path and changes the browser URL is not equivalent. The original response remains a 200 or 404, and non-JavaScript clients never receive the intended redirect.

Dynamic features are fine outside the primary content path

Forms can use a host feature, third-party endpoint, or serverless function. The submission interaction is not indexable content, but the page should contain pre-rendered copy explaining what the form does.

Client-side search can use a local index or hosted API. Search results generally should not become the only discovery path for your content. Every important result needs its own static URL and at least one crawlable internal link outside the search interface.

Comments and review widgets require more care. If they hydrate after load, their content may not exist in the original HTML. When reviews materially support a product page, render the relevant review content during the build and generate accurate structured data from the same source.

Personalization, recommendations, and experiments can remain client-side if the primary page does not depend on them. My rule is blunt: decide indexable content during the build; add optional interaction in the browser.

A release process that catches static SEO defects

1. Build with production configuration. Confirm the real hostname and base path are available to templates.
2. Inspect raw HTML. Check titles, descriptions, canonicals, headings, links, alt text, JSON-LD, and primary content.
3. Open the sitemap and robots.txt. Verify that both are deployed and internally consistent.
4. Disable JavaScript. Confirm that the main information and navigation remain available.
5. Test old URLs. Verify that the host returns the intended status and final destination.
6. Measure representative pages. Compare them with the LCP, INP, and CLS thresholds instead of assuming static means fast.
7. Crawl after deployment. Find duplicate metadata, missing canonicals, orphan pages, broken links, and unexpected status codes.

Run this process for page types, not just the homepage. Blog posts, product pages, pagination, tag archives, documentation pages, and landing pages often use different layouts. One healthy homepage tells you almost nothing about a thousand generated URLs.

For migrations, retain the old URL list and test it automatically after release. We learned during the SEOJuice domain move that migration checks need to cover what users cannot see as well as what they can. Canonicals and structured-data identifiers are easy to miss during a visual review.

Where SEOJuice fits, and where it does not

SEOJuice continuously applies internal links, meta titles and descriptions, schema markup, and image alt text to a live site. It can be installed through a JavaScript snippet or a WordPress/CMS plugin, and a free plan is available without a credit card.

There is an important boundary for static sites. Snippet-injected metadata, schema, and links depend on client-side rendering, so they are not present in the original crawl-step HTML and may be unavailable to non-JavaScript bots. Keep primary content, canonicals, essential titles and descriptions, and critical JSON-LD in the generated HTML whenever you control the build. Use the snippet for incremental on-page work that can degrade gracefully, not as an excuse to ship an empty shell.

SEOJuice also does not replace your sitemap, CDN redirects, build architecture, or content strategy. If you want to see which parts of the on-page layer are missing, start with the free SEO audit. Fix the structural issues in the build, then automate the repetitive layer where that trade-off makes sense.

Frequently Asked Questions

Are static sites good for SEO?

Yes, as a starting architecture. Pre-rendered HTML removes the JavaScript rendering dependency for content present in the source, while CDN delivery makes strong performance easier to achieve. You still need relevant content, metadata, canonicals, a sitemap, structured data, internal links, and redirects.

Do static sites need an XML sitemap?

Yes. Hugo generates sitemap.xml by default, while Astro requires its sitemap integration and a configured site URL. Other generators may require project-specific configuration or a plugin. Inspect the deployed sitemap rather than assuming the build created one correctly.

Is Jamstack good for SEO?

Jamstack can provide the same pre-rendered markup and CDN delivery advantages as other static architectures. The risk appears when important content is fetched through browser-side APIs. If it is missing from the built HTML, Google must render JavaScript to see it, and other bots may miss it entirely.

How do I set up redirects on a static site?

Configure them at the host or CDN. Netlify supports _redirects and netlify.toml, Vercel uses project configuration, and Cloudflare Pages supports an _redirects file. Specify permanent status codes deliberately, keep rules in version control, and test the HTTP response after deployment.

Does Google index JavaScript on static sites?

Google can render JavaScript, but rendering occurs after crawling and may be deferred. Google also notes that not all bots can run JavaScript. If primary content appears only after hydration, render it into the built HTML instead of depending on browser execution.

Do static sites still need meta tags and canonical tags?

Yes. Static-site generators do not reliably invent unique titles, descriptions, Open Graph tags, or canonical URLs for every project. Generate them from page data, use the production base URL for absolute canonicals, and inspect the final HTML for duplicates or staging values.