Eleventy SEO

TL;DR — Eleventy builds your site into plain HTML files ahead of time, and — unlike most JavaScript tools — it sends no JavaScript to the browser by default. That’s about as friendly as it gets for Google. The catch: Eleventy won’t write your title tags, meta descriptions, or sitemap for you. You have to add those yourself.

What Eleventy is

Eleventy (you’ll also see it written 11ty) is a static site generator. You write your content in Markdown and your page templates in something like Nunjucks or Liquid, and Eleventy turns all of it into finished HTML files before anyone visits. You upload those files to a host, and when Google or a reader requests a page, they get complete HTML straight away. Evidence for this claim Eleventy transforms templates and data into static output files during a build. Scope: Eleventy static site generation. Confidence: high · Verified: 2026-07-14 Eleventy documentation

The thing that sets Eleventy apart from most JavaScript-based tools is that it ships zero JavaScript to the browser by default. Evidence for this claim Eleventy does not require a client-side JavaScript runtime and ships only the browser JavaScript a developer adds. Scope: Eleventy core output; site code can add JavaScript. Confidence: high · Verified: 2026-07-14 Eleventy documentation The page a visitor gets is plain HTML — nothing has to run in the browser to build it. For SEO that’s ideal: there’s no rendering step for Google to wait on, and pages load fast.

Why that helps SEO

• Your content is in the raw HTML. Google sees your text and links on the first fetch — no JavaScript has to run successfully first.
• It’s fast. Plain HTML with no script payload is great for Core Web Vitals.
• Less can break. Fewer moving parts means fewer ways for content to go missing from search.

The big catch: Eleventy does not do SEO for you

This is the part people get wrong. Eleventy gives you clean HTML, but it adds none of the SEO markup automatically:

• No <title> tag
• No meta description
• No canonical link
• No sitemap
• No structured data

All of that is yours to add — usually in a shared layout file that wraps every page, so you write it once and every page inherits it. There are plugins that help (the popular one is eleventy-plugin-seo), but they’re conveniences, not magic. The work still has to happen.

The mental model: the data cascade

Eleventy’s clever trick for doing this without hand-editing every page is the data cascade. You set sitewide defaults once in a global data file (your site name, base URL, default social image), and Eleventy applies them everywhere. Override them per section or per page only where you need to. It even lets you compute values — like building each page’s canonical URL automatically from your domain plus the page’s path.

Want the technical version — the full data cascade, code for meta tags and canonicals, the plugin comparison, sitemaps, image optimization, and pagination SEO? Switch to the Advanced tab.

TL;DR — Eleventy emits plain HTML at build time with zero client-side JS by default, so content is in the response before the first crawler request — the lowest-risk indexability setup there is. But Eleventy ships no SEO markup: title, description, canonical, robots, OG, sitemap, and JSON-LD are all yours to build. The data cascade (_data/site.js → directory data files → front matter → eleventyComputed) is the architecture that makes this scale — declare defaults once, derive canonicals in eleventyComputed. Plugins (eleventy-plugin-seo, @11ty/eleventy-img, @quasibit/eleventy-plugin-sitemap) add convenience, not capability. robots.txt is a passthrough file. Template language is an SEO non-issue — pick by team familiarity. v3 is ESM-first and makes the Image Transform plugin the default path to CWV-clean images. Watch three edge cases: eleventyComputed dependency ordering can fail silently, collection membership doesn’t guarantee a URL was emitted, and a local build is not proof of what production actually serves — verify the deployed artifact directly.

Why Eleventy is a strong SEO baseline

Eleventy builds every route to static HTML at build time and, unlike Next.js, Nuxt, Gatsby, or Astro, ships no JavaScript to the browser unless you add it. Evidence for this claim Eleventy compiles templates to static output and adds no client-side framework runtime by default. Scope: Eleventy core behavior. Confidence: high · Verified: 2026-07-14 Eleventy documentation There’s no client-side rendering for a crawler to wait on, no rendering budget impact, and no hydration bundle taxing Core Web Vitals. Real production Eleventy sites routinely report Lighthouse scores of 99–100 across the board and homepages that ship 0 KB of JavaScript.

