AEM link checking
A broken URL is not enough: an AEM link checker needs CTA context
A useful link check should tell you what failed, where it sits on the page and what the visitor was trying to do. Otherwise, it only moves the manual work to the next person.
The problem with a list of failing URLs
A page can contain navigation links, cards, footers, buttons, embedded content and repeated components. When a check returns a list of URLs alone, someone still has to locate every destination in the rendered page before they can decide whether to fix it, update it or ignore it.
That is especially slow on AEM pages where components may reuse similar wording and where the same destination can appear in more than one place. The meaningful unit of work is not just the URL. It is the visible link and its CTA context.
What a useful link result should contain
This context makes a manual check useful to authors and QA, not only to a developer reading network responses. It also makes the result suitable for a clear hand-off.
A practical AEM link-checking workflow
Open the page in the environment you are reviewing
Run the check on the same version of the page a reviewer or visitor should see. Different environments can legitimately return different destinations.
Separate broken links from redirects
Fix unavailable pages first. Then review each redirect to make sure it is intentional and does not point to an outdated path, locale or environment.
Use the CTA label to find the component
Read the visible text before changing anything. This prevents a common error: fixing a similar-looking link in another component while leaving the actual failing CTA unchanged.
Confirm the expected target after the edit
Do not stop when the request no longer fails. Confirm that it reaches the intended page, not simply any reachable page.
Record exceptions with enough context
Some outbound links and expected redirects will be valid. Leave a brief reason so they are not re-investigated on every release.
Use a hand-off that someone else can act on
When an issue needs another team, include the page and component context. It eliminates the usual back-and-forth before the actual fix begins.
Page: /en/campaign/springCTA: “Explore offers”Component: campaign heroObserved destination: https://www.example.com/en/offers/springResult: unavailableExpected destination: https://www.example.com/en/offersThis is also more useful than screenshots alone: it can be reproduced directly and checked again after the correction.
How Slingmap handles page links
Slingmap checks the links present in the page and reports their status. For problematic results, it shows the CTA label or link text when available and lets you jump to the matching element in the page. It also distinguishes redirects from unavailable links, so the review starts with the right question.
Where automated testing begins
This workflow is deliberately page-level and human-readable. It is useful during authoring, content QA and release review. For high-volume regression testing, authenticated flows or scheduled tests, a dedicated automated test suite is still appropriate. The two approaches solve different parts of the quality process.
The best outcome is not more reports. It is a shorter path from a detected problem to the exact AEM component that needs attention.
Check the page you are already reviewing
Install Slingmap to check links with useful CTA context from the browser toolbar.
Add Slingmap to Chrome