Headless CMS SEO

TL;DR — A headless CMSA headless CMS decouples content storage and editing (the backend) from how that content is rendered and delivered (the frontend), serving content over an API instead of a built-in templated 'head'. Its SEO outcomes come almost entirely from how the separate frontend renders pages. separates where you write content from where it gets displayed — it doesn’t specify how that content gets rendered, hosted, cached, or previewed. For SEO, the biggest single lever is how your website renders that content — built at deploy time (SSG), on the server for each request (SSR), or in the visitor’s browser (CSR). SSG and SSR deliver complete HTML; CSR needs the rendered output verified, not assumed.

What headless means for SEO

Traditional CMSA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms. platforms (WordPress, Drupal) tightly couple content management and presentation. The CMS renders the HTML page that search engines see. In a headless setup, the CMS is just a content store accessible via an API. A separate frontend (usually a JavaScript framework like Next.js or Nuxt) fetches content from that API and renders it. Evidence for this claim A headless CMS decouples the content repository from the frontend presentation layer and delivers content through APIs. Scope: Contentful as a representative headless CMS architecture. Confidence: high · Verified: 2026-07-14 Contentful: What is a headless CMS? “Headless” only describes that separation — it doesn’t say which frontend framework, renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. mode, host, cache, preview security, or publishing workflow you’re using. Each of those is a separate decision, made by you, that actually affects SEO.

This means the CMS platform itself — Contentful, Strapi, Sanity, Storyblok, or Ghost — doesn’t directly render the page search engines see, but it still shapes the implementation: how you model content, what your API exposes, how preview and publishing work, and who owns fixing a page when something breaks. What determines the SEO outcome is what your frontend does with the content it receives.

The one thing that determines SEO outcomes

How your frontend renders pages.

SSG, SSR, and CSR are delivery architectures, not ranking factors — Google evaluates the initial HTML, the rendered HTML, crawl permissions, HTTP status, resource access, links, and metadata it actually gets from a page, not the name of the framework that produced it. Any of the three can succeed or fail depending on the implementation:

• SSG (static site generation) — pages are built at deploy time as static HTML. Search engines get fully-formed HTML with no JavaScript required, which removes a renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. step but doesn’t guarantee the HTML is complete or fresh.
• SSR (server-side rendering) — pages are rendered on the server at request time. Search engines also get complete HTML on the first request; the same caveat about completeness and freshness applies.
• CSR (client-side rendering) — the browser fetches the API and builds the page with JavaScript. Google can render JavaScriptMaking sure search engines can crawl, render, and index content that depends on JavaScript., but the content depends on a separate rendering stage and successful resource loading. Verify the rendered output rather than assuming it is visible. Evidence for this claim Google renders JavaScript pages in a separate processing stage, and JavaScript or resource failures can affect rendered output. Scope: Google Search; no guarantee of indexing. Confidence: high · Verified: 2026-07-14 Google: JavaScript SEO basics

In practice, SSG and SSR remove one failure mode (a crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. skipping or delaying the render step) so they’re the safer default — but test the actual delivered output for all three rather than treating the label as a guarantee.

What you have to build yourself

In a WordPress setup, plugins handle metadata, sitemapsA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing., canonicals, and structured data. In a headless setup, you build all of that:

• Title and meta descriptionThe meta description is an HTML head tag — `<meta name=\"description\" content=\"…\">` — that suggests a short summary of the page for the search snippet. It's not a Google ranking factor, and Google rewrites it the majority of the time, but a good one can still lift click-through. — set in your framework’s <head> component
• Canonical tagsA rel=\"canonical\" annotation — in the HTML <head> or an HTTP Link header — that tells search engines which URL is the preferred version of duplicate or near-duplicate content. — configured in your layout or per-page
• XML sitemapAn XML sitemap is a UTF-8 file listing the canonical URLs on your site (with optional lastmod) so search engines can discover and prioritize them. It's a discovery and diagnostic aid, not a guarantee of indexing — and Google ignores its priority and changefreq tags. — generated by a package (next-sitemap, Nuxt’s sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing. module) or custom code
• Structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding. — JSON-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal. injected via your <head> or <script> components
• robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere. — a static file in your public directory