It’s also fast to build, which matters more for SEO than it looks: faster builds mean tighter deploy cycles, so content fixes reach search engines sooner. On a 4,000-Markdown-file benchmark Eleventy builds in ~1.93s versus ~22.9s for Astro, ~29s for Gatsby, and ~70.6s for Next.js, with a fraction of the node_modules footprint (34 MB vs Gatsby’s 583 MB).

But — and this is the whole point of the page — none of that buys you SEO markup. Eleventy generates clean HTML and stops there. Every <title>, meta description, canonical, sitemap entry, and JSON-LD block is something you implement. The good news is that Eleventy’s data model makes implementing them once-and-everywhere genuinely pleasant.

The data cascade: your SEO architecture foundation

The single most important concept for scalable Eleventy SEO is the data cascade — the order in which Eleventy resolves a value, lowest priority to highest: Evidence for this claim Eleventy's data cascade resolves data from multiple sources according to a documented priority order. Scope: Eleventy data cascade. Confidence: high · Verified: 2026-07-14 Eleventy: Data cascade

1. Eleventy-supplied global data
2. Global data files in _data/ (e.g. _data/site.js with title, description, url, author)
3. Directory data files (e.g. blog/blog.11tydata.js — give every blog post og:type: article)
4. Template front matter (per-page overrides)
5. eleventyComputed (highest — derive values from other data)

In practice:

• Declare your SEO defaults once in _data/site.js.
• Override at the directory level for a content type (all posts get the article OG type, a noindex section gets noindex, etc.).
• Override per page in front matter where a page is special.
• Use eleventyComputed for derived values — the canonical being the canonical example:

// _data/eleventyComputed.js  (or eleventyComputed in a layout data file)
module.exports = {
  canonical: (data) => `${data.site.url}${data.page.url}`,
};

Now every page has a correct self-referencing canonical with zero per-page work. That’s the leverage the cascade gives you.

One edge case worth testing rather than assuming: eleventyComputed values can depend on other computed values (a title that feeds into a computed description, say), and Eleventy has to resolve that dependency graph before it can render anything. Straightforward chains work fine, but a computed value that accidentally depends on itself — directly or through another computed field — is a circular reference, and ordering issues here fail silently as a missing or wrong value rather than a loud build error. If you lean on multiple layered eleventyComputed fields, check the rendered output for the exact values you expect, not just that the build succeeded. Evidence for this claim Computed Data values can derive from other computed values, so dependency ordering and circular references need testing against the rendered output. Scope: Eleventy eleventyComputed resolution. Confidence: high · Verified: 2026-07-16 Eleventy: Computed Data

Meta tags in the base layout

Standard architecture is a base layout that owns the <head>, with content layouts extending it:

_includes/
  layouts/
    base.njk      ← <head> with all SEO meta tags
    post.njk      ← extends base, adds BlogPosting schema
_data/
  site.js         ← sitewide SEO defaults

The meta tags you need to implement yourself, at minimum:

• <title> — unique per page
• <meta name="description"> — unique per page
• <link rel="canonical"> — Eleventy has no built-in canonical; add it explicitly
• <meta name="robots"> — noindex for draft/preview pages (and thin paginated pages, if any)
• Open Graph — og:title, og:description, og:image, og:url, og:type
• Twitter/X Cards — twitter:card, twitter:title, twitter:description, twitter:image

A minimal Nunjucks <head> pulling from the cascade:

<title>{{ title }} | {{ site.title }}</title>
<meta name="description" content="{{ description or site.description }}">
<link rel="canonical" href="{{ canonical }}">
<meta property="og:title" content="{{ title }}">
<meta property="og:image" content="{{ ogImage or site.defaultImage }}">
<meta name="twitter:card" content="summary_large_image">

SEO plugins, compared

You don’t need a plugin — a manual base layout plus the data cascade gives you full control with no dependencies, and many practitioners prefer exactly that. But two plugins are worth knowing:

• eleventy-plugin-seo (artstorm) — the most mature and widely used. A single {% seo %} shortcode (Liquid) / {% seo "" %} (Nunjucks) emits title, description, canonical, robots, Open Graph, Twitter Card, and author from a config block (site title, description, URL, author, Twitter handle, default image). It also handles robot directives on paginated pages, a title divider, and a minimalistic mode. Install: npm install eleventy-plugin-seo.
• eleventy-plugin-metagen (tannerdolby) — more granular, with named shortcode parameters; generates charset, viewport, title, author, description, generator, OG, Twitter Card, canonical, and CSS/JS tags.

