AEM URL conversion
Converting AEM URLs between environments without fixed templates
Author, preview, staging and production links often describe the same content through different domains and path rules. The reliable solution starts with your site’s examples, not somebody else’s URL convention.
Why AEM URL conversion is rarely a simple domain swap
It is tempting to replace an authoring hostname with a production hostname and call it done. That only works when every other part of the URL remains identical. In practice, authoring URLs can contain content roots, HTML suffixes, mode parameters or a path structure that the public site does not expose.
Public URLs can have their own rewrite rules too. A project can remove a content prefix, use a different hierarchy for one section, or retain a variable segment that another environment does not use. These are implementation details, but they directly affect everyday content QA.
author.example.com/content/en/products/item.html?mode=preview↓preview.example.com/en/products/item↓www.example.com/en/products/itemThe conversion is a relationship between whole patterns: host, fixed path pieces, variable pieces, suffixes and parameters. Treating only the hostname as variable creates links that look plausible but lead to the wrong place.
Common mistakes when mapping AEM environments
Assuming every section follows the same path rule
A global navigation section, campaign landing page or application area can have a different public rewrite. Test examples from the important path families before relying on one rule.
Dropping a meaningful variable segment
Locale, market, brand or site-root segments can be variable values rather than removable prefixes. A conversion must preserve the value when the target needs it.
Carrying authoring parameters to a public URL
Mode parameters are useful while authoring, but they can be irrelevant or harmful in visitor-facing links. Treat query strings as part of the rule, not as an afterthought.
Trusting a conversion without checking the target page
A correctly shaped URL can still return a redirect or an unavailable page. Conversion and link verification are related but separate checks.
A safer way to define a mapping
Collect at least three genuine page pairs for each environment you use. Choose different pages, rather than three examples from one nearly identical template. Then compare what is fixed and what varies:
- the hostname and optional port;
- path segments that are always added or removed;
- segments that change value but must be preserved;
- suffixes such as
.html; - query parameters that belong only to one environment.
With a stable mapping, always test both directions. A rule that reaches production correctly may not reconstruct the authoring URL correctly on the way back.
How Slingmap approaches the problem
Slingmap asks for real URLs from the environments you configure. It infers a reusable relationship from the shared and variable parts, instead of embedding a client-specific path template. You can name environments however your team does and add the groups that your workflow needs. The same configuration supports one-click navigation and bulk URL conversion.
Use conversion as part of QA, not as a shortcut alone
Opening the equivalent page is useful only if the page is then reviewed. A practical sequence is: convert the current page, confirm it resolves, check the page links in their CTA context, then review the main SEO metadata and any heavy image assets. That makes environment switching a quality step rather than just faster navigation.
For a wider release process, use the AEM QA checklist for links, assets and environment URLs.
Teach Slingmap your own URL pattern
Configure real examples once, then convert and open equivalent pages from the browser toolbar.
Add Slingmap to Chrome