AEM Cloud Service: Runtime Exclusion of External Links from Link Checker

[MarekStryjenski]

I'm experiencing an issue where external links are incorrectly flagged as broken by AEM's Link Checker, as documented in KA-27042

I'm aware of two existing methods to exclude links from the Link Checker:

1. HTML attribute approach:

   <a href="https://www.example.com" x-cq-linkchecker="skip">Link Text</a>

1. OSGi configuration approach: Configure link checker service to exclude specific external domains via OSGi config.

Is there a content-author-friendly way to exclude external links from the Link Checker at runtime in AEM as a Cloud Service?

Specifically, I'm looking for a solution that would allow:

• Content authors to exclude problematic links without developer intervention
• Runtime exclusion when false positives are discovered in production
• No code deployment required for link exclusions

[giuseppebag · Accepted solution]

hi @MarekStryjenski, 

As suggested in KA-27042, a temporary workaround is to add a trailing slash (/) at the end of external URLs to prevent them from being flagged as broken links. 

Alternatively, if you cannot use the OSGi configuration approach, a more user-friendly solution would be to update the components where a link is utilized by adding a new property to set the attribute.

x-cq-linkchecker="skip"

 You should add to the dialog a checkbox:

<skipLinkChecker
        jcr:primaryType="nt:unstructured"
        sling:resourceType="granite/ui/components/foundation/form/checkbox"
        text="Skip Link Checker"
        name="./skipLinkChecker"
        value="{Boolean}false" />

Then on the HTL of the component:

<a data-sly-attribute.x-cq-linkchecker="${properties.skipLinkChecker}" href="${properties.linkHref}">${properties.linkLabel}</a>

For the RTE, you can extend the link modal to include the field as well: https://experience-aem.blogspot.com/2017/09/aem-63-touch-ui-extend-rich-text-link-dialog-add-rel-sel... 

[MarekStryjenski]

Hi Giuseppebag,

Thank you for the reply. In my opinion indeed component-level approach is more user friendly and is better solution for us. The OSGi method becomes impractical since we can't predict which external links might need exclusion in the future.

Thank you for code snippets, they are really useful.

Just small correction for future readers: I noticed a potential issue with the HTL code snippet. The x-cq-linkchecker attribute expects specific string values:

• x-cq-linkchecker="skip"
• x-cq-linkchecker="valid"

In the current example:

<a data-sly-attribute.x-cq-linkchecker="${properties.skipLinkChecker}" href="${properties.linkHref}">${properties.linkLabel}</a>

If the checkbox is checked, this would output:

<a x-cq-linkchecker="true" href="...">LinkLabel</a>

But the Link Checker won't recognize "true" as a valid instruction.

What should be in my opinion:

<a data-sly-attribute.x-cq-linkchecker="${properties.skipLinkChecker ? 'skip' : ''}" 
   href="${properties.linkHref}">
   ${properties.linkLabel}
</a>

This way, when the checkbox is checked, it outputs x-cq-linkchecker="skip", and when unchecked, the attribute is omitted entirely.

Thanks again for pointing me toward this solution - it's exactly what we needed for runtime link exclusion without deployment cycles!

Best regards, Marek