How does Adobe Experience Manager handle SEO metadata?

AEM does not have a built-in SEO component — SEO metadata is implemented via custom or third-party components. Common patterns: (1) Custom AEM Page Properties — the SEEM component or custom Dialog fields on jcr:content nodes for page title (jcr:title), meta description (custom property), OG image (fileReference), and noindex (custom Boolean property). The Sling rendering layer (HTL/Sightly or JSP) reads these properties and outputs meta tags. (2) ACS Commons — Adobe Consulting Services Commons provides a Meta Tags component and Sitemap Generator utility used widely across AEM implementations. (3) AEM Core Components (v2.0+) — include SEO-aware head rendering via the Page Core Component with configurable meta tags. The key SEO risk: AEM page properties are configured per page by authors in the Touch UI editor. Without enforced validation rules (mandatory field validation in Dialog) or author guidance, meta descriptions and SEO titles frequently go unpopulated on large page sets.

How is JSON-LD structured data implemented in AEM?

AEM does not generate JSON-LD structured data by default. Implementation approaches: (1) HTL (Sightly) template — add a block in the page head HTL template, binding schema values from jcr:content properties (jcr:title for headline, jcr:created/cq:lastModified for datePublished/dateModified, custom author reference for author Person schema). (2) Custom AEM component — an AEM component that renders structured data using a Sling Model that reads and serialises page metadata into JSON-LD. The Sling Model approach enables type-safe property binding and testability. (3) Content Fragments — for headless AEM setups with AEM Content Fragments and Edge Delivery Services or a decoupled frontend, JSON-LD is generated in the frontend layer from Content Fragment data exposed via the AEM Content Fragment API. All approaches must produce server-rendered JSON-LD in the initial HTML response — GTM-injected schema is not reliably parsed by Googlebot\'s first-pass HTML crawler.

How does AEM handle URL structure and canonical tags?

AEM URL routing is managed by Apache Sling\'s URL mapping and resource resolution, typically combined with Apache Dispatcher rewrite rules and URL mapping in /etc/map (or AEM Cloud Service CDN rewrite rules). Key SEO URL considerations: (1) Content paths (/content/site-name/language/page) are mapped to clean URLs (/en/page) via Dispatcher RewriteRules or /etc/map URL mapping — verify that canonical tags reference the mapped clean URLs, not the /content/ JCR paths. (2) Selectors and suffixes (e.g., /page.html, /page/jcr:content.infinity.json) — Dispatcher rules must block non-HTML selectors from being indexed (403 or robots.txt disallow). (3) Multi-site AEM implementations using MSM (Multi-Site Manager) require per-locale canonical tags and hreflang implementation. (4) AEM asset URLs (DAM assets at /content/dam/) should be disallowed in robots.txt if not intended for indexing — DAM URLs are often inadvertently crawled and indexed.

What Core Web Vitals challenges do AEM sites face?

AEM sites face specific Core Web Vitals challenges: (1) LCP from DAM-served images — AEM\'s Dynamic Media (Scene7) or core image component should use responsive image renditions with srcset and appropriate sizes, plus fetchpriority="high" on the above-fold hero image. Dynamic Media URL transformation parameters can serve WebP to supporting browsers. Without explicit rendition configuration, AEM may serve full-resolution originals as LCP images. (2) TTFB from AEM Dispatcher cache misses — Dispatcher is AEM\'s caching layer; a cache miss proxies the request to the AEM Publisher, which may take 300–1000ms to render. Ensure Dispatcher cache headers are configured correctly (Cache-Control, no-store exceptions for personalised content) and that statfiles are not invalidating the full cache on every publish. (3) INP from AEM ClientLibs — AEM\'s ClientLib system bundles JS; large ClientLib bundles blocking the main thread cause INP failures. (4) CLS from DAM images without explicit dimensions in the Image Core Component — add explicit width/height attributes.

Adobe Experience Manager SEO audit

Adobe Experience Manager (AEM) is an enterprise content management system combining a headless CMS, DAM (Digital Asset Management), and site-building capabilities. AEM SEO requires custom implementation at every layer: HTL/Sightly page components for meta tags, Sling URL mapping for canonical URLs, Dispatcher robots.txt configuration, and Sling Model-based JSON-LD structured data. DeepSEOAnalysis validates the rendered server-side output — not the JCR content model — checking exactly what Googlebot receives across all six SEO dimensions.

Run free AEM SEO audit →

What the audit checks on AEM sites

