AEM SEO Technical search engine optimization in Adobe Experience Manager: URLs, canonicals, redirects, sitemaps and index control
In Adobe Experience Manager, technical SEO errors rarely originate in the authoring interface, but in the configuration in between: resource resolver, Externalizer, Dispatcher and CDN. This page maps each SEO task to the layer where AEM solves it.
AEM SEO per layer: most tasks live on publish, in the Dispatcher and in the CDN
| Task | Layer | Typical error |
|---|---|---|
| Short URLs | Resource resolver on publish | components output unmapped paths with /content |
| Canonical | Page component and Externalizer | wrong domain or http instead of https |
| Redirects | Dispatcher or CDN | chains across several layers |
| Sitemap | Apache Sling Sitemap on publish | unmapped URLs or the author domain |
| Index block | Dispatcher or CDN via header | preview and test environments in the index |
| Status codes | Publish and Dispatcher | error page served with status 200 |
Clean URLs in AEM: resource resolver mapping shortens /content/<site> and must apply in components
Without mapping, AEM serves pages under their repository path, such as /content/brand/en/products.html. In its SEO and URL Management Best Practices, Adobe recommends shortening the prefix with the OSGi property resource.resolver.mapping of the Resource Resolver Factory rather than with /etc/map, because the latter has more limited regular expression support and can cause problems with Dispatcher cache invalidation.
- Output: The mapping only takes effect when components build links through the resource resolver's
mapfunction. Custom components that concatenate paths keep emitting long URLs. - Selectors instead of parameters: Where no directory structure fits, Adobe recommends Sling selectors over query strings, because the Dispatcher can cache selector URLs.
- Translated segments: With
sling:alias, a page gets a language-specific name without changing the repository structure. - The .html extension: Classic AEM projects usually keep it, because Dispatcher cache and invalidation rely on files with an extension. Removing it requires rewrite rules and a mapping that match each other and are tested together.
Canonicals and vanity URLs: the Externalizer and page properties determine the canonical URL
The page properties allow authors to overwrite a page's canonical URL; if the field stays empty, the page's own URL is canonical. In article KA-34775, Adobe traces wrong domains, wrong protocols or relative URLs in canonicals and sitemaps to four causes: a missing Externalizer domain, a missing X-Forwarded-Proto header, unsuitable clientheaders rules in the Dispatcher, or a second canonical from custom template logic.
Vanity URLs are short additional addresses, for campaigns for instance. Without a redirect, the same page is reachable under two URLs; a redirect to the canonical URL is the clearer solution for search.
Redirects in AEM: rewrite maps in the Dispatcher and rules in the CDN instead of redirect pages
For redirects maintained by editors or the SEO team, Adobe describes pipeline-free URL redirects: the Dispatcher loads Apache rewrite maps from the publish repository, configured once in a managed-rewrite-maps.yaml file. The maps can be maintained with the Redirect Map Manager or the Redirect Manager from ACS AEM Commons, a community open source project not supported by Adobe. In AEM as a Cloud Service, static rules can also run in the CDN, through the CDN configuration and the config pipeline.
For load time, the number of hops counts: every redirect costs a round trip before Time to First Byte. Chains of CDN rule, Dispatcher rewrite and redirect page show up in a crawl, not in the authoring interface.
Sitemaps in AEM as a Cloud Service: generate them with Apache Sling Sitemap on publish
AEM generates sitemaps with the Apache Sling Sitemap module. A page marked as sitemap root in its page properties receives a sitemap.xml and, where needed, sitemap-index.xml. According to Adobe, the default generator only outputs canonical URLs and existing language alternates. Background generation is controlled by an OSGi configuration for org.apache.sling.sitemap.impl.SitemapScheduler, and the Dispatcher needs a filter rule for the sitemap files (Adobe sitemaps tutorial).
Sitemaps should be generated on publish, because the mapping rules that produce correct canonical URLs usually exist only there. For AEM as a Cloud Service, Adobe names the built-in generator with sling:sitemapRoot as the way to handle multilingual and MSM structures; the sitemap generator from ACS AEM Commons is not supported there.
Multilingual sites: language copies, MSM live copies and hreflang from the same structure
AEM offers two routes to language and market versions: language copies, which the translation framework uses by default, and live copies from the Multi Site Manager. Adobe recommends limiting MSM to content within one language (MSM and Translation). For SEO, this produces a frequent case: German-language live copies for Germany, Austria and Switzerland with almost identical content. They need hreflang annotations with a region and a self-referencing canonical per version; a canonical pointing to the master language invalidates the hreflang annotations.
hreflang in the sitemap and in the page head must show the same mapping. Both derive from the language structure below the language roots, whose names follow ISO codes such as de or de_CH.
Index control: block preview and test environments via header, serve robots.txt from the DAM
The preview tier of AEM as a Cloud Service is used for quality assurance before publishing (architecture). To keep it and development environments out of the index, Adobe recommends combining robots.txt with the X-Robots-Tag header, set in the Dispatcher or the CDN (KA-36839). Many projects keep the production robots.txt in the DAM and serve it under /robots.txt with a rewrite rule; the DAM path must be allowed in the Dispatcher filters. With Edge Delivery Services, URLs on aem.page and aem.live always serve a robots.txt that disallows all crawlers (aem.live).
A disallow prevents crawling, not indexing. For pages that should drop out of the index, noindex with crawling allowed is the right route.
Structured data in AEM: server-side JSON-LD from page properties and content fragments
Since version 2.31.0 of the Core Components, the page component supports structured data as JSON-LD in the page head, rendered on the server. With release 2026.6.0 of AEM as a Cloud Service, authors can add their own JSON-LD blocks in the page properties. For recurring types such as organization, person or FAQ, a component that renders the markup from content fragments keeps the data in one place. In a practitioner guide, Adobe recommends server-side rendering, because JSON-LD injected by JavaScript remains invisible to AI crawlers.
Dispatcher cache and SEO: status codes, query parameters and Core Web Vitals
The Dispatcher caches responses with status 200 but not error responses such as 404 (KA-17497). Serving error pages with status 200 to get them cached produces soft 404s at scale; a real 404 with a custom error page is correct.
The Dispatcher only caches requests with query parameters if those parameters are configured as ignored. For ignoreUrlParams, Adobe recommends an allowlist approach: ignore all parameters except those that change the content (Dispatcher caching). For search, the same list is the basis for canonicals on parameter URLs. Details are in AEM Dispatcher Cache.
The Core Web Vitals are among the signals Google groups under page experience, and they carry less weight than relevance and content. How releases are signed off against field data is described in AEM DevOps.
In the AEM Core Web Vitals Benchmark 2026, 49.4 percent of AEM websites in the DACH region pass the thresholds on mobile devices.
Book a free performance analysis
30 minutes via video call. You see your platform's Google user data and whether response time, redirects or the frontend determine the values.
Frequently asked questions about AEM SEO
Why do URLs with /content appear in the AEM source code?
Because components do not build links through the resource resolver's map function, or the mapping is only configured on some environments. The mapping belongs on all publish instances, and custom components must use it for every link they output. A crawl for URLs containing /content reveals the affected components.
Where should AEM generate the sitemap?
On publish. As a rule, only there do the mapping rules exist that produce correct canonical URLs. AEM as a Cloud Service provides the built-in generator based on Apache Sling Sitemap for this, controlled by marking a page as sitemap root and a schedule in the OSGi configuration.
How are redirects maintained in AEM as a Cloud Service without a deployment?
Through rewrite maps that the Dispatcher loads from the publish repository. Adobe calls this pipeline-free URL redirects; the maps can be maintained with the Redirect Map Manager from ACS AEM Commons, for example. Static rules can also run in the CDN.
Does the Dispatcher cache affect search engine optimization?
Yes, in two ways. It determines response time and therefore part of Largest Contentful Paint, and its rules for query parameters and status codes decide on duplicate URLs and soft 404s. Both belong in the same review.