Adobe Experience Manager MCP: let Claude update AEM pages from search and AI answer data

Adobe's AEM MCP Server brings AEM into an AI client so you describe the work instead of clicking through the interface. Adobe's overview says it covers create, read, update and delete operations on pages and content fragments, plus asset import, search and management, in read-write or read-only use, with access following the permissions of the signed-in AEM user.

Adobe also lists an Experience Governance capability that evaluates text, images and pages against brand rules. Adobe's page says it requires an Agents trial or paid license, so check your own license before you plan around it.

The Claude connector listing shows five tools: list-aem-environments, lookup-api-spec, read-api, write-api and delete-api. Three are reads and two are writes. It is a partner connector with authentication required. It has no view of search demand or of what AI engines say about your brand, which is the gap Linkeddit fills.

AEM knows what you published, not whether the answer engines recommend it. Linkeddit measures that: it records which brands ChatGPT, Gemini, Perplexity, Claude and Google AI Overviews name for your buying questions, lists the gaps where a competitor is named instead of you, and tracks competitor moves from blogs, changelogs and watched pages. Compete and Answer Radar come with one plan at $60 a month.

A marketer on Reddit put the measurement problem plainly: "And I have no way to track if the AI descriptions are getting better or worse over time as we publish new content." Linkeddit gives Claude a dated record to compare against, and the AEM connector makes the change.

Linkeddit does not write or publish anything itself. It supplies the evidence, and the AEM connector, driven by Claude, carries out the edit under your AEM permissions.

Start from one gap, not a list. Ask Claude to read your open gaps with answer_gaps_get, pick the highest ranked one, and read the AEM page that should answer it with read-api. On Linkeddit's test project, plausible.io, the live read returned one open gap: "Not represented for: 'Umami vs Matomo for self-hosted analytics'", rank 1, confidence 1, intent score 0.6, evidence score 22.

Claude then proposes the change to the page or content fragment, and you approve it before write-api runs. Publishing is a separate step. Afterwards Linkeddit can re-check the question. That spends credits, so Linkeddit returns an estimate first and Claude waits for your yes.

Adobe's own AEM MCP pages describe the connector as acting on AEM content through the signed-in user, so run the first pass on an environment where a wrong edit is cheap to undo.

Use Linkeddit's keyword research and SERP tools to see which questions have demand and who ranks, then have Claude draft the page structure that answers them. The tools involved are keyword_research_get, keyword_serp and keyword_autocomplete, all of which only read.

Bounteous describes the AEM side of this in its write-up of its proofs of concept: an agent created a content fragment model, generated the campaign fragment, created a content page, and wired the fragment into the page so it could be previewed and published. Bounteous also calls the work still early, so treat the sequence as a pattern to try on a development environment, not a guarantee.

The part Claude cannot guess is which page is worth building. That comes from the demand data, which is why the order is research in Linkeddit first and edits in AEM second.

If your Google Search Console is connected to Linkeddit, gsc_queries_get returns real queries with impressions, clicks and average position, plus views for striking distance (average position 11 to 20), CTR opportunities and queries with no dedicated page. Claude reads those, finds the AEM page that owns each query with read-api, and proposes a title, intro or section change.

On the test project the same call returned no rows, because Search Console is not connected there. The response says so plainly instead of guessing. If yours is not connected either, Claude should stop and tell you rather than invent queries.

Refresh pages in small batches and change one thing per page, so a later change in position can be tied to the edit.

Yes, as two separate steps. Linkeddit's article_save stores an article in Linkeddit. Claude then reads it back and creates the AEM page or content fragment with write-api, in the model your team already uses. Keeping the two steps separate means the article is reviewed in one place and published in the other.

Ask Claude to create the page and stop before publishing, then check it in AEM with your own eyes. Adobe says changes respect your AEM permissions, so an account without publish rights will be refused, which is the behaviour you want from a first test.

Yes, and this is where fresh data helps most. compete_signals_get returns competitor moves with a priority, a category, why it matters and a source link. On the test project it returned four signals for the week of 2026-10-26, all low priority: two from Simple Analytics, on cookie banners and on tracking, and two from Umami, on its v3 preview and its roadmap overview.

Claude can turn a high priority signal into a comparison page or a fragment update, citing the source link, and you decide whether it is worth publishing. A quiet week should produce no page. Low priority signals like these are a reason to wait, not to write.

Adobe's AEM MCP Server follows the permissions of your signed-in AEM user, so the first control is the account you connect with. Use one that can edit in the environment you are testing and cannot publish to production until you trust the flow.

There is also a community AEM MCP server from Netcentric on GitHub. It runs on your own machine, works with AEM as a Cloud Service and self-hosted instances, and authenticates with client credentials or a user name and password. It is a different project from Adobe's hosted server, so check which one a tutorial is describing before you follow it.

Finally, read what Claude proposes. Check every claim, number and link in the draft against the Linkeddit data, because the AEM connector will publish whatever it is told to.