AEM SEO component output and meta tag rendering: AEM's SEO output depends entirely on the page component implementation — there is no default meta tag generation. The audit validates what is actually rendered in the server-side HTML: whether the title tag is populated from jcr:title or a custom SEO title field; whether meta description is populated (empty description is common on large AEM sites where authors don't complete Dialog SEO fields); whether canonical tags use clean mapped URLs (not /content/ JCR paths); whether OG title, OG description, and OG image are set; and whether noindex pages are excluded from the sitemap. AEM Page Properties configured via Touch UI Dialog are the primary source — verifying the rendered output catches cases where Dialog fields exist but the HTL template fails to output them (common after component refactoring or template migrations).
AEM Sling URL mapping and canonical slug structure: AEM's content lives at /content/[site]/[language]/[path] in the JCR, but external-facing URLs are cleaned up via Dispatcher rewrite rules or /etc/map URL mappings. SEO risks in this architecture: (1) Canonical tags must reference the clean external URL, not the /content/ internal path — a common misconfiguration in custom page components. (2) Dispatcher rules that serve the same content on multiple URLs (with and without .html extension, with different query parameters) without canonical consolidation create duplicate content. (3) AEM assets at /content/dam/ that are linked from indexed pages cause Googlebot to crawl and sometimes index DAM URLs — disallow /content/dam/ in robots.txt unless assets are intentionally indexable. (4) AEM Multi-Site Manager (MSM) live copies often inherit page templates across locales — verify that hreflang tags reference the correct locale URLs and that MSM live copy pages have distinct SEO fields from the blueprint source. (5) ACS Commons URL Externaliser configuration determines the domain used in sitemap and canonical URLs — verify the externaliser configuration for the environment.
JSON-LD from AEM page components and Content Fragments: AEM structured data implementation varies significantly between projects. The audit checks what is server-rendered in the initial HTML: (1) Article JSON-LD — headline bound from jcr:title (max 110 characters), datePublished from jcr:created or cq:lastModified, dateModified from cq:lastModified, author from a custom author reference component or Dialog field, image from a DAM asset path rendered as an absolute Dynamic Media or CDN URL. A common error: DAM asset paths rendered as /content/dam/... paths in JSON-LD rather than absolute external URLs. (2) FAQPage JSON-LD — generated from FAQ accordion components using a Sling Model that maps component children to question/answer pairs in FAQPage schema. (3) Organisation JSON-LD site-wide in the page head. (4) BreadcrumbList from the AEM page tree parent hierarchy. (5) All structured data must be server-rendered in the initial HTML — not injected via Adobe Launch (DTM) or GTM, which are client-side and not parsed by Googlebot's first-pass HTML crawler.
AEM sitemap configuration and robots.txt: AEM sitemap implementation options: (1) ACS Commons Sitemap Generator — the most common approach; configured via OSGi configuration, generates sitemap.xml from the JCR page tree with configurable exclusions (noindex pages, specific templates, page types). (2) AEM Sitemap feature (AEM 6.5.6+ / AEM Cloud Service) — built-in sitemap generation with configurable selectors and servlet-based generation. (3) Custom Sling servlet — generates sitemap.xml via a Java servlet, enabling full control over page inclusion, priority, and lastmod. Key validation points: the sitemap must use clean external URLs (not /content/ paths); noindex pages must be excluded; lastmod must use jcr:lastModified; Dispatcher caching of the sitemap (frequent updates require appropriate Dispatcher invalidation or short cache TTL); and the sitemap must be declared in robots.txt. Robots.txt on AEM is typically managed as a Dispatcher-served static file — verify it disallows /content/dam/, /libs/, /crx/, /mnt/, and non-HTML selectors.
Core Web Vitals for AEM sites: AEM sites have distinct Core Web Vitals patterns driven by their architecture: (1) LCP — AEM's Image Core Component with Dynamic Media should use srcset with responsive rendition sets and fetchpriority="high" on the hero image. Dynamic Media Adaptive Bitrate and WebP delivery require explicit configuration. Without it, AEM serves full-resolution DAM originals, causing LCP failures. CrUX field data from real users is the authoritative measurement — Lighthouse lab scores often look better because they don't capture Dispatcher cache miss TTFB. (2) CLS — AEM image components without explicit width/height attributes in HTL templates cause layout shift. AEM Core Components (Image v3+) include intrinsic width/height rendering; custom components may not. (3) INP — large AEM ClientLib JS bundles (particularly sites using legacy JSP components or heavy client-side personalisation) cause main thread blocking. AEM Cloud Service's CDN and preloading options help. (4) TTFB — Dispatcher cache miss performance is the key risk. Personalised content (logged-in user state, geolocation, A/B tests) frequently bypasses Dispatcher cache, causing per-request AEM Publisher rendering at 300–800ms TTFB.
AI visibility and GEO score for AEM sites: Five AI visibility checks on AEM sites: (1) AI crawler access — AEM Dispatcher robots.txt must explicitly allow GPTBot, ClaudeBot, PerplexityBot, Google-Extended, and CCBot. AEM security hardening often adds broad User-agent: * Disallow rules that inadvertently block AI crawlers. Dispatcher-level WAF rules (Fastly, Akamai, Cloudflare fronting AEM) can also block AI crawlers at the CDN layer without being visible in robots.txt. (2) llms.txt — implement as a static file served by Dispatcher or as a Sling servlet at /llms.txt selectively listing key content pages, their summaries, and content type. (3) FAQPage JSON-LD — generated from FAQ accordion components server-side via Sling Model, not via Adobe Launch injection. (4) Question-heading ratio — AEM Rich Text Editor (RTE) content contains heading markup; audit heading structure for ≥20% question-format headings across content pages. (5) Content chunkability — AEM parsys (paragraph system) and Core Component Page Sections provide natural content boundaries; ensure sections are delimited by heading components for AI retrieval.

