SEO on Adobe Experience Manager Sites: What to Check

AEM SEO comes down to whether Adobe Experience Manager publishes clean, single, crawlable URLs with the right tags, sitemaps and redirects, and whether the Dispatcher cache keeps them that way. Most problems are not content problems: they sit in configuration that marketing teams cannot see from the authoring screen. This checklist turns each area into a question a marketing team can hand to its AEM developers, with what a good answer looks like.

How to use this AEM SEO checklist

Responsibility for search usually splits three ways: authors control titles, descriptions and page names; developers control templates, components and Sling configuration; and whoever runs hosting controls the Dispatcher and CDN rules. A finding is only useful if it reaches the person who can fix it.

For each item below, raise a ticket with three parts: the URL where the problem shows, what search engines currently see, and what they should see. Where an item depends on your AEM version, ask the team to check Adobe's documentation for that version.

URLs and the content path

Adobe's own guidance on SEO and URL management for AEM as a Cloud Service recommends short, readable URLs, hyphens between words, and subfolders such as a language folder rather than subdomains. It also recommends removing the internal repository path from public URLs.

Questions for your developers

• Do public URLs still contain the internal content path? If live links include the repository structure rather than a short path such as a language folder, ask how resource resolver mappings and the web server rewrite rules are set up, and whether components generate links through the mapping so every internal link uses the short form.
• Does an uppercase version of a URL return a page? Adobe suggests a rewrite rule that sends uppercase requests to the lowercase URL with a permanent redirect, plus training authors to name pages in lowercase.
• Are query strings used where selectors would do? Adobe notes that selector based URLs can be cached by the Dispatcher, while query string URLs generally cannot.

AEM canonical tags and duplicate pages

AEM can serve the same content at several addresses: with and without selectors, through vanity URLs, through aliases and through campaign parameters. Adobe recommends a canonical link on pages reachable through several paths, and specifically on pages with vanity URLs, because extra addresses split the value of a page.

What to check

1. Open five page types (home, a section landing page, a detail page, a filtered listing and a campaign page) and view the source. Each should have exactly one canonical tag pointing to the preferred, absolute URL.
2. Check that the canonical uses the public domain and short path, not an author or publish host name or the long content path.
3. Check that language versions point to themselves, not all to the English page.
4. Check the live page, not a preview, so the Dispatcher and CDN are included.

If your site runs in English and Arabic, ask whether hreflang annotations are output alongside the canonical, and whether each language version lists every other version. Our guide on schema, sitemaps and canonicals on headless builds covers the same principles for decoupled front ends, which matters if your AEM content is delivered headless.

AEM sitemap generation

Adobe recommends generating the XML sitemap programmatically so it changes with the content. On AEM as a Cloud Service, Adobe's documentation describes the Apache Sling Sitemap approach: a page is marked as a sitemap root in its properties, and a scheduler regenerates the files on the publish tier, where public URLs resolve correctly.

Questions for your developers

• Is a sitemap root set for each site and language, and is the sitemap index listed in robots.txt?
• How often does the scheduler run, and does a newly published page appear after the next run?
• Do sitemap URLs match the canonical URLs exactly, including protocol, host, short path and extension?
• Are pages that should not be indexed (thank you pages, internal search results, test pages) excluded?

Submit the sitemap index in Google Search Console and compare submitted pages with indexed pages. A large gap is a prompt to investigate.

The AEM Dispatcher, caching and robots.txt

The AEM Dispatcher is the caching and filtering layer in front of the publish tier.

Stale pages after publishing

Adobe notes that short URLs created by mappings can leave stale cache entries after a page is activated, and suggests expanding short URLs with rewrite rules before the request reaches the Dispatcher so cache flushes work. If updated titles take a long time to appear live, ask the team to test an activation and flush on one page.

Exposed paths

Adobe cautions that Dispatcher filters should expose only the paths the site needs. Ask whether internal paths, author style URLs or JSON renditions of pages can be reached and crawled from the public domain.

robots.txt

Adobe advises blocking all crawling on test environments, blocking only unwanted paths on live sites, and managing the robots.txt file so a cache flush does not remove it. Check that staging hosts are not indexed; a staging copy in Google is a common source of duplicates.

Redirects, migrations and vanity URLs

When a site moves to AEM or restructures inside it, Adobe recommends permanent redirects from legacy URLs and testing them. Ask where redirects live (Dispatcher rewrite rules, the CDN or an authoring based tool), who can add one, and how long a new rule takes to reach production. Then test a sample of old URLs and confirm each returns one permanent redirect straight to the final page, not a chain.

Each vanity URL should either redirect or carry a canonical to the main page.

Hypothetical example: a property developer relaunches on AEM and moves project pages under a new section. The old URLs return the new homepage rather than the matching project page. The project pages lose links they had earned. A one to one redirect map, agreed before launch and tested after it, prevents this.

Templates, components and page speed

One template fix often corrects hundreds of pages.

• Titles and descriptions: Do page properties map to the title tag and meta description, and is there a sensible fallback when authors leave them empty?
• Headings: Does each template output one H1, and do components use heading levels in order?
• Images: Do image components require alt text, serve modern formats and sizes suited to the device, and lazy load below the fold?
• Speed: Measure Core Web Vitals per template. Server and CDN location matter for UAE visitors, as explained in our piece on server location, latency and Core Web Vitals.

Prioritising the findings

Fix problems that block crawling or indexing first (robots.txt, exposed staging, broken redirects), then duplicate URL problems (canonicals, case, extensions), then template quality (titles, headings, images, speed). Use the same scale thinking applied to large WordPress sites: fix the template, not the page. To decide which fixes are worth developer time, connect them to leads, as discussed in what separates Dubai sites that generate leads.

Get an outside view before the next release

If your team wants an independent list of findings to hand to its AEM developers, Codeeo's technical SEO review checks crawlability, indexing, canonicals, redirects and page speed on the live site and turns them into prioritised actions. For a wider look at content and conversion, see the website audit, or explore our digital marketing and SEO services. Our team is based in Dubai, so you can talk through findings in person. Contact Codeeo to arrange a review.