The rule of thumb: plugins add convenience, not capability. Anything they do, you can do in the base layout. Reach for one if you’d rather not maintain the boilerplate.

robots.txt

Eleventy does not auto-generate robots.txt. Two approaches:

1 — Static passthrough (simplest). Drop a robots.txt in your source and copy it verbatim:

eleventyConfig.addPassthroughCopy("src/robots.txt");

2 — Template-generated (for environment-specific output — block everything on staging, allow on production):

---
permalink: /robots.txt
eleventyExcludeFromCollections: true
---
User-agent: *
{% if environment == "production" %}
Allow: /
Sitemap: {{ site.url }}/sitemap.xml
{% else %}
Disallow: /
{% endif %}

Remember the universal rule: Disallow blocks crawling, not indexing — and a noindex tag on a crawl-blocked URL is never seen.

Sitemap generation

Also not built in. The most-control option is a manual template — create sitemap.xml.njk with permalink: /sitemap.xml and eleventyExcludeFromCollections: true, loop over collections.all, skip excluded pages, and emit <loc> / <lastmod> entries:

---
permalink: /sitemap.xml
eleventyExcludeFromCollections: true
---
<?xml version="1.0" encoding="utf-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
{% for page in collections.all %}
  {% if not page.data.excludeFromSitemap %}
  <url>
    <loc>{{ site.url }}{{ page.url }}</loc>
    <lastmod>{{ page.date | dateToISO }}</lastmod>
  </url>
  {% endif %}
{% endfor %}
</urlset>

Or use @quasibit/eleventy-plugin-sitemap (configure with hostname; it also supports multilingual alternate links). Either way, mark utility pages with eleventyExcludeFromCollections: true so they don’t leak in.

One thing worth being precise about: looping over collections.all walks collection membership, not guaranteed output. A template can belong to a collection and still not emit a URL — most commonly because its permalink is set to false, or because a data-only file was never meant to render a page in the first place. Membership in collections.all is not proof an item belongs in the sitemap; check the rendered <loc> entries against the pages you actually expect to be crawlable. Evidence for this claim Collection membership does not by itself guarantee that an item emits a URL or belongs in the sitemap. Scope: Eleventy collections and permalink interaction. Confidence: high · Verified: 2026-07-16 Eleventy: Collections

Image optimization for Core Web Vitals

A static site’s HTML is fast, but unoptimized images will still tank LCP and CLS. The fix is @11ty/eleventy-img, and in v3 the recommended path is the Image Transform plugin, which post-processes every <img> tag in your built HTML automatically — no per-image shortcode needed:

const { eleventyImageTransformPlugin } = require("@11ty/eleventy-img");

eleventyConfig.addPlugin(eleventyImageTransformPlugin, {
  formats: ["avif", "webp", "jpeg"],
  defaultAttributes: {
    loading: "lazy",
    decoding: "async",
  },
});

What that buys you for SEO:

• Auto-stamped width and height → prevents layout shift (CLS)
• srcset with multiple widths → responsive images
• <picture> with AVIF + WebP + JPEG fallback
• No upscaling

For above-the-fold hero images, override the lazy default so they load eagerly:

<img src="hero.jpg" loading="eager" fetchpriority="high" eleventy:widths="800,1200">

Permalinks and clean URLs

Eleventy’s default is clean URLs with a trailing slash: about.njk → _site/about/index.html → /about/. Override in front matter:

permalink: "/blog/{{ title | slugify }}/"

Useful flags: permalink: false processes a template for collections but skips writing it to disk (handy for data-only templates), and dynamicPermalink: false treats the permalink string literally. The one SEO thing to stay disciplined about: trailing-slash consistency — mixing /page and /page/ is a duplicate-content own-goal.

Worth stating plainly because it trips people up: permalink: false suppresses output entirely — the source file compiles and can still feed collections and data, but no HTML page is written and no URL exists to crawl. A source file sitting in your content directory is not proof that a corresponding page shipped; if a page is missing from search, check the built _site output for the file before assuming it’s an indexing problem rather than a permalink one. Evidence for this claim A permalink value of false suppresses page output entirely, so a source file's existence is not proof of a crawlable page. Scope: Eleventy permalink output control. Confidence: high · Verified: 2026-07-16 Eleventy: Permalinks