TL;DR — Headless CMSA headless CMS decouples content storage and editing (the backend) from how that content is rendered and delivered (the frontend), serving content over an API instead of a built-in templated 'head'. Its SEO outcomes come almost entirely from how the separate frontend renders pages. SEO is mostly frontend architecture, and no headless setup has an inherent ranking advantage over a coupled CMSA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms. — the CMS still shapes the implementation. The CMS-specific considerations are: preview access control (authentication first, noindexNoindex is a directive that tells search engines to keep a page out of their index, so it won't appear in search results. It works only on pages a crawler can actually fetch — a page blocked in robots.txt can never be noindexed. second — noindexNoindex is a directive that tells search engines to keep a page out of their index, so it won't appear in search results. It works only on pages a crawler can actually fetch — a page blocked in robots.txt can never be noindexed. is not access control), API-driven metadata fields (the CMS must expose title/description fields per entry), the publish-to-live pipeline (a delivered webhook proves automation fired, not that a fresh page is live), and AI crawlerAI crawlers are bots from AI companies that fetch web pages to train language models, build AI-search indexes, or answer live user questions. They come in three categories, each with its own user-agent tokens and its own robots.txt controls. access (many headless APIs are blocked by default).

CMS-level SEO considerations

The headless CMSA content management system that separates the content repository from the presentation layer, delivering content via API to any front-end framework rather than rendering HTML server-side itself. It doesn't specify the rendering mode, hosting, cache, preview security, or publishing workflow — those are separate decisions. itself doesn’t render the public page, but it still contributes to SEO in these ways:

Metadata fields — Your CMS schema must include SEO metadata fields per content type: title, meta descriptionThe meta description is an HTML head tag — `<meta name=\"description\" content=\"…\">` — that suggests a short summary of the page for the search snippet. It's not a Google ranking factor, and Google rewrites it the majority of the time, but a good one can still lift click-through., Open GraphOpen Graph (OG) tags are `<meta>` elements in a page's head, defined by the Open Graph protocol (ogp.me, created by Facebook), that describe a page as a shareable object — its title, description, image, URL, and type. They control how a link preview card looks when the page is shared on Facebook, LinkedIn, Slack, Discord, WhatsApp, and iMessage. They are not a direct Google ranking factor, though Google reads og:title, og:image, and og:site_name as inputs to how a result appears. image, canonical URLHow search engines pick one canonical URL among duplicates and consolidate signals onto it. override. These need to be exposed in the API response so your frontend can consume them.

Preview URLs — Headless CMSes generate preview content through a separate API, host, or tokenA token is the smallest unit of text (or image/audio/video) an LLM processes — roughly 4 characters, or about ¾ of an English word. A context window is the maximum number of tokens (input plus output) a model can hold at once, like its short-term memory. so editors can see drafts before publishing — the preview API is a distinct, sensitive delivery path, not a variant of the public one. Evidence for this claim Google supports noindex in a robots meta tag or X-Robots-Tag response header, while robots.txt blocking can prevent Google from seeing that directive. Scope: Google Search indexing controls. Confidence: high · Verified: 2026-07-14 Google: Block indexing with noindex Treat access control as the primary defense: keep preview tokens and hosts authenticated, and don’t let a shared or guessable preview link stand in for a login. Noindex (in HTML or an X-Robots-Tag header) is a second, complementary layer for the case where a preview page is reachable — it stops indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed., it doesn’t stop access, and a robots.txt disallow can actually keep crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. from ever seeing the noindex tag. A common mistake is treating noindex alone as enough and letting preview URLs stay reachable without authentication.

