WEBINY SEO AUDIT · SERVERLESS HEADLESS CMS · AWS LAMBDA · NEXT.JS

Free Webiny SEO Audit

Webiny is an open-source serverless headless CMS on AWS — content models define SEO fields (seoTitle, seoDescription, ogImage, noIndex) that are populated in the Webiny editor and consumed via the Headless CMS GraphQL API in the Next.js frontend. Lambda cold starts affect TTFB; ISR with lifecycle event webhooks is essential. DeepSEOAnalysis audits the rendered HTML — validating JSON-LD from Webiny content model fields, real CrUX Core Web Vitals including Lambda TTFB impact, GraphQL API sitemap coverage, and all five AI visibility signals — free with no signup.

Audit my Webiny site →How we score

WHAT WE CHECK

6 Webiny-specific SEO checks

Webiny SEO auditing covers content model SEO fields and generateMetadata() output, Headless CMS URL routing with draft status filtering, JSON-LD from GraphQL API fields (using Webiny system fields createdOn/savedOn for datePublished/dateModified, File Manager CloudFront URLs for images, reference fields for author resolution), GraphQL API sitemap with pagination and draft exclusion, real CrUX Core Web Vitals including Lambda cold start TTFB impact and File Manager CDN image optimisation, and AI visibility for developer and SaaS content sites.

🔧

Webiny content model SEO fields and generateMetadata() output

Webiny\'s content model editor allows developers to add SEO field groups to any content type. The audit validates the rendered frontend meta tag output. The audit checks: meta title quality (the `seoTitle` Text field feeds `generateMetadata()` — empty `seoTitle` falls back to the entry\'s `title` field, which is typically the display title rather than a search-optimised title; all entries relying on this fallback are flagged); meta description coverage (`seoDescription` Long text field — empty means no meta description in the rendered page; the audit flags all entries missing a meta description); canonical tag accuracy (`canonicalUrl` Text field — if not set, the frontend must construct the canonical from the entry slug and site origin; missing canonical tags are flagged); OG image (`ogImage` File field returning a CloudFront CDN URL — must be an absolute URL included in `og:image`; the audit validates the URL is absolute and accessible); noindex consistency (`noIndex` Switch field — must trigger `metadata.robots = "noindex"` in `generateMetadata()` AND exclude the entry from the sitemap; inconsistencies between noindex status and sitemap inclusion are flagged); Webiny Page Builder vs Headless CMS (Webiny has two content authoring modes — Page Builder pages with their own SEO settings panel and Headless CMS entries with SEO fields in the content model; the audit detects which mode is powering the rendered page and validates accordingly); and Read API token exposure (checking that Webiny API tokens don\'t appear in client-side JavaScript bundles — a security risk if the manage API token is exposed).

🔗

Webiny Headless CMS URL routing and content entry structure

