CIRCUIT

AEM and Apache HTTP server: mod_rewrite rules for SEO

AEM and Apache HTTP Server operate at different layers of a publishing stack: AEM manages structured content, templates and page delivery, while Apache handles incoming HTTP requests and can route them to AEM Dispatcher or another origin. Setting up AEM and Apache HTTP Server mod_rewrite rules for SEO starts with deciding which URLs should exist publicly, which should redirect and where the canonical signal belongs.

Developers working with AEM can learn much from the two-day CIRCUIT conference in Chicago, whose agendas, speaker details and session recordings are preserved on the CIRCUIT event archive. Its 2015 and 2016 programmes cover architecture, integrations and front-end delivery, although current Adobe documentation should guide implementation decisions.

For Australian organisations, URL design must support a geographically spread market without creating duplicate destinations. Common domain choices include .com.au, service pages may target Sydney, Melbourne and Brisbane, and Australian English usually means en-AU metadata alongside spellings such as “organisation”. Each campaign, product and location needs one preferred address.

The safest approach is to change one routing layer at a time, preserve meaningful query parameters and verify every redirect with real URLs. Apache mod_rewrite is powerful, but an SEO migration fails when a rule creates a loop, exposes AEM paths, changes the wrong host or sends crawlers to a generic homepage.

Design a stable URL and redirect policy

Begin with a URL inventory rather than a collection of regular expressions. Record each indexable AEM page, its current public address, the intended destination and any campaign aliases. Flag trailing slashes, index.html variants, uppercase paths and inherited query strings, because search engines can treat those as separate URLs even when the rendered content is identical.

Choose one canonical pattern, such as lowercase paths with a trailing slash, and apply it consistently in AEM links, XML sitemaps, social metadata and Apache. A new South Australian service page might belong at /service-areas/adelaide/solar-installations/, while the national product remains at /products/solar-panels/. Store that policy in version control with named examples for edge cases.

Configure Apache in front of AEM

Apache normally sits before AEM as the public gateway, commonly through AEM Dispatcher. The rewrite engine can enforce host and protocol rules before content selection, but it should not impersonate AEM’s content model. Keep AEM aliases and authored metadata in AEM, and reserve server-level routing for requests that need a consistent HTTP response.

Enable mod_rewrite and grant access only to directories that need local rules. If directives live in .htaccess rather than the virtual host, the Apache service account must be able to read those files. Replace the example path with the actual document root.

<Directory /var/www/aem-publish>
    Options +FollowSymLinks
    AllowOverride FileInfo Options
</Directory>

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
</IfModule>

Test the active configuration with apachectl configtest before reloading Apache, and retain a rollback copy of the previous virtual host. Also deny requests for sensitive AEM authoring and system paths before they reach the public instance; hiding them with a redirect does not provide access control.

Redirect legacy URLs to the correct pages

Use a 301 permanent redirect when a legacy URL has a genuine replacement. It transfers search-engine signals more effectively than a 302 and makes the relationship clear to users and crawlers. Each old path should map directly to its closest relevant page, not indiscriminately to the home page, and chains should be flattened into one hop wherever possible.

Place focused rules in the production virtual host rather than applying broad transformations to every environment. These examples consolidate the preferred host, enforce HTTPS and map a retired campaign URL directly to its replacement.

RewriteRule ^solar-offer/?$ /products/solar-panels/ [R=301,L]

RewriteCond %{HTTP_HOST} !^www\.example\.com\.au$ [NC]
RewriteRule ^ https://www.example.com.au%{REQUEST_URI} [R=301,L]

RewriteCond %{HTTPS} !=on
RewriteRule ^ https://www.example.com.au%{REQUEST_URI} [R=301,L]

Original query parameters are normally copied when the replacement contains no question mark, but this should be confirmed for every rule family. The HTTPS condition also depends on Apache seeing the secure scheme. Behind a load balancer or CDN, inspect the forwarded protocol from a trusted proxy instead of trusting an arbitrary client header.

Handle canonical URLs and duplicate paths