Webhook-triggered builds — In SSG setups, published content doesn’t go live until a new build runs. Configure your CMS to trigger a build webhook on publish, but don’t treat webhook delivery as proof of a completed rebuild — a delivered callback confirms the automation fired; it doesn’t confirm the build succeeded, the deploy promoted, or any downstream cache was invalidated. Evidence for this claim A statically generated deployment must be rebuilt to include source-content changes in its generated output. Scope: Astro static output as a representative SSG; deployment automation varies. Confidence: high · Verified: 2026-07-14 Astro: Build your site Verify the public page directly (a fresh fetch or your monitoring) after a publish, and know who owns re-running or rolling back a failed build. Otherwise, the generated site will not contain the change until the next build.

ISR (incremental static regeneration) pitfalls — If using ISR with Next.js or similar, stale cached pages may be served to crawlers for as long as your revalidation interval allows. Set short revalidation windows for content that changes frequently, and prefer on-demand revalidation triggered by the same publish webhook over relying on a fixed interval alone.

AI crawler access — Many headless CMS API endpoints are protected by API keys. Your public-facing frontend pages should be accessible, but verify that AI crawler user agentsA user agent is the HTTP request header a client (browser, crawler, or bot) sends to identify itself. For crawlers, a short user-agent token — a substring of that string — is what robots.txt rules actually target. (GPTBot, ClaudeBot, etc.) aren’t being blocked by your CDN or edge config.

No inherent ranking advantage — A headless CMS doesn’t outrank a coupled one by architecture alone. Decoupling changes who controls what (content modeling, API shape, renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM., hosting), adds dependencies (API, build, cache, preview), and adds testing and ownership burden — none of that is a ranking factor by itself. Search evaluates the public pages your setup actually produces, not the CMS label behind them; compare platforms on delivery reliability, latency, cost, and who owns each failure mode, not on which one is “better for SEO.”

TIP Audit the integrated frontend, not the CMS API

A healthy API says nothing about the HTML crawlers receive. Compare the initial document with a browser render to find content, links, and metadata that the frontend leaves JavaScript-dependent.

Test representative routes with my free Render Gap Analyzer Free

1. Choose one public route for each content type and rendering mode.
2. Treat the comparison as delivery evidence, not a Google index verdict.
3. Move critical output into SSG or SSR, retest, and confirm the final Google view in URL Inspection.

Tap to enlarge

The initial HTML contains about eight words while the rendered page contains about 112. Most content is added by JavaScript.

Platform comparison

“Headless” only means the CMSA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms. (Contentful, Strapi, Sanity, Storyblok, Ghost) separates content management from presentation — it doesn’t specify the frontend framework, renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. mode, hosting, cache, preview security, or publishing workflow. The CMS still shapes the implementation (content modeling, API shape, preview, publishing, ownership), but the biggest single lever for what search engines see is the frontend renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. architecture. No headless setup has an inherent ranking advantage over a coupled CMS by architecture alone.

The rendering decision: SSG (pages built at deploy time as static HTML) and SSR (pages rendered server-side per request) both deliver complete HTML and are the safer default. CSR (pages built entirely in the browser with JavaScript) depends on a separate rendering stage — Google can process it, but verify the rendered output rather than assume it. SSG, SSR, and CSR are delivery architectures, not ranking factors; each can succeed or fail depending on the implementation.

What you must build explicitly in a headless setup (vs. what WordPress plugins handle automatically):