Pagination SEO

Eleventy’s pagination splits a collection across output files. The first page is /blog/, then /blog/1/, /blog/2/, and so on (customizable via permalink). Each page in the set needs a unique URL and pagination.alias to expose per-page data. The SEO decisions:

• Canonicals. Two schools: point every page at page 1 (consolidates signals but buries legitimate deep-page content), or self-referencing canonicals where each page’s canonical is its own URL — Google’s preferred approach in current documentation. I default to self-referencing unless the deeper pages truly have nothing worth indexing.
• rel="prev" / rel="next". Google confirmed back in 2019 it no longer uses these as ranking signals. Some still add them to help crawlers understand series structure; if you do, wire them from pagination.href.previous / pagination.href.next.
• noindex on thin pages. If later pages have insufficient content, add noindex (via the noindex field if you’re using eleventy-plugin-seo, or manually in the head).

Structured data / JSON-LD

Manual is the most flexible: define a schema object in eleventyComputed or a directory data file and serialize it in the layout. The cleanest types for a content site are Organization / WebSite sitewide in the base layout, BlogPosting / Article per post, BreadcrumbList if you have breadcrumbs, and FAQPage on FAQ sections. @quasibit/eleventy-plugin-schema offers a shortcode for BlogPosting and WebPage if you’d rather not hand-roll it (it expects ISO 8601 dates, so register a date filter).

Eleventy v2 vs v3 — what changed for SEO

v3 (current stable) is ESM-first: a config file that uses require() now needs the .cjs extension, or you set "type": "module" in package.json and use import. CommonJS is still fully supported — just be deliberate about it. The two SEO-relevant wins:

• ~38% faster cold builds on sites over 500 pages → faster deploys, fresher index.
• The Image Transform plugin is the default path — declarative post-processing of every <img>, which makes shipping responsive, CLS-safe images the path of least resistance instead of a per-image chore.

Verify the production artifact, not just the local build

Everything above is about getting the source right — the data cascade, the layout, the plugins. None of it proves what actually ships. A local _site build (or eleventy --serve) doesn’t tell you what production serves: the host and path your deploy platform actually uses, redirects it injects, headers it sets, or whether a CDN/proxy rewrites anything on the way out. Confirm the installed Eleventy version matches what you’re testing against, then check the deployed site directly, not just the build output:

• Raw HTML — view-source the live URL, not just _site/index.html; confirm the title, meta description, and canonical are there and correct.
• Absolute canonical host — a canonical built from a staging or localhost site.url will silently ship wrong in production if that value wasn’t overridden per environment.
• Sitemap XML — fetch the live /sitemap.xml and confirm it resolves, uses the production host, and lists the URLs you expect (see the sitemap section above on collection membership not guaranteeing an entry).
• Suppressed/utility pages — spot-check that permalink: false and eleventyExcludeFromCollections: true pages are actually absent from the live site, not just from your local build.
• Assets — CSS, JS, and images referenced in the built HTML resolve on the production host (a relative-vs-absolute path mismatch is easy to miss locally).
• Status codes and redirects — request the live URLs directly and confirm 200s where you expect 200s; a deploy platform’s redirect rules can silently turn a canonical page into a 301 chain that never shows up in a local build.

Third-party plugin installation is not proof of correct output either — it changes what gets generated, not what a specific deploy environment does with it. Treat this as a release-checklist item, not a one-time setup. Evidence for this claim Local build output does not by itself prove production hostnames, redirects, headers, or canonical behavior; the deployed artifact needs its own verification pass. Scope: Eleventy production deployment verification. Confidence: medium · Verified: 2026-07-16 Patrick Stox: Eleventy SEO

Common Eleventy SEO mistakes

• Assuming Eleventy “handles SEO” — it handles HTML; the SEO markup is all yours.
• Forgetting the canonical entirely (there’s no built-in one).
• Shipping no sitemap because you assumed it was automatic.
• Letting unoptimized images undo the speed advantage.
• Inconsistent trailing slashes creating duplicate URLs.
• Using Disallow in robots.txt to try to deindex a page (use noindex instead).
• Leaving draft/preview pages indexable because no noindex was set on the section.