Canonicalisation has two parts: redirecting duplicate requests to one address and declaring the preferred address in the page head. Apache can handle obvious duplicates such as a trailing slash, but the rel="canonical" element should be generated by the AEM template or page model so its value follows the content’s language and region. These signals must agree.

<link rel="canonical"
      href="https://www.example.com.au/products/solar-panels/" />

Do not strip every query parameter. Campaign tags such as utm_source can be useful for attribution, and search parameters may select a valid product variant. Normalise only known duplicates, keep revenue-bearing or paginated parameters, and self-canonicalise each paginated result rather than pointing every page to page one.

Non-HTML routes need separate treatment. AEM APIs, GraphQL endpoints and app-delivered content should not be redirected as if they were web pages. The content-fragment delivery patterns recorded for CIRCUIT show how structured content can serve mobile apps independently of an authored web page; those endpoints need their own authentication, caching and canonical-access rules rather than an HTML rewrite.

Protect crawl signals and staging environments

Staging and preview systems must not enter the index. Password protection alone can leave crawlable URLs, so return a noindex response while still enforcing access controls. With mod_headers enabled, apply the header at the staging virtual host rather than relying on a robots.txt rule, because robots.txt controls crawling rather than removal from results.

Header always set X-Robots-Tag "noindex, nofollow"

Preserve accurate HTTP status codes: serve 404 for a missing page, 410 for content deliberately removed, and 301 only for a permanent move. Generate XML sitemaps from the canonical AEM URLs and align them with robots directives and internal links. Across Australian CDN edges, verify that the same redirect and cache headers are returned as at the origin. Log status codes, request paths and user agents so regressions become visible before search engines encounter them.

Compare rewrite responsibilities across the stack

SEO routing works best when each layer has a clear responsibility and one source of truth. The following comparison shows where common actions belong and what each option can accidentally alter.

Layer Best responsibility SEO benefit Main risk
AEM templates and page properties Authored canonical URLs, language regions, aliases and sitemap entries Keeps content signals close to their source Published metadata can conflict with gateway rules
Apache mod_rewrite Host, protocol, legacy-path and slash normalisation Provides consistent redirects before content selection Bad conditions can create loops or discard parameters
AEM Dispatcher filters Access restrictions, cache eligibility and denied paths Protects unpublished content and improves caching Rules that bypass filters can expose internal resources
CDN and edge rules Fast redirects, geolocation logic and response-header overrides Reduces latency for distant audiences Stale edge configuration can disagree with the origin

Use AEM for content-specific signals, Apache for stable gateway behaviour and Dispatcher for access and cache controls. CDN rules can shorten response times, but only when origin and edge configuration remain synchronised. Test combinations such as a legacy URL, a tracking query string, a language path and a preview host; a rule that works for one can expose a mismatch in another.

Performance decisions deserve the same discipline. A discussion of benchmarking string operations illustrates why a universal winner can be less useful than results measured under realistic conditions. Measure rewrite overhead using representative HTML requests, cached assets and redirects, then compare CPU use, latency and error rates before and after each change.

Recommended rollout sequence

Use a staged deployment sequence that connects technical checks with search and business outcomes. The following recommendations give the rollout team a practical order of operations:

  • Export priority URLs from AEM, analytics and Google Search Console; record their current status, traffic, links and intended destinations.
  • Build and test redirect rules in staging, including query strings, language variants, trailing-slash behaviour and non-www requests.
  • Align Apache responses with AEM canonical tags, XML sitemaps, internal links and hreflang values before the production release.
  • Release one URL group at a time, monitor logs and crawl reports, and maintain a documented rollback path for every rule change.

After deployment, check redirect chains, response codes and server logs at short intervals during the first crawl cycle. Compare landing-page traffic and conversion data with the pre-change baseline, especially for Australian campaigns that target different cities or use campaign parameters. Keep old rules until the replacement pages are indexed and no valuable external links still point at the retired addresses.

Start by exporting the highest-value legacy URLs and implementing one redirect group in staging today. Validate it against real traffic samples, then release that group with monitoring and rollback ready before expanding the policy.