• Metadata (title, description, Open GraphOpen Graph (OG) tags are `<meta>` elements in a page's head, defined by the Open Graph protocol (ogp.me, created by Facebook), that describe a page as a shareable object — its title, description, image, URL, and type. They control how a link preview card looks when the page is shared on Facebook, LinkedIn, Slack, Discord, WhatsApp, and iMessage. They are not a direct Google ranking factor, though Google reads og:title, og:image, and og:site_name as inputs to how a result appears.) per page
• Canonical tagsA rel=\"canonical\" annotation — in the HTML <head> or an HTTP Link header — that tells search engines which URL is the preferred version of duplicate or near-duplicate content.
• XML sitemapAn XML sitemap is a UTF-8 file listing the canonical URLs on your site (with optional lastmod) so search engines can discover and prioritize them. It's a discovery and diagnostic aid, not a guarantee of indexing — and Google ignores its priority and changefreq tags.
• Structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding. (JSON-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal.)
• robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere.

CMS-specific SEO considerations:

• Contentful: expose SEO fields in content model; the Preview API serves drafts through a separate host and tokenA token is the smallest unit of text (or image/audio/video) an LLM processes — roughly 4 characters, or about ¾ of an English word. A context window is the maximum number of tokens (input plus output) a model can hold at once, like its short-term memory. — require authentication first, use noindexNoindex is a directive that tells search engines to keep a page out of their index, so it won't appear in search results. It works only on pages a crawler can actually fetch — a page blocked in robots.txt can never be noindexed. as a second layer
• Strapi: install the SEO plugin; configure webhook to trigger builds on publish, then verify the public page rather than trusting webhook delivery alone
• Sanity: define SEO fields in schema; use GROQ to query metadata; webhook rebuild on publish, verified against the live page
• Storyblok: built-in SEO plugin with meta title/description per story; preview token controls draft access
• Ghost: built-in SEO fields (meta title, description, OG image); the frontend rendering mode (headless via API vs. Ghost’s own Handlebars renderer) determines crawlabilityCrawlability is how well search engine crawlers can discover, access, and fetch a site's pages. A crawlability issue is any technical condition — blocked access, broken links, server failures, or bloated URL inventory — that stops pages from reaching the index.

A delivered webhook confirms the automation fired, not that a fresh build succeeded, deployed, or invalidated the cache — verify the live public page after publishing rather than treating webhook delivery as proof.

Headless CMS SEO setup checklist

CMS configuration

• Add SEO fields to every content type: title, meta descriptionThe meta description is an HTML head tag — `<meta name=\"description\" content=\"…\">` — that suggests a short summary of the page for the search snippet. It's not a Google ranking factor, and Google rewrites it the majority of the time, but a good one can still lift click-through., OG image, canonical URLHow search engines pick one canonical URL among duplicates and consolidate signals onto it. override
• Configure preview URL authentication or noindexNoindex is a directive that tells search engines to keep a page out of their index, so it won't appear in search results. It works only on pages a crawler can actually fetch — a page blocked in robots.txt can never be noindexed. headers
• Set up build webhook triggered on content publish/unpublish
• Document which environments are staging vs. production (to verify noindexNoindex is a directive that tells search engines to keep a page out of their index, so it won't appear in search results. It works only on pages a crawler can actually fetch — a page blocked in robots.txt can never be noindexed. on staging)

Frontend (applies to all headless setups)

• Render pages as SSG or SSR — verify with a curl or view-source check
• Set <title> and <meta name="description"> dynamically from CMSA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms. fields
• Add canonical tagA rel=\"canonical\" annotation — in the HTML <head> or an HTTP Link header — that tells search engines which URL is the preferred version of duplicate or near-duplicate content. (<link rel="canonical">) to every page
• Generate XML sitemapAn XML sitemap is a UTF-8 file listing the canonical URLs on your site (with optional lastmod) so search engines can discover and prioritize them. It's a discovery and diagnostic aid, not a guarantee of indexing — and Google ignores its priority and changefreq tags. (next-sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing., @nuxtjs/sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing., or custom)
• Add robots.txt to public directory, blocking staging/preview paths
• Inject structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding. (JSON-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal.) via <script type="application/ld+json">
• Test renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM.: verify Google can see your content with Rich ResultsRich results (formerly 'rich snippets') are enhanced search listings — stars, images, prices, breadcrumbs, video thumbnails, and more — that Google and Bing build from structured data. They're a display feature, not a ranking factor, and eligibility never guarantees they'll show. Test or URL Inspection

ISR-specific

• Set short revalidate intervals for frequently-updated content (news, pricing)
• Trigger on-demand revalidation via webhook on CMS publish events
• Monitor for stale-content issues in Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. (content live on site but not indexed)

Tools for testing a headless stack

• Render Gap Analyzer — compare server-delivered HTML with the rendered page and catch content or links that exist only after client execution.
• Staging vs. Production SEO Diff — compare directives, canonicals, metadata, and structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding. before a frontend release.
• Schema Validator — validate JSON-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal. assembled by the frontend from CMSA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms. fields.
• Sitemap Validator — verify that frontend routes and CMS publication state produce the intended sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing..
• Scout Site Audit Free — sample the integrated system; a CMS API audit alone cannot show what crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. receive from the frontend.

Platform deep dives

• Contentful SEOContentful SEO is the practice of making content delivered through the Contentful headless CMS crawlable, indexable, and rankable. Because Contentful serves content over APIs and renders no HTML itself, every SEO outcome is decided by the frontend that consumes it.
• Strapi SEOStrapi SEO is the practice of making content stored in Strapi — an open-source headless CMS — discoverable and rankable. Because Strapi has no built-in frontend, every SEO outcome is decided by the frontend framework that renders its API, not by Strapi itself.
• Sanity SEOSanity SEO is the set of technical and content practices that make a website built on Sanity.io rank and get cited. Sanity stores content as structured JSON and produces zero HTML, so every SEO output — meta tags, sitemaps, canonicals, structured data — is built in the frontend that consumes Sanity's API.
• Storyblok SEOStoryblok SEO is the practice of making sites built on Storyblok — a visual, API-first headless CMS — discoverable in search and AI answers. Because Storyblok only stores content and the frontend framework renders it, SEO outcomes are decided almost entirely by how that frontend is built.
• Ghost SEOGhost SEO is the practice of optimizing a site built on Ghost CMS. The work splits in two: in traditional (Handlebars) mode Ghost handles core technical SEO automatically; run headless and you must rebuild all of it in the frontend.

Related reading

• Headless CMS SEO overviewA headless CMS decouples content storage and editing (the backend) from how that content is rendered and delivered (the frontend), serving content over an API instead of a built-in templated 'head'. Its SEO outcomes come almost entirely from how the separate frontend renders pages.
• JavaScript SEOMaking sure search engines can crawl, render, and index content that depends on JavaScript.
• Next.js SEONext.js SEO is the set of practices and built-in features that make a Next.js site crawlable, indexable, and rankable — rendering mode (SSG/SSR/ISR/Server Components), the App Router Metadata API, sitemap.ts/robots.ts conventions, next/image, and next/link.

Test yourself: headless CMS SEO

Five questions on what actually drives SEO outcomes in a headless setup. Pick an answer for each, then check.

Headless CMS

A content management system that separates the content repository from the presentation layer, delivering content via API to any front-end framework rather than rendering HTML server-side itself. It doesn't specify the rendering mode, hosting, cache, preview security, or publishing workflow — those are separate decisions.

Related: JavaScript SEO, Crawling

Headless CMS

A headless CMSA headless CMS decouples content storage and editing (the backend) from how that content is rendered and delivered (the frontend), serving content over an API instead of a built-in templated 'head'. Its SEO outcomes come almost entirely from how the separate frontend renders pages. decouples where content is stored and managed from how it is rendered and delivered. Traditional CMSsA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms. couple these together — content lives in a database and the CMS renders the HTML. A headless CMS exposes content through APIs (REST or GraphQL), and a separate front-end layer handles what visitors see. “Headless” only describes that separation; it says nothing about which frontend framework, renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. mode, host, cache, preview security, or publishing workflow is used.

From an SEO perspective, the headless CMS doesn’t render the public page, but it still shapes the implementation — content modeling, API behavior, preview access, and publishing workflow. No headless CMS has an inherent ranking advantage over a coupled one by architecture alone. The biggest single lever is the renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. model: server-side rendering (SSR) and static generation (SSG) produce complete HTML on delivery; client-side rendering (CSR) depends on a separate rendering stage, and GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer.’s ability to execute that JavaScript should be verified rather than assumed. The choice of headless CMS (Contentful, Strapi, Sanity, Storyblok, Ghost) doesn’t by itself determine SEO outcomes — the rendering architecture and the CMS’s own implementation choices do.

Related: JavaScript SEO, Crawling

Changelog