Webiny Headless CMS content entries are accessed by slug or ID via the GraphQL API; URL routing is entirely determined by the frontend framework. The audit checks: slug field quality (Webiny content models include a `slug` field (Text) that maps to the frontend URL slug — auto-generated slugs from the entry title may include stop words or be inconsistently formatted; the audit flags slugs that are over-long (>70 characters) or keyword-absent); `generateStaticParams()` coverage (Next.js static generation requires querying all published entries via the Webiny list query — the audit checks that all sitemap URLs return 200; 404s indicate gaps in `generateStaticParams()` or entries published in Webiny but not handled by the frontend route); draft content exposure (Webiny entries have a status of `draft` or `published` — the read API `where` clause must filter for `status: "published"` to prevent draft entries from being served to public users; the audit checks for draft entries accessible at public URLs by checking Webiny-specific response patterns); publish workflow timing (Webiny\'s ISR revalidation should be triggered via lifecycle event webhooks — if the `revalidate` interval is the only cache invalidation mechanism, newly published entries may take `revalidate` seconds to appear; the audit notes if ISR seems to be configured without webhook-based on-demand revalidation); tenant and locale routing (for multi-tenant or multi-locale Webiny deployments, the frontend must route correctly to the appropriate tenant/locale API; hreflang implementation on localised entries is checked); and redirect management (Webiny has no built-in redirect management — broken slugs after content restructuring must be handled via `next.config.js` redirects or a separate redirect content model).

📋

JSON-LD from Webiny Headless CMS content model fields

Webiny content model fields provide the data for JSON-LD structured data implemented in the Next.js frontend. The audit validates all JSON-LD against Google\'s Rich Results specifications. For `Article` JSON-LD: `headline` from `entry.seoTitle` or `entry.title` — must be under 110 characters (add a Webiny content model field validator: in the field settings, add a validation rule for maximum character count to enforce this at the editor level); `datePublished` from the entry\'s `createdOn` system field (Webiny automatically sets `createdOn` on entry creation — available in GraphQL queries without a dedicated field; format as ISO 8601 string); `dateModified` from `savedOn` (Webiny sets `savedOn` on every save/publish — use this for `dateModified`; updated on every publish event, keeping `dateModified` current); `author` from a `ref` field pointing to an Authors model (Webiny supports reference fields between content models — use a `{ modelId: "author" }` ref field; in the GraphQL query, use a nested query to resolve the author entry and access `author.name`); `image` from `entry.ogImage.url` (the File Manager URL — already absolute from CloudFront CDN; ensure the `url` property is included in the GraphQL ogImage selection set). For `FAQPage` JSON-LD: add a `faqItems` field using Webiny\'s `object` field type (list of objects each with `question` Text and `answer` Long text sub-fields) — in the GraphQL query, include `faqItems { question answer }`; map to FAQPage `mainEntity` array in the server component. Common Webiny-specific JSON-LD errors: `headline` too long when `entry.title` (display title) is used without a separate `seoTitle` field with length validation; `datePublished` absent when the frontend queries the Webiny API without requesting the `createdOn` system field; OG image and Article `image` diverging when `ogImage` and `featuredImage` are separate fields.

🗺️

Webiny GraphQL API sitemap and crawl configuration

Webiny has no native sitemap generation — the Next.js frontend queries the Webiny Headless CMS GraphQL API to build `app/sitemap.ts`. The audit checks: sitemap accessibility (/sitemap.xml must return valid XML and be accessible); content model coverage (the sitemap should include all published entries across all relevant content models — articles, pages, case studies, documentation — each requiring a separate GraphQL list query per model; missing content models leave significant content undiscovered by Googlebot); Webiny list query pagination (Webiny\'s GraphQL list queries default to returning 1,000 entries with cursor-based pagination support; for content sets exceeding 1,000 entries, the sitemap query must paginate using the `after` cursor from the `meta.cursor` field); `lastmod` from `savedOn` (the Webiny `savedOn` system field tracks the last content update — map to sitemap `lastModified` via `new Date(entry.savedOn).toISOString()`); draft exclusion (the Webiny read API list query must include `where: { status: "published" }` to exclude draft and unpublished entries from the sitemap); noindex exclusion (entries with `noIndex: true` must be filtered out of the sitemap — add `noIndex_not: true` to the `where` clause, or filter after retrieval); and robots.txt (the Webiny admin panel at `[webiny-admin-url]` should be disallowed; `app/robots.ts` should declare the sitemap URL).

⚡

Core Web Vitals for Webiny serverless deployments

Webiny\'s serverless AWS architecture creates distinct Core Web Vitals challenges. The audit uses real CrUX field data. **TTFB and Lambda cold starts** — the most significant performance risk in Webiny deployments. Lambda cold starts (100ms–3s) spike TTFB for the first request after an idle period. The primary mitigation is Next.js ISR or SSG: pre-rendered static HTML is served from the Next.js CDN (Vercel, Netlify, CloudFront) without Lambda invocation, achieving sub-100ms TTFB. If SSR is used, Lambda Provisioned Concurrency eliminates cold starts at additional cost. The audit detects high TTFB from the crawl request as a directional signal. **LCP** — the LCP element on Webiny-powered pages is typically the featured image from Webiny\'s File Manager (served from CloudFront CDN). Optimise: configure the CloudFront domain in `next.config.js` `images.remotePatterns`, use Next.js `Image` with `priority` on the featured image; request image dimensions from the Webiny GraphQL API (`ogImage { url width height }`) and pass to the `width`/`height` props on `Image` to prevent CLS. Webiny\'s File Manager supports S3 image processing — request WebP-format delivery if the CloudFront distribution is configured with image optimisation. **INP** — Webiny\'s frontend is developer-built; INP depends entirely on the frontend implementation. React Server Components for Webiny content queries minimises client-side JavaScript for the content display. **CLS** — image fields must include dimensions in the GraphQL query to prevent layout shift from images loading without reserved space. Webiny File Manager returns `width` and `height` for uploaded images — always request these in the GraphQL selection set.

🧠

AI visibility for Webiny-powered sites

Webiny is developer-focused — Webiny-powered sites typically serve technical content, documentation, or SaaS marketing pages — categories frequently cited by AI systems. The audit checks all five AI visibility signals. For `llms.txt`: Webiny has no native llms.txt generation. Add `app/llms.txt/route.ts` that generates llms.txt from a Webiny GraphQL list query — querying published entries across relevant content models and formatting their titles and URLs in the llms.txt structure. For self-hosted Webiny, this route can also be generated as a static file at build time if the content set is stable. For `robots.txt`: `app/robots.ts` must disallow the Webiny admin panel URL, allow all content paths, and ensure GPTBot, ClaudeBot, PerplexityBot, Google-Extended, and CCBot are not in any Disallow block. Self-hosted deployments should also check for security middleware or WAF rules that might block AI crawler user agents by default. For `FAQPage` JSON-LD: the `faqItems` object field in the Webiny content model (as described in the JSON-LD check) provides the question-answer pairs that map to FAQPage JSON-LD in the frontend server component — the audit verifies this is present in the server-rendered HTML. For question-heading ratio: Webiny\'s rich text editor (Lexical-based) renders heading elements as semantic `<h2>`/`<h3>` in the rendered HTML — the audit checks whether content includes sufficient question-format headings (≥20%) for AI Overview citation eligibility. For content chunkability: Webiny content rendered via the rich text field produces standard HTML paragraph and heading structure — average section length in the rendered HTML is measured against the ≤400-word target.

HOW IT WORKS

Audit your Webiny site in 60 seconds

Enter your frontend URL. Use the public URL of your Next.js (or other framework) frontend consuming the Webiny Headless CMS GraphQL API. No Webiny API token, AWS credentials, DynamoDB access, or admin panel credentials needed. Works with any frontend consuming Webiny: Next.js, Nuxt, SvelteKit, Gatsby, Astro, or custom React applications.
We crawl and analyse. The engine validates all meta tags generated from Webiny content model fields; checks every JSON-LD block (Article, FAQPage) against Google's Rich Results specs with property-level errors including missing datePublished (when `createdOn` system field isn't requested), null author from unresolved reference fields, and images without `width`/`height` causing CLS; verifies the GraphQL API sitemap covers all published entries with correct status filtering and pagination; measures CrUX Core Web Vitals from real Chrome field data including TTFB from Lambda cold starts; and evaluates all five AI visibility signals.
You get a prioritised report. Webiny-specific issues first — `seoTitle` field empty causing unoptimised meta title fallback, `datePublished` absent from Article JSON-LD because `createdOn` wasn't included in the GraphQL selection set, draft entries accessible at public URLs due to missing `status: "published"` filter, Lambda cold start TTFB spikes indicating missing ISR configuration, missing lifecycle event webhook for on-demand revalidation — then general SEO findings, each with the Webiny content model field path or Next.js integration location for the fix.

FAQ

Questions about the Webiny SEO audit

Does Webiny have built-in SEO features?

Webiny (webiny.com) is an open-source serverless headless CMS built on AWS (Lambda, DynamoDB, S3, CloudFront). SEO capabilities come from defining SEO fields in Webiny\'s content model and consuming them via the Headless CMS GraphQL API in the frontend application. Key Webiny SEO capabilities: (1) **SEO fields in content models** — Webiny\'s drag-and-drop content model editor allows developers to add SEO-specific field groups to any content type. Common SEO fields added to an Article or Page content type: seoTitle (Text field), seoDescription (Long text field), canonicalUrl (Text field), ogImage (File field from Webiny\'s File Manager), noIndex (Switch/Boolean field), and schema type selection. These fields appear as editor inputs in the Webiny content editor and are saved in Webiny\'s DynamoDB backend. (2) **Headless CMS GraphQL API** — Webiny exposes a read API (for frontend consumption) and a manage API (for CMS operations). The frontend application queries the read API to fetch content entries and their SEO fields, which are then used in `generateMetadata()` and JSON-LD components. (3) **File Manager for media** — Webiny\'s built-in File Manager stores media on S3 with CloudFront CDN delivery. Image fields (ogImage, featuredImage) in content models reference File Manager files — the GraphQL query returns the S3/CloudFront URL of the image, which must be used as an absolute URL in OG tags and Article JSON-LD. (4) **Tenant and locale support** — Webiny supports multi-tenancy and content localisation, with locale-specific content entries — relevant for international SEO with hreflang implementation in the frontend. (5) **Page Builder** — Webiny includes a separate Page Builder module for visual page editing, distinct from the Headless CMS. Page Builder pages have their own SEO settings in the page settings panel, including title, description, and social image. (6) **Self-hosted on AWS** — because Webiny is self-hosted, the frontend performance characteristics (TTFB, CDN configuration, Lambda cold starts) are determined by the deployment configuration rather than a hosted platform.

How do I implement generateMetadata() with Webiny in Next.js?

In a Next.js App Router application consuming the Webiny Headless CMS GraphQL API, `generateMetadata()` queries the read API to fetch a content entry\'s SEO fields. The pattern: (1) **Configure the Webiny API client** — the Webiny read API endpoint is at `https://[webiny-api-gateway]/cms/read/[tenant]/[locale]`. Set the `x-tenant` and `x-webiny-cms-locale` headers and the Webiny Read API token (`process.env.WEBINY_API_TOKEN`) for authentication. (2) **Define a GraphQL query** — write a query that fetches the entry by its slug or ID along with all SEO fields: `query GetPage($slug: String!) { getPage(where: { slug: $slug }) { data { title seoTitle seoDescription canonicalUrl ogImage { url } noIndex } } }`. (3) **Map to Next.js metadata** — in `generateMetadata()`, call the Webiny GraphQL API with `fetch()` (or your preferred GraphQL client), then map the response: `entry.seoTitle || entry.title` → `metadata.title`, `entry.seoDescription` → `metadata.description`, `entry.canonicalUrl || \`/blog/${slug}\`` → `metadata.alternates.canonical`, `entry.ogImage?.url` → `metadata.openGraph.images` (the File Manager URL is already absolute — no prepending needed), `entry.noIndex` → `metadata.robots`. (4) **generateStaticParams()** — query the Webiny read API for all published entries using a list query (`listPages(limit: 1000, sort: createdOn_DESC)`) to fetch slugs for static generation. For large content sets, Webiny\'s GraphQL API supports `after` cursor-based pagination for fetching beyond the limit. (5) **Authentication** — the read API requires the Webiny Read API token in the `Authorization: Bearer [token]` header or as an API key header — do not expose this in client-side code; always fetch from Server Components or `generateMetadata()` on the server.

How does Webiny\'s serverless architecture affect SEO and Core Web Vitals?

Webiny is serverless on AWS Lambda — the Headless CMS GraphQL API runs as Lambda functions with DynamoDB for content storage. This affects SEO in specific ways: (1) **Lambda cold starts and TTFB** — AWS Lambda functions experience "cold starts" when they haven\'t been invoked recently (typically 100ms–3 seconds depending on runtime and package size). If the Next.js frontend uses SSR (Server-Side Rendering) with Webiny GraphQL API calls on each request, and the Lambda function cold-starts on the first request after an idle period, the server response time (TTFB) can spike significantly. Mitigation: use Next.js ISR (Incremental Static Regeneration) or full static generation (`generateStaticParams()`) to pre-render pages to static HTML, eliminating the Lambda call from the critical TTFB path for users. Revalidate via Webiny webhooks: configure a Webiny Lifecycle Event hook (on content entry publish/update) to trigger a Next.js On-Demand Revalidation endpoint (`/api/revalidate?slug=[slug]&secret=[token]`). (2) **DynamoDB read latency** — DynamoDB reads are fast (1–5ms for consistent reads) but add to Lambda execution time. For high-traffic content, Webiny API Gateway responses can be cached at CloudFront to avoid Lambda invocations entirely. (3) **File Manager CDN** — Webiny\'s File Manager stores files on S3 and serves them via CloudFront CDN. OG images and featured images from File Manager are served from CloudFront edge nodes — good TTFB for image delivery. In Next.js, configure the CloudFront domain in `images.remotePatterns` for Next.js Image optimisation. (4) **Real CrUX field data** — the DeepSEOAnalysis audit uses actual Chrome User Experience Report data for LCP, INP, and CLS — capturing real-world performance including Lambda cold start latency that synthetic Lighthouse tests might not replicate.

Is the Webiny SEO audit free?

Yes. The complete audit is free with no signup and no email gate. Enter the URL of your frontend application consuming the Webiny Headless CMS GraphQL API — the audit crawls the rendered HTML as Googlebot would. No Webiny API token, AWS credentials, or admin access needed. Works with any frontend framework consuming Webiny: Next.js, Nuxt, SvelteKit, Gatsby, Astro, or custom React applications. Paid DeepSEOAnalysis plans add saved report history, scheduled monitoring for larger crawls, and white-label agency reporting.