For where Eleventy sits among the other generators, see the Static Site Generators hub; for the rendering theory behind why static output is low-risk, the parent JavaScript SEO hub.

AI summary

A condensed take on the Advanced version:

• Eleventy outputs plain HTML at build time with zero client-side JavaScript by default — content is in the first byte, nothing to render. The lowest-risk architecture for indexability, with Lighthouse 99–100 and 0 KB JS homepages common.
• Eleventy generates NO SEO markup. No title, description, canonical, robots, Open Graph, sitemap, or JSON-LD. Every one of those is something you implement.
• The data cascade is the scaling architecture: global _data/site.js → directory data files → front matter → eleventyComputed. Declare defaults once; derive the canonical with eleventyComputed (${site.url}${page.url}).
• Meta tags live in a shared base layout — either hand-written, or via eleventy-plugin-seo (artstorm, the leading plugin: one {% seo %} shortcode for title/description/canonical/robots/OG/Twitter).
• robots.txt is a passthrough file (addPassthroughCopy) or a template for env-specific output — not auto-generated.
• Sitemap = a Nunjucks template over collections.all, or @quasibit/eleventy-plugin-sitemap. Exclude utility pages with eleventyExcludeFromCollections: true.
• Images: @11ty/eleventy-img; v3’s Image Transform plugin post-processes every <img> (auto width/height → no CLS, srcset, AVIF/WebP). Override heroes to loading="eager" fetchpriority="high".
• Pagination: each page a unique URL + pagination.alias; default to self-referencing canonicals; rel=prev/next no longer a ranking signal.
• Template language doesn’t affect SEO — pick by familiarity. v3 is ESM-first (require() needs .cjs or "type":"module") and makes Image Transform the default.
• Plugins add convenience, not capability — the manual base-layout approach does everything they do.
• Three edge cases to test, not assume: layered eleventyComputed values can depend on each other and fail silently if ordering breaks; collections.all membership doesn’t guarantee a URL was actually emitted (check for permalink: false); and a local _site build proves nothing about production — verify the live canonical host, sitemap, suppressed pages, assets, and status codes directly on the deployed site.

Official documentation

Primary-source documentation — from Eleventy, the SEO plugins, and the search engines.

Eleventy

• Eleventy docs home — the starting point.
• Image plugin (@11ty/eleventy-img) — Image Transform, responsive images, width/height.
• Permalinks — clean URLs, slugify, permalink: false, trailing slashes.
• Pagination — splitting collections, pagination.alias, per-page URLs.
• Performance — Eleventy’s build-speed and zero-JS benchmarks.
• Passthrough copy — how to ship a static robots.txt.
• Community plugins — the SEO/sitemap/schema plugin index.
• Eleventy v3 announcement — ESM-first, faster builds, Image Transform.

SEO / sitemap / schema plugins

• eleventy-plugin-seo (artstorm) — title, description, canonical, robots, OG, Twitter Card.
• eleventy-plugin-metagen (tannerdolby) — granular meta-tag generation.
• @quasibit/eleventy-plugin-sitemap — sitemap with multilingual alternates.
• @quasibit/eleventy-plugin-schema — JSON-LD (BlogPosting, WebPage).

Google

• Consolidate duplicate URLs (canonicals + pagination) — the canonical and pagination guidance that informs the SEO decisions above.

Quotes from the source

There are no on-the-record statements from Google or Bing reps specifically about Eleventy — the search engines don’t comment on individual static site generators. The applicable guidance is the general principle that pre-rendered HTML is the lowest-risk thing you can serve, which is exactly what Eleventy outputs.

Google — pre-rendered HTML is simplest

• John Mueller has repeatedly made the general point that while Google can render JavaScript, serving the HTML directly is simpler and faster. The exact wording varies across Search Central office-hours and threads, and no statement specifically referencing Eleventy was found — so I’m not quoting a verbatim line here. The takeaway holds regardless: Eleventy’s default output is the “just serve the HTML” case.

Eleventy SEO checklist

A pass to confirm your Eleventy site is actually configured for search — because Eleventy did none of it for you:

