An AEM QA checklist for links, assets and environment URLs

Why a page-level QA checklist still matters

A content change can be correct in an authoring environment and still fail where the visitor sees it. A link can retain the wrong domain, a CTA can lead to a page that does not exist in the target environment, or one large image can make an otherwise small change expensive to load.

The purpose of a QA checklist is not to replace automated regression testing. It gives authors and manual QA a short, repeatable way to verify the page they are actually reviewing, in the context in which it will be used.

The checklist

1. Identify the source and target environment

   Write down the page you are checking and the equivalent environment it must work in. “Preview” and “production” are labels; what matters is the actual URL pattern for each of your environments.

2. Verify that the page maps to the intended URL

   Check the path, locale or market segment, suffix and query parameters. Do not assume that removing a prefix or changing a domain is enough: different environments often need different path rules.

3. Check internal links in their CTA context

   Review every relevant navigation link, button and inline CTA. When a result fails, record the visible CTA label as well as the destination URL. A bare failing URL forces the next person to hunt for the element again.

4. Review redirects separately from failures

   A redirect is not automatically wrong, but it is a decision worth reviewing. Confirm it is deliberate, does not add an unnecessary hop, and lands on the intended destination for that environment.

5. Review image assets that can affect page weight

   Look for unusually heavy image files and check whether the format, dimensions or rendition are appropriate for the component. A file that is acceptable for a hero may be wasteful in a small content card.

6. Confirm the page-level SEO basics

   Check the title, meta description, canonical URL, robots directive, language and social metadata. This is a fast way to catch an accidental carry-over from another page or environment.

7. Repeat on representative variations

   Use the same process on at least one page for each template family and URL structure. You do not need to manually retest identical patterns forever; you do need to notice where the pattern changes.

What a correct environment mapping looks like

A reliable mapping is based on examples from your own site, not on a generic rule copied from another implementation. For example, a source URL can have an authoring prefix, an HTML suffix and a mode parameter, while the visitor-facing URL may use neither.

The important part is the relationship: domain, removable path segments, variable segments, suffixes and parameters. Document it once if the setup is stable; review it when the platform or rewrite rules change.

A simple hand-off format

When you find an issue, make it actionable. A useful QA note contains the source page, target environment, CTA label or component context, actual URL, expected URL and the observed result. This is much easier to fix than “one link is broken.”

That small amount of context removes ambiguity for authors, QA, developers and external teams. It also lets recurring issues reveal a pattern instead of being treated as isolated mistakes.

Make the process smaller, not the standard lower

Good QA should feel proportionate. A routine content update does not need the same work as a major release, but it should never depend on memory alone. A compact checklist, accurate environment mappings and useful issue context reduce the repetitive work without reducing the quality bar.