How to audit your AEM site

Enter any URL from your AEM site — homepage, content page, product page, or category listing.
DeepSEOAnalysis crawls the live site through Dispatcher, validating structured data in server-rendered HTML (not JCR-level), checking Core Web Vitals from real CrUX field data, and scoring AI visibility across five GEO signals.
Review property-level structured data errors (exact missing fields with corrected markup), Core Web Vitals, Dispatcher robots.txt analysis, canonical URL correctness, and GEO score.
Share the audit URL with your AEM development team — no login required to view results.

Adobe Experience Manager SEO frequently asked questions

How does Adobe Experience Manager handle SEO metadata?: AEM does not have a built-in SEO component — SEO metadata is implemented via custom or third-party components. Common patterns: (1) Custom AEM Page Properties — the SEEM component or custom Dialog fields on jcr:content nodes for page title (jcr:title), meta description (custom property), OG image (fileReference), and noindex (custom Boolean property). The Sling rendering layer (HTL/Sightly or JSP) reads these properties and outputs meta tags. (2) ACS Commons — Adobe Consulting Services Commons provides a Meta Tags component and Sitemap Generator utility used widely across AEM implementations. (3) AEM Core Components (v2.0+) — include SEO-aware head rendering via the Page Core Component with configurable meta tags. The key SEO risk: AEM page properties are configured per page by authors in the Touch UI editor. Without enforced validation rules (mandatory field validation in Dialog) or author guidance, meta descriptions and SEO titles frequently go unpopulated on large page sets.
How is JSON-LD structured data implemented in AEM?: AEM does not generate JSON-LD structured data by default. Implementation approaches: (1) HTL (Sightly) template — add a <script type="application/ld+json"> block in the page head HTL template, binding schema values from jcr:content properties (jcr:title for headline, jcr:created/cq:lastModified for datePublished/dateModified, custom author reference for author Person schema). (2) Custom AEM component — an AEM component that renders structured data using a Sling Model that reads and serialises page metadata into JSON-LD. The Sling Model approach enables type-safe property binding and testability. (3) Content Fragments — for headless AEM setups with AEM Content Fragments and Edge Delivery Services or a decoupled frontend, JSON-LD is generated in the frontend layer from Content Fragment data exposed via the AEM Content Fragment API. All approaches must produce server-rendered JSON-LD in the initial HTML response — GTM-injected schema is not reliably parsed by Googlebot\'s first-pass HTML crawler.
How does AEM handle URL structure and canonical tags?: AEM URL routing is managed by Apache Sling\'s URL mapping and resource resolution, typically combined with Apache Dispatcher rewrite rules and URL mapping in /etc/map (or AEM Cloud Service CDN rewrite rules). Key SEO URL considerations: (1) Content paths (/content/site-name/language/page) are mapped to clean URLs (/en/page) via Dispatcher RewriteRules or /etc/map URL mapping — verify that canonical tags reference the mapped clean URLs, not the /content/ JCR paths. (2) Selectors and suffixes (e.g., /page.html, /page/jcr:content.infinity.json) — Dispatcher rules must block non-HTML selectors from being indexed (403 or robots.txt disallow). (3) Multi-site AEM implementations using MSM (Multi-Site Manager) require per-locale canonical tags and hreflang implementation. (4) AEM asset URLs (DAM assets at /content/dam/) should be disallowed in robots.txt if not intended for indexing — DAM URLs are often inadvertently crawled and indexed.
What Core Web Vitals challenges do AEM sites face?: AEM sites face specific Core Web Vitals challenges: (1) LCP from DAM-served images — AEM\'s Dynamic Media (Scene7) or core image component should use responsive image renditions with srcset and appropriate sizes, plus fetchpriority="high" on the above-fold hero image. Dynamic Media URL transformation parameters can serve WebP to supporting browsers. Without explicit rendition configuration, AEM may serve full-resolution originals as LCP images. (2) TTFB from AEM Dispatcher cache misses — Dispatcher is AEM\'s caching layer; a cache miss proxies the request to the AEM Publisher, which may take 300–1000ms to render. Ensure Dispatcher cache headers are configured correctly (Cache-Control, no-store exceptions for personalised content) and that statfiles are not invalidating the full cache on every publish. (3) INP from AEM ClientLibs — AEM\'s ClientLib system bundles JS; large ClientLib bundles blocking the main thread cause INP failures. (4) CLS from DAM images without explicit dimensions in the Image Core Component — add explicit width/height attributes.