• SEO defaults declared once in _data/site.js (title, description, url, author, default OG image).
• A base layout owns the <head> with <title>, meta description, OG, and Twitter Card tags pulling from the cascade.
• A canonical is set on every page (Eleventy has none built in) — ideally derived in eleventyComputed from site.url + page.url.
• Draft/preview/section pages that shouldn’t rank carry noindex (set at the directory data file where possible).
• A sitemap is generated — template over collections.all or @quasibit/eleventy-plugin-sitemap — and utility pages are excluded with eleventyExcludeFromCollections: true.
• robots.txt exists (passthrough copy or template), references the sitemap, and does not block JS/CSS or pages you want indexed.
• Images run through @11ty/eleventy-img (Image Transform in v3) so width, height, srcset, and modern formats are emitted — heroes overridden to loading="eager" fetchpriority="high".
• Permalinks are clean and trailing-slash consistent sitewide.
• Paginated sets give each page a unique URL and a self-referencing canonical (unless deep pages are genuinely thin → noindex).
• Structured data (Organization/WebSite sitewide, BlogPosting/Article per post) is emitted in the layout or via a schema plugin.
• Content edits trigger a rebuild + redeploy — a static site only reflects its last build.
• The live, deployed site is checked directly — raw HTML, canonical host, /sitemap.xml, suppressed/utility pages, asset paths, and status codes — not just the local _site build. A local build doesn’t prove what production serves.

The data → template → artifact framework

Eleventy SEO problems usually enter at one of three stages:

1. Data: frontmatter and the data cascade define titles, descriptions, canonicals, language, publication state, and structured-data values.
2. Template: layouts transform that data into consistent head markup and links.
3. Artifact: the generated _site HTML, sitemap, and robots file are what crawlers receive.

Validate in that order when diagnosing the source of a bad value, but validate the built artifact before release. A correct frontmatter field is irrelevant if a layout does not render it or a collection still publishes a draft route.

Eleventy SEO — cheat sheet

Who generates what

The data cascade (low → high priority)

1. Eleventy global data
2. _data/ global files (site.js)
3. Directory data files (blog.11tydata.js)
4. Template front matter
5. eleventyComputed (derive canonical here)

Plugin shortlist

• eleventy-plugin-seo (artstorm) — the leading meta-tag plugin; {% seo %} shortcode.
• eleventy-plugin-metagen — granular meta tags.
• @quasibit/eleventy-plugin-sitemap — sitemap + multilingual alternates.
• @quasibit/eleventy-plugin-schema — JSON-LD.
• @11ty/eleventy-img — images.

Fast facts

• Template language (Nunjucks / Liquid / Markdown / WebC / HTML / JS) → no SEO difference; pick by familiarity.
• v3 is ESM-first: require() config → rename to .cjs or set "type": "module".
• Exclude utility pages: eleventyExcludeFromCollections: true.
• Pagination: self-referencing canonicals by default; rel=prev/next no longer a ranking signal.
• Plugins = convenience, not capability.

Scaffold an SEO-ready Eleventy site

A starting point: create the global data file and a base-layout <head> so every page inherits correct meta tags from the cascade.

macOS / Linux

# In your Eleventy project root
mkdir -p src/_data src/_includes/layouts

cat > src/_data/site.js <<'EOF'
module.exports = {
  title: "Your Site",
  description: "Your default site description.",
  url: "https://example.com",
  author: "Your Name",
};
EOF

# Derive a self-referencing canonical for every page via the data cascade
cat > src/_data/eleventyComputed.js <<'EOF'
module.exports = {
  canonical: (data) => `${data.site.url}${data.page.url}`,
};
EOF

Windows (PowerShell)

# In your Eleventy project root
New-Item -ItemType Directory -Force -Path src\_data, src\_includes\layouts | Out-Null

@'
module.exports = {
  title: "Your Site",
  description: "Your default site description.",
  url: "https://example.com",
  author: "Your Name",
};
'@ | Set-Content src\_data\site.js

@'
module.exports = {
  canonical: (data) => `${data.site.url}${data.page.url}`,
};
'@ | Set-Content src\_data\eleventyComputed.js

Confirm your built HTML has the SEO markup

After a build, the content (and your meta tags) should be in the raw HTML — no JS required. Check the output directory directly.

macOS / Linux

