DECAP CMS SEO AUDIT · GIT-BASED CMS · JAMSTACK · STATIC SITE GENERATORS
Free Decap CMS SEO Audit
Decap CMS (formerly Netlify CMS) is an open-source Git-based headless CMS — content is stored as YAML frontmatter in Markdown files committed directly to your Git repository, consumed by static site generators (Next.js, Gatsby, Hugo, Eleventy, Astro, SvelteKit) at build time. The pre-rendered static HTML is optimal for SEO: no JavaScript rendering gap, sub-50ms TTFB from CDN edge, all meta tags and JSON-LD in the initial HTML response. DeepSEOAnalysis audits the rendered output — validating frontmatter-derived meta tags, JSON-LD from config.yml fields, static sitemap coverage with draft and no_index filtering, real CrUX Core Web Vitals, and all five AI visibility signals — free with no signup.
WHAT WE CHECK
6 Decap CMS-specific SEO checks
Decap CMS SEO auditing covers frontmatter field mapping to generateMetadata() output (seo_title, seo_description, canonical_url, og_image path-to-absolute-URL conversion, no_index, /admin Disallow in robots.txt), Git-backed URL routing with slug quality and draft filtering, JSON-LD from frontmatter fields (datePublished from date widget, dateModified from lastmod field, author from string or relation field, og_image relative-to-absolute conversion, faq_items list widget for FAQPage), static sitemap with collection coverage and no_index/draft exclusion, real CrUX Core Web Vitals for Jamstack CDN deployments, and AI visibility for content-heavy static sites.
Decap CMS frontmatter SEO fields and generateMetadata() output
Decap CMS stores SEO data as YAML frontmatter in content Markdown files, collected via fields defined in `config.yml`. The audit validates the rendered meta tag output — not the raw frontmatter — by crawling the live HTML. Key checks: meta title quality (the `seo_title` frontmatter field should map to `title` and `og:title`; when empty, the fallback is the post\'s display `title` which may be optimised for reading rather than search; all entries relying on unoptimised title fallbacks are flagged); meta description coverage (`seo_description` field — empty means the `meta name="description"` tag is absent or uses an auto-generated excerpt; missing descriptions are flagged with character-count guidance for the character field hint); canonical tag accuracy (`canonical_url` frontmatter field — when empty, the frontend must construct the canonical from the page\'s slug and site origin; malformed or missing canonical tags are flagged); OG image (`og_image` frontmatter field — Decap CMS stores this as a relative path to the public directory; the frontend must prepend the site origin to create an absolute URL for `og:image` and Article `image` JSON-LD; relative OG image URLs are flagged); no_index field vs sitemap consistency (`no_index: true` in frontmatter must simultaneously produce `meta name="robots" content="noindex"` AND exclude the page from the sitemap; inconsistencies are flagged); Decap CMS `/admin` access (`/admin` must appear in `robots.txt` Disallow to prevent Googlebot from indexing the CMS interface — the audit checks robots.txt for this rule); and schema_type field usage (if a schema_type frontmatter field is defined for selecting JSON-LD type per post, the audit verifies the rendered JSON-LD matches the selected type).
Git-backed URL routing and content file structure
Decap CMS saves content as individual Markdown files in the Git repository at the path defined in the collection\'s `folder` field. The filename typically becomes the URL slug. The audit checks: slug quality (Decap CMS auto-generates slugs from the title in the admin UI; slugs longer than 70 characters, containing stop words, or mismatching the content\'s target keyword are flagged); slug consistency after file rename (Decap CMS allows renaming content files, which changes the slug — without a redirect from the old path, any backlinks or GSC-indexed URLs to the original slug become 404s; the audit identifies 404 responses and flags missing redirects); `generateStaticParams()` coverage (Next.js static generation reads all markdown files from the `content/` directory at build time; the audit verifies all sitemap URLs return 200, with 404 responses indicating files that weren\'t included in `generateStaticParams()`); draft and no_index filtering (Decap CMS doesn\'t have a publish workflow in the same sense as database-backed CMSes — draft posts may exist in the repository but should be filtered from `getStaticPaths()` / `generateStaticParams()` via a `draft: true` frontmatter convention; the audit checks for draft-like pages accessible at public URLs); redirect management (Decap CMS has no built-in redirect management — slug changes require adding redirects to Netlify\'s `_redirects` file, `vercel.json`, or Cloudflare Pages `_redirects`; the audit checks for redirect chains that indicate prior slug migrations without redirect cleanup); and collection coverage (Decap CMS supports multiple collections — posts, pages, team members, case studies; the audit checks whether all collections with public-facing URLs are included in the sitemap).
JSON-LD from frontmatter fields
Decap CMS frontmatter fields provide all the data for JSON-LD structured data implemented in the static site generator\'s layout components. The audit validates all JSON-LD against Google\'s Rich Results specifications. For `Article` JSON-LD: `headline` from `seo_title` or `title` — must be under 110 characters (a hint in the `config.yml` field definition helps editors stay within the limit: `"hint: max 60 characters for SEO title"`, but JSON-LD validation requires the rendered value check); `datePublished` from the `date` or `publishedAt` frontmatter field — Decap CMS includes a datetime widget for publication date; must be formatted as ISO 8601 in the JSON-LD (`new Date(post.date).toISOString()`); `dateModified` from a `lastmod` or `updated_at` field — Decap CMS doesn\'t auto-update a modification date field on edit (unlike database-backed CMSes that track `updatedAt`); if no `lastmod` field is defined in `config.yml`, `dateModified` will equal `datePublished` or be absent; `author` from `author` frontmatter field — defined as a string (author name) or a relation field pointing to an authors collection; if using a string field, the name is directly available; if using a relation, the author collection entry must be read separately at build time; `image` from `og_image` field — relative path must be converted to absolute URL at build time. For `FAQPage` JSON-LD: define an `faq_items` field in `config.yml` as a list widget with `fields: [{name: question, widget: string}, {name: answer, widget: text}]` — the list of question/answer pairs maps directly to FAQPage `mainEntity`. The audit validates property completeness for each JSON-LD type found on crawled pages. Common Decap CMS-specific errors: relative `og_image` path used directly as Article `image.url`; `dateModified` absent when no `lastmod` field is defined; author field empty (left blank in admin panel); `headline` exceeding 110 characters when the post `title` display field is used without a separate length-validated `seo_title` field.
Static site generator sitemap and robots.txt
Decap CMS-powered sites generate sitemaps at build time from the content files in the Git repository. The audit checks: sitemap accessibility (`/sitemap.xml` returns valid XML and is accessible); collection coverage (all public-facing content types — blog posts, pages, case studies, documentation — should be included in the sitemap; content collections omitted from the sitemap deprive Google of discovery signals); `lastmod` accuracy (the most common `lastmod` source in Decap CMS-powered sitemaps is the file\'s Git `mtime` or the `date` frontmatter field; for accurate `lastmod`, the sitemap generator should use the Git commit timestamp of the content file — available via `git log --follow -1 --format="%aI" -- path/to/file` at build time — rather than the frontmatter `date` field, which reflects publish date not last-edit date; using the frontmatter `date` means `lastmod` never updates for refreshed content); `no_index` exclusion (pages with `no_index: true` in frontmatter must be filtered from the sitemap at build time — the sitemap generation logic must read frontmatter and exclude `no_index` pages); draft exclusion (similar to no_index — pages with `draft: true` in frontmatter must be filtered from the sitemap); robots.txt (must contain `Disallow: /admin` to prevent Googlebot from indexing the Decap CMS admin interface; the admin panel is a single-page application that shouldn\'t be indexed; `User-agent: *\nDisallow: /admin/` should appear in `robots.txt` or `app/robots.ts`); sitemap URL in robots.txt (`Sitemap: https://example.com/sitemap.xml` should appear at the bottom of `robots.txt` or be generated by `app/robots.ts`).
Core Web Vitals for Jamstack / static sites
Decap CMS-powered sites built with static site generators are among the best-performing web architectures for Core Web Vitals — pre-rendered static HTML served from CDN edges achieves results that database-driven dynamic CMSes structurally cannot match. The audit uses real CrUX field data. **TTFB** — static HTML served from Netlify Edge, Vercel Edge, or Cloudflare Pages achieves sub-50ms TTFB for most users globally. If TTFB is high on a static Decap CMS site, the likely cause is CDN misconfiguration (page bypassing the edge cache), excessive use of ISR/SSR rather than full static generation, or a custom hosting environment without CDN. **LCP** — the primary LCP risk on static sites is unoptimised images: (a) Decap CMS `og_image` field stores the file path in frontmatter; the image must be processed at build time with dimensions to avoid layout shift and to generate correctly-sized formats (WebP, AVIF); (b) Next.js: configure the `og_image` path as a Next.js `Image` component with `priority` on the above-the-fold image and the correct `width`/`height` from the processed image; (c) Gatsby: use `gatsby-image` / `GatsbyImage` for automatic image optimisation from frontmatter paths; (d) Hugo: use Hugo image processing (`image.Resize`, `image.Process`) to generate WebP variants and correct dimensions. **INP** — minimal concern for static sites with limited client-side JavaScript; third-party scripts (chat, analytics, embeds) are the primary risk. **CLS** — images without dimensions are the primary CLS source; fixing with build-time image processing resolves most CLS issues on static sites.
AI visibility for Decap CMS sites
Decap CMS powers many developer-focused, documentation, and content-heavy static sites — categories frequently cited by AI systems. The architecture\'s static nature makes AI visibility implementation straightforward: all AI visibility signals can be rendered at build time into static HTML. The audit checks all five signals. For `llms.txt`: generate a static `public/llms.txt` at build time by reading all content files and extracting titles, slugs, and brief summaries — or use a build script that generates the file during CI/CD. Alternatively, `app/llms.txt/route.ts` (in Next.js App Router) can read content files on the server and return the formatted llms.txt. For `robots.txt`: `app/robots.ts` (Next.js) or `public/robots.txt` (other frameworks) must allow GPTBot, ClaudeBot, PerplexityBot, Google-Extended, and CCBot; disallow `/admin`; and declare the sitemap URL. The audit verifies no AI crawlers are blocked in the Disallow rules. For `FAQPage` JSON-LD: implemented via the `faq_items` list widget in Decap CMS `config.yml` and rendered as FAQPage JSON-LD in the layout component at build time — the audit validates the server-rendered JSON-LD in the static HTML. For question-heading ratio: Markdown content rendered via the Decap CMS admin (using the Markdown widget) produces standard heading HTML; the audit checks whether ≥20% of H2/H3 headings are question-format for AI Overview citation eligibility. For content chunkability: average section length in the rendered HTML is measured against the ≤400-word target; Markdown naturally produces section-chunked content via headings.
HOW IT WORKS
Audit your Decap CMS site in 60 seconds
- Enter your frontend URL. Use the public URL of your static site generated from Decap CMS content — whether deployed on Netlify, Vercel, Cloudflare Pages, GitHub Pages, or self-hosted. No Git repository access, no Decap CMS admin credentials, no Netlify API token needed. Works with any frontend consuming Decap CMS content files: Next.js with generateStaticParams(), Gatsby, Hugo, Eleventy, Astro, SvelteKit, or any other static site generator.
- We crawl and analyse. The engine validates all meta tags generated from frontmatter fields; checks every JSON-LD block (Article, FAQPage) against Google's Rich Results specs with property-level errors including relative og_image paths used as Article image.url, missing dateModified when no lastmod frontmatter field is defined, and author fields empty from the admin panel; verifies the static sitemap covers all public content collections with correct no_index and draft filtering; measures CrUX Core Web Vitals from real Chrome field data including image optimisation quality for LCP; and evaluates all five AI visibility signals.
- You get a prioritised report. Decap CMS-specific issues first — seo_title field empty causing unoptimised meta title fallback, og_image relative path used directly in JSON-LD without absolute URL conversion, /admin not in robots.txt Disallow, missing faq_items list widget definition preventing FAQPage JSON-LD, draft posts accessible at public URLs due to missing frontmatter filter — then general SEO findings, each with the config.yml field name and frontend template location for the fix.
FAQ
Questions about the Decap CMS SEO audit
What is Decap CMS and how does it affect SEO?
Decap CMS (decapcms.org, formerly Netlify CMS) is an open-source Git-based headless CMS. Content is stored as Markdown or MDX files directly in a Git repository — editors use the Decap CMS admin panel (typically at `/admin`) and changes are committed directly to the Git repo. The frontend (Next.js, Gatsby, Hugo, Eleventy, Astro, SvelteKit, or any static site generator) reads content files from the filesystem at build time and generates static HTML. SEO implications of the Git-based architecture: (1) **Frontmatter is the SEO data layer** — Decap CMS collects SEO data via frontmatter fields in the content files. Fields defined in `config.yml` (or `config.ts` for Decap CMS 3.x) appear as inputs in the admin panel; their values are saved in the Markdown file\'s YAML frontmatter. Common SEO fields: `seo_title: string`, `seo_description: string`, `canonical_url: string`, `og_image: image` (stored as a relative path in the public/static directory), `no_index: boolean`, and `schema_type: select`. These frontmatter values are read by the frontend at build time and used in `generateMetadata()` (Next.js) or equivalent framework metadata functions. (2) **Static HTML output** — because Decap CMS powers static site generators, the final output is pre-rendered HTML. All meta tags, JSON-LD, canonical tags, and body content are in the initial HTML response — no JavaScript rendering gap. Googlebot can index the full content without executing JavaScript. (3) **Build-time content** — content changes require a rebuild and redeploy to take effect. SEO changes (fixing a meta description, adding a canonical URL) are not live until the next build. CI/CD integration with Netlify, Vercel, or Cloudflare Pages typically auto-builds on Git push, meaning admin panel saves trigger rebuilds via the Git commit hook. (4) **Admin panel access** — the Decap CMS admin panel at `/admin` must be excluded from search indexing via robots.txt or the `noindex` meta tag to prevent Google from indexing the CMS interface.
How do I implement SEO fields in Decap CMS config.yml?
Decap CMS 2.x uses `config.yml` (or `public/admin/config.yml` in the web build) to define the content schema. SEO fields are added as additional fields within a collection. Example for a blog posts collection in `config.yml`: define fields including `name: seo_title` (widget: string, label: SEO Title, required: false, hint: "Leave blank to use post title (max 60 chars)"), `name: seo_description` (widget: text, label: SEO Description, required: false, hint: "max 160 chars"), `name: canonical_url` (widget: string, label: Canonical URL, required: false, hint: "Full URL including https://"), `name: og_image` (widget: image, label: OG Image, required: false — stored as path to the public directory), `name: no_index` (widget: boolean, label: No Index, default: false), and `name: schema_type` (widget: select, options: ["article", "how-to", "faq-page"]). In Decap CMS 3.x (`config.ts`), the same fields are defined in TypeScript with the same structure via `defineConfig()`. In the Next.js frontend, read the frontmatter with `gray-matter` (for MDX) or the static site generator\'s built-in frontmatter parser. Then in `generateMetadata()`: `return { title: post.seo_title || post.title, description: post.seo_description, alternates: { canonical: post.canonical_url || \`/blog/${post.slug}\` }, openGraph: { images: post.og_image ? [{ url: absoluteUrl(post.og_image) }] : [] }, robots: post.no_index ? "noindex" : undefined }`. The `og_image` value from Decap CMS is a relative path — prepend the site origin for the absolute URL required by OG tags and Article JSON-LD. The audit validates all of these in the rendered HTML output.
How does Decap CMS work with static site generators for Core Web Vitals?
Decap CMS stores content as Markdown files in a Git repository. The frontend static site generator reads those files at build time and generates pre-rendered HTML pages. This architecture is optimal for Core Web Vitals: (1) **TTFB** — static HTML served from a CDN (Netlify Edge, Vercel Edge, Cloudflare Pages) achieves sub-50ms TTFB globally. No server-side processing, database queries, or API calls on the critical request path. This is the best achievable TTFB for any CMS architecture. (2) **LCP** — the LCP element is typically the hero image or featured image from the `og_image` frontmatter field. In Next.js with static generation: configure `Image` with `priority` on the above-the-fold image, use the `width` and `height` of the image (Decap CMS\'s image widget stores the file path; the dimensions must be read from the image file at build time or hard-coded per content type). In Hugo or Gatsby: use the framework\'s image processing utilities to generate responsive images at build time, which produce correct dimensions without layout shift. (3) **CLS** — the most common CLS source with Decap CMS-powered sites is images rendered without dimensions. Fix by processing images at build time (Gatsby Image, Next.js Image, Hugo image resources) to generate the `width` and `height` attributes that prevent layout shift. (4) **INP** — static sites generated from Decap CMS typically have minimal client-side JavaScript, making INP naturally low. Third-party scripts (comments, chat widgets, analytics) are the primary INP risk. The real CrUX field data in the DeepSEOAnalysis audit captures actual user experience performance from the CDN edge, not Lighthouse lab estimates.
Is the Decap CMS SEO audit free?
Yes. The complete audit is free with no signup and no email gate. Enter the URL of your frontend application — the static site generated from Decap CMS content (whether on Netlify, Vercel, Cloudflare Pages, or self-hosted). The audit crawls the server-rendered HTML output as Googlebot would. No Git repository access, no Decap CMS admin credentials, no Netlify account access needed. Works with any frontend generating static HTML from Decap CMS content: Next.js with `generateStaticParams()`, Gatsby, Hugo, Eleventy, Astro, SvelteKit, or any other static site generator. Paid DeepSEOAnalysis plans add saved report history, scheduled monitoring for larger crawls, and white-label agency reporting.