How we gave each AEM page its own head script with Sling Rewriter

In a client project with a company building AI for enterprise customer experience, we needed to load a different JavaScript file in the <head> of each AEM page. The script would change what visitors saw in their browsers. AEM did not need to create a content component for every variation.

Our first concern was the shared head file. In the AEM sites we had worked with, one Page component and its customheaderlibs.html could serve many pages. We initially assumed that meant the head would load the same script everywhere. The requirement challenged that assumption: how could one head implementation choose a different script for each page?

What a shared head file could already do

AEM renders the shared Page component in the context of the current page. The head file can therefore read a script URL from that page's jcr:content. Page A can hold one URL and page B another, even though both use the same template. If we controlled a single site's Page component, a conditional script tag in its head file would have been enough.

We were building a connector for multiple client sites, though. We could not assume they used the same Page component or ask every client to edit its head file. Adding a common loader through a page policy still left each site with an integration step. Having the package rewrite a client's customheaderlibs.html was fragile because Page component paths and contents vary. AEM as a Cloud Service also deploys application code through Cloud Manager and does not support package install hooks for that purpose. Adobe explains those deployment constraints.

Could a tag manager have handled it?

Yes. The original site already used Adobe Tags, whose rules can run custom code when conditions match. Google Tag Manager can also fire a custom HTML tag for a particular page URL. Adobe's rules documentation and Google's trigger documentation describe those options.

For this connector, that route would make page-to-script assignments depend on each client's tag container and its release process. We needed the assignment attached to the AEM page and governed by its Author and publication flow. The requirement also called for the script tag in the rendered <head>, whereas a tag-manager rule would insert or run code in the browser. Sling Rewriter gave us the server-rendered tag without relying on a browser rule. We did not build a Google Tag Manager version; a client that already manages its scripts there could reasonably choose it.

Adding the tag to rendered HTML

We used Sling Rewriter at the point between AEM rendering the page and sending its HTML response. A transformer receives events from the parsed HTML and can add an element before the response is serialized. Sling supports a global transformer that joins existing rewriting pipelines without replacing each client's pipeline configuration. Apache Sling describes that extension point.

Our OSGi bundle registered a TransformerFactory with pipeline.mode=global. For each normal HTML page response, the transformer identifies the current page and reads its enabled script assignment. It accepts only an HTTPS URL on an approved host. At </head>, it emits the script tag once. It leaves unassigned pages, editor responses, selector requests, and duplicate tags alone.

Here is the simplified result with illustrative .example URLs:

• Page A stores https://scripts.example/a.js and renders <script src="https://scripts.example/a.js"></script> in its head.
• Page B stores https://scripts.example/b.js and renders <script src="https://scripts.example/b.js"></script> in its head.

Both responses use the same transformer. The script URL comes from the page being rendered, so the connector does not change the client's Page component or save HTML tags into individual pages.

Getting an assignment onto Publisher

The AI platform knew a public URL, while AEM stored the assignment on an internal page. Our Author endpoint resolved the public URL through configured site routes and saved the script URL and enabled flag on that page's jcr:content. The transformer on Publisher could read the assignment after the page was published. We supported two publication modes: auto could request whole-page activation for controlled tests, while manual left publication to the client's approval process. Automatic whole-page publication can release other draft edits, so that choice belongs to each site's workflow.

The page-level test

In local AEM, we verified script execution with a headless browser. Two published pages loaded and ran different scripts. Neither page ran the other's script. A third assignment remained on Author in manual mode and did not appear on Publisher. Disabling one published assignment removed its script while the other page continued to run.

That test established page isolation across Author and Publisher. The same delivery path also calls for checking the final response through Dispatcher and CDN, the site's Content Security Policy, any existing rewriter configuration, and whether a script at the end of <head> meets the required load timing.

The shared head could read page-specific data all along. To deliver that behavior through an installable connector without touching each client's Page component, we put the logic in Sling Rewriter. Two published pages then ran different scripts through the same transformer.