# Build, then grep the output for the tags Eleventy does NOT add for you
npx @11ty/eleventy
grep -o '<link rel="canonical"[^>]*>' _site/index.html
grep -o '<title>[^<]*</title>'        _site/index.html
# Confirm robots.txt and sitemap.xml actually shipped
ls -l _site/robots.txt _site/sitemap.xml

Windows (PowerShell)

npx @11ty/eleventy
Select-String -Path _site\index.html -Pattern '<link rel="canonical"'
Select-String -Path _site\index.html -Pattern '<title>'
Get-Item _site\robots.txt, _site\sitemap.xml

If grep/Select-String finds nothing, the markup isn’t there — remember Eleventy won’t add it on its own.

Tools for Eleventy SEO

• eleventy-plugin-seo (artstorm) — the leading meta-tag plugin: title, description, canonical, robots, OG, and Twitter Card from one {% seo %} shortcode.
• eleventy-plugin-metagen (tannerdolby) — granular, parameterized meta-tag generation when you want fine control.
• @11ty/eleventy-img — image optimization; the v3 Image Transform plugin auto-stamps width/height, builds srcset, and emits AVIF/WebP.
• @quasibit/eleventy-plugin-sitemap — sitemap generation with multilingual alternate links.
• @quasibit/eleventy-plugin-schema — JSON-LD (BlogPosting, WebPage).
• @11ty/eleventy-plugin-rss — RSS/Atom feeds (updated for v3).
• Lighthouse / PageSpeed Insights — verify the Core Web Vitals your static output should be acing.
• Google Search Console URL Inspection — confirm the rendered HTML matches your built HTML (it should, since there’s nothing to render) and that canonicals resolve.
• Screaming Frog / Ahrefs Site Audit — crawl the built site to catch missing titles, missing canonicals, trailing-slash duplicates, and orphaned output files.

Eleventy SEO anti-patterns

Concrete mistakes I see on real Eleventy sites — every one of them comes from treating Eleventy’s clean HTML output as if it were finished SEO work, when it’s just the starting point.

Assuming Eleventy “handles SEO”

The mistake: Shipping a site on the strength of Eleventy’s zero-JS output and Lighthouse 99–100 scores, without ever adding a title, meta description, or canonical.

Why it’s wrong: Eleventy only handles rendering — it builds clean HTML and stops there. Fast, crawlable HTML with no <title> tag still isn’t going to rank for anything specific; Google needs the actual on-page signals, and none of them are generated for you.

What to do instead: Build the SEO meta tags into your base layout on day one, before you write a single content page — see the Advanced tab’s “Meta tags in the base layout” section. Every page should inherit title, description, and canonical from the data cascade automatically.

Forgetting the canonical entirely

The mistake: Leaving <link rel="canonical"> out of the layout because it “felt automatic” — it isn’t.

Why it’s wrong: Eleventy has no built-in canonical. Without one, you’re relying on Google to guess the preferred URL, which matters more than it seems once trailing-slash variants, ?utm_ params, or paginated pages enter the picture.

What to do instead: Derive it once in eleventyComputed — canonical: (data) => `${data.site.url}${data.page.url}` — so every page gets a correct self-referencing canonical with zero per-page effort.

Shipping without a sitemap

The mistake: Assuming a sitemap gets generated as part of the build, the same way Eleventy generates the HTML files.

Why it’s wrong: It doesn’t. A missing sitemap doesn’t break crawling on a small site, but on anything with more than a handful of pages it slows discovery of new and updated content.

What to do instead: Add a sitemap.xml.njk template that loops over collections.all, or install @quasibit/eleventy-plugin-sitemap. Either way, tag utility pages eleventyExcludeFromCollections: true so they don’t leak into it.

Letting unoptimized images undo the speed advantage

The mistake: Dropping raw JPEGs/PNGs straight into templates because “the site is already fast” thanks to zero JS.

Why it’s wrong: A zero-JS homepage with a 4 MB hero image still fails LCP and CLS — the JS advantage doesn’t touch image weight or missing width/height attributes.

What to do instead: Run images through @11ty/eleventy-img (the Image Transform plugin in v3), which auto-stamps width/height, builds srcset, and emits AVIF/WebP — then override above-the-fold heroes to loading="eager" fetchpriority="high" so they don’t get lazy-loaded out of your LCP window.

Inconsistent trailing slashes

The mistake: Linking to /about in some templates and /about/ in others, or letting a redirect layer paper over both existing.

Why it’s wrong: Eleventy’s default output is /about/ (a directory with an index.html). Mixed internal links split link equity and crawl budget across two URLs that render the same content — a duplicate-content own-goal you created yourself, not one Eleventy created for you.

What to do instead: Pick one form (Eleventy’s default trailing slash is the path of least resistance) and enforce it in every internal link and in permalink overrides. Spot-check with a crawl — my Redirect Checker will surface redirect chains if a slash mismatch is being papered over with 301s instead of fixed at the source.

Using Disallow to try to deindex a page

The mistake: Adding a Disallow rule in robots.txt to remove a page that’s already indexed.

Why it’s wrong: Disallow blocks crawling, not indexing. If the page is already indexed, blocking the crawl just means Google can no longer see a noindex tag you add later — the URL can persist in the index with no snippet.

What to do instead: Add <meta name="robots" content="noindex"> to the page (via front matter or a directory data file) and let Google crawl it long enough to see and honor that tag. Only add Disallow for content you never want crawled in the first place.

Test yourself: Eleventy SEO

Five quick questions on optimizing an Eleventy (11ty) site for search. Pick an answer for each, then check.

Resources worth your time

My related writing

• JavaScript SEO: A Definitive Guide — rendering, DOM parity, and why static/prerendered output (Eleventy’s default) is the low-risk end of the spectrum.
• The Beginner’s Guide to Technical SEO — where rendering architecture and on-page configuration fit in the bigger picture.

My speaking

• How Search Works (SlideShare) — my walkthrough of crawling, rendering, indexing, and ranking. (My standing disclaimer applies: “This is my understanding of systems… not going to be 100% complete or accurate.”)

From around the industry

• Eleventy docs — the primary source for everything in this guide.
• Eleventy Image plugin — the v3 Image Transform path to responsive, CLS-safe images.
• eleventy-plugin-seo (artstorm) — the leading meta-tag plugin’s README and config reference.
• @quasibit/eleventy-plugin-sitemap — sitemap generation with multilingual alternates.
• Create a sitemap for your Eleventy website (DEV.to) — a clear walkthrough of the manual collections.all template approach.
• Adding robots.txt to an Eleventy site (Mike Fallows) — passthrough vs. environment-specific template generation.
• Add structured data to an Eleventy blog (Maxi Vanov) — manual JSON-LD patterns beyond BlogPosting.

Eleventy SEO

Eleventy (11ty) is a JavaScript-based static site generator that outputs plain HTML with zero client-side JavaScript by default. Eleventy SEO is the practice of explicitly configuring that output — meta tags, canonicals, sitemaps, images, and structured data — because Eleventy generates none of it for you.

Related: Static Site Generator, JavaScript SEO

Eleventy SEO

Eleventy (11ty) is a Node.js static site generator that turns templates and Markdown into finished HTML at build time, shipping zero client-side JavaScript by default. That makes it one of the safest possible architectures for indexability: your content is in the raw HTML on the first fetch, so there’s no rendering step for a crawler to wait on. “Eleventy SEO” is the work of configuring that clean output for search — and the key word is configuring, because Eleventy generates no <title>, meta description, canonical, sitemap, or structured data on its own.

The architectural lever is Eleventy’s data cascade: values resolve from global _data/ files (like site.js) up through directory data files, page front matter, and finally eleventyComputed for derived values such as a self-referencing canonical. Declare your SEO defaults once, override them per section, and compute the rest — that’s how you scale correct <head> markup across thousands of pages without hand-editing each one.

Three things make up most of the day-to-day work: meta tags in a shared base layout (manually, or via eleventy-plugin-seo), a sitemap (a Nunjucks template over collections.all, or @quasibit/eleventy-plugin-sitemap), and a passthrough-copied robots.txt. Add @11ty/eleventy-img — and in v3 its Image Transform plugin — to get responsive, width/height-stamped images that keep Core Web Vitals clean. The template language you pick (Nunjucks, Liquid, Markdown, WebC, HTML, JavaScript) doesn’t affect SEO; choose by team familiarity.

Related: Static Site Generator, JavaScript SEO

Changelog