How we mapped live SEO edits back to AEM Author

An enterprise SEO platform serving global brands needed to send a public page URL to AEM and update what appeared on that page: metadata, an H1, selected text, a link, an image, or structured data. The request arrived in terms of the live website. AEM stored the source in page properties and components under /content, sometimes with values inherited from a language master. We had to identify the exact thing to change before accepting an edit.

Our first plan split the work. Metadata could be updated on Author, where its page properties lived. For an XPath-selected heading or link, we initially thought we might need to modify the rendered page on Publish. We could see the element there, but could we find which AEM component and property produced it? A Publish-only change would not become an ordinary authored change that survived the next publication. We wanted the API to work through AEM's content model.

Finding the property behind the HTML

We tested whether Author could render a page with editing disabled and tell us which component produced a selected element. A component render trace gave us the rendered fragment and its resource path. We then evaluated the requested tag or XPath against those fragments, chose the most specific component when parent and child traces contained the same element, and looked for a matching editable property in that component's page-local subtree.

The early tests were useful because they did not always find one answer. A visible H1 could come from a teaser title, a page property, or a custom component. One trace exposed two candidate title properties. Another showed the heading but no page-local property we could safely edit. Those cases shaped the rule: a rendered match alone was not permission to write. The request needed a unique target and the current value had to match what the caller supplied. If the source was missing, shared, computed, or ambiguous, the connector returned an error.

That result let us bring the XPath and H1 changes back to Author. We did not have to create an instruction that patched a Publisher response. The API could save a normal content change and let AEM's publication process deliver it.

Resolving the public URL before changing content

The public URL still needed its own checks. A shortened path, a vanity URL, a Dispatcher rewrite, and a redirect can all lead to different AEM resources. We put site roots, public origins, property mappings, and explicit URL rules in per-site configuration. A request could update only a page under the configured root.

This was not just configuration on paper. In local routing tests, an existing redirect page initially took precedence over the intended destination. We changed resolution so an explicit destination rule wins. If that rule points to a missing page, the connector rejects the request rather than falling back to another resource. We verified that a write aimed at a redirect destination changed the destination page, not the redirect page.

Respecting inherited content and other owners

Language copies made the meaning of “this page” more complicated. A visible value on a copy may still be inherited from its master. The connector checks that relationship before a write. Depending on the configured metadata mode, it can update a local copy value or the verified master source. Inherited H1 and XPath targets go to the verified source; local or inheritance-cancelled targets can change on the copy. The connector does not silently cancel inheritance or roll out a master change to every copy. Adobe's Multi Site Manager documentation explains why source and live-copy state have to be treated separately.

Structured data needed the same respect for ownership. Pages can hold several JSON-LD objects. We used the page's structured-data property and tracked only objects written by the connector. Replacement and removal preserve other objects and fail when the stored content no longer matches the ownership record. A later test caught a JCR single-value versus multi-value storage failure; we corrected that path and added repository-level tests before treating removal as reliable. A compatible AEM Core Page Component can render page-level JSON-LD, while custom page components require their own rendering check.

What the tests established

The final connector uses Author-hosted APIs. Local tests covered metadata and H1 changes, XPath updates to text and dedicated link or image properties, structured-data preservation, language copies, public URL routing, and optional publication. We also exercised local Publisher and Dispatcher. One delivery test exposed a warm Dispatcher cache that still served old HTML because local invalidation was not configured. A successful Author write or replication request could not be treated as proof that the public response was fresh.

The package was ready for client-environment acceptance, where authentication, component mappings, publication rules, and cache behavior could be checked against the site's own setup.

The lesson we carried into other AEM integrations was to begin with content ownership. Finding a string in HTML is only the first clue. A live URL can identify the page and an XPath can identify what the visitor sees. The connector should write only after it can also identify the Author resource, the editable property, the inheritance state, and the expected current value. That is how we turned a live SEO request into an authored AEM change.