How Detection Works
SiteAuditPro automatically detects Adobe Experience Manager (AEM) sites during every scan without requiring any manual configuration. The detection engine examines the page source for a set of AEM-specific signals that are reliably present across both AEM 6.x on-premise installations and AEM as a Cloud Service deployments.
The primary markers include /content/ path structures in asset URLs and internal links, which are characteristic of AEM's JCR content repository. The scanner also checks for cq: namespace attributes in the HTML, AEM clientlib path patterns such as /etc.clientlibs/, and dispatcher-specific response headers that AEM environments commonly emit.
Once these signals are confirmed, SiteAuditPro adds an AEM-specific analysis layer on top of the standard SEO, LLM readiness, and performance checks. The entire process happens in the background — there is no setup step, no integration to configure, and no credentials to provide. If you are on a Premium plan and scan an AEM-powered site, the additional checks are included automatically from the very first audit.
Requirements
Because AEM detection is fully automatic, the requirements are minimal:
- A SiteAuditPro Premium plan — AEM-specific CMS checks are not available on the Free tier
- Your site must be built on Adobe Experience Manager, either AEM 6.x (on-premise or managed services) or AEM as a Cloud Service
- No manual configuration needed — detection is automatic and runs on every scan
AEM detection relies on the presence of standard AEM output patterns in publicly accessible HTML. Sites that run AEM in a fully headless configuration — where AEM serves only Content Fragments via API and all HTML is rendered by a separate front-end framework — may not expose the AEM-specific markup patterns that detection looks for. In those cases, the standard audit results remain fully accurate, but the AEM-specific check layer may not activate.
For the vast majority of AEM sites using AEM Sites components, Core Components, or traditional template-based rendering, detection will function correctly without any intervention on your part.
What Gets Checked
Once AEM is detected, SiteAuditPro runs a set of checks specifically tailored to how AEM sites are structured, deployed, and optimized. These checks appear alongside your standard audit findings and address the areas where AEM deployments most commonly introduce SEO or performance issues:
- Dispatcher configuration analysis that evaluates caching headers, identifies whether the dispatcher is properly caching responses, and checks for URL rewriting rules that expose or clean up
/content/paths - AEM component usage patterns and render efficiency, checking whether components are generating clean, crawlable HTML or producing excessive DOM nesting and inline styles that affect both performance and SEO
- AEM-native SEO signals including
sling:vanityPathconfiguration,cq:tagspropagation to meta keywords, and whether AEM page metadata properties are correctly mapped to HTML head elements - Client library (clientlib) optimization and aggregation, verifying that JS and CSS are being properly combined and minified rather than served as individual unoptimized files
- Content Fragment and Experience Fragment SEO structure, checking whether fragment-based content is being rendered with appropriate semantic markup and whether structured data is present where expected
- AEM-specific redirect configuration and URL mapping, including checks for sling:redirect nodes, vanity URL conflicts, and whether the URL map is configured to present clean URLs to search engines
These checks complement the standard audit results. A full AEM audit gives you the complete picture: technical SEO health, LLM readiness scores, Core Web Vitals performance data, and the AEM-specific layer that identifies issues unique to the platform.
Interpreting Results
AEM-specific check results appear alongside your standard findings. Each check shows a pass, warn, or fail status with a score and a detail message explaining what was found and what action, if any, is recommended.
Dispatcher analysis results are among the most impactful. A passing dispatcher check confirms that caching headers are correctly set and that the dispatcher is serving cached content for appropriate request types. A warning typically indicates that Cache-Control headers are absent or misconfigured, which forces the dispatcher to re-render pages on every request and significantly degrades Time to First Byte. A failing result may indicate that the dispatcher is not caching at all, or that /content/ paths are being served directly to browsers without URL rewriting.
Component usage scores reflect how efficiently AEM components render the page. High scores indicate clean, well-structured HTML output typical of AEM Core Components. Lower scores may point to legacy custom components producing bloated markup, excessive inline scripts, or render-blocking resource loading patterns that degrade Core Web Vitals.
SEO signal checks verify that AEM-specific metadata is correctly propagated. A warning on sling:vanityPath checks may mean that vanity URLs are configured in AEM but not correctly resolving, or that canonical tags do not point to the intended canonical URL. The detail message will specify which signal is missing or misconfigured.
Clientlib scores indicate whether JavaScript and CSS are properly aggregated and minified. AEM's clientlib system is designed to concatenate and minify assets, but misconfigured categories or debug mode enabled in production will bypass this optimization entirely. A failing clientlib check is a reliable indicator that assets are being served unoptimized.
Optimization Tips
Ensure the dispatcher caches static content aggressively with proper TTLs. The AEM dispatcher is the most important performance layer for AEM sites, but its effectiveness depends entirely on correct cache configuration. Verify that Cache-Control and Expires headers are set for all cacheable responses, that cache invalidation rules are scoped correctly so that a single content update does not flush the entire cache, and that TTLs are long enough to provide meaningful performance benefits without staling content unnecessarily.
Use AEM's built-in URL mapping for clean, SEO-friendly URLs instead of exposing /content/ paths. Raw AEM URLs containing /content/sitename/en/ are not SEO-friendly and can cause duplicate content issues if both the clean URL and the internal path are accessible. Configure the Sling URL Map or dispatcher rewrite rules to ensure that all public-facing URLs are clean, and that any request to a /content/ path is redirected to its canonical form with a 301 rather than served as a separate page.
Aggregate and minify client libraries to reduce page load time. AEM's clientlib system provides built-in support for concatenation and minification, but it requires correct category assignment and must not be running in debug mode in production environments. Check your com.day.cq.widget.impl.HtmlLibraryManagerImpl OSGi configuration to confirm that minification and gzip compression are enabled. Also audit clientlib categories for duplicate inclusions — it is common for multiple components to include the same library category, resulting in the same JS being loaded more than once.
Leverage AEM's built-in image optimization via Dynamic Media or adaptive image servlets. AEM Core Components include an adaptive image servlet that can serve responsive images at appropriate resolutions, but it must be configured correctly to function. If your site uses Dynamic Media, verify that image presets are defined for common viewport sizes and that images are being served through the Dynamic Media CDN rather than directly from the AEM publish instance. Unoptimized large images are one of the most common causes of low Largest Contentful Paint scores on AEM sites.
Implement proper sling:vanityPath configuration for marketing URLs. AEM's vanity path feature allows editors to assign short, memorable URLs to pages without going through IT. However, vanity paths that conflict with existing URL mappings, that lack corresponding canonical tags, or that resolve to the same content as the primary URL without a redirect can create duplicate content problems. Audit your vanity path configuration to ensure each vanity URL either 301-redirects to the canonical URL or has a canonical tag pointing to the intended primary URL.
One aspect of AEM auditing worth bearing in mind: detection accuracy depends on the publicly rendered HTML containing standard AEM output markers. AEM as a Cloud Service sites using the latest Core Components will be reliably detected. Heavily customized AEM implementations that strip or override default component output, or that use AEM purely as a headless content store with a non-AEM front end, may not trigger detection. In those cases, your standard audit results remain fully accurate — you simply will not see the AEM-specific check layer on top of them.
For sites that are detected correctly, the AEM-specific checks provide immediate, targeted insight into the areas where AEM deployments most frequently underperform: dispatcher caching, URL cleanliness, clientlib optimization, and metadata propagation. These are issues that general HTML-level checks will not surface — they require understanding AEM's architecture to recognize when that architecture is not being used to its full potential. That is precisely what the CMS detection layer is designed to do.