Update your website content through a conversation

A service page needs an update. The business has approved the new information, but someone still has to find the right entry, edit its fields and check the page. A connected AI assistant could help carry that request into the content management system, or CMS.

Start with a concrete instruction:

Draft this service-page update from these approved notes. Show the changes and a preview; leave it unpublished.

This guide follows an illustrative workflow for an authorised content editor. It shows what an integration would need to do, rather than describing a launched Devmojos connector. The example stops at a draft; publication follows the permissions and publishing rule agreed for the business.

Give the request a clear boundary

Identify the page and language before editing. Attach the approved information and say which fields may change. Existing facts outside that request should stay intact.

Figure 1 as text

An authorised editor provides approved notes. The assistant reads existing service-page fields and saves a structured draft. Compare old and proposed values and preview the page. The publishing rule and CMS permissions determine approval or publication. Record the actual result, resolve conflicting edits and verify the recovery path supported by the CMS.

1. Request and source notes — From someone allowed to edit, with the approved notes.
2. Structured draft — Save into the existing content fields.
3. Field diff and preview — Old and new text side by side, and the page as it would look.
4. Publish by your rule — Review first, or another policy you agreed for this content.
5. Result and recovery — Who changed what, and a way back where your CMS supports it.

For this example, the editor wants a clearer service-page heading and summary. The assistant should read the current values, prepare replacements and save a draft. It should flag a missing fact or conflicting instruction for clarification.

The connection needs access appropriate to this work. Someone allowed to edit a service page should not gain broader publishing rights by asking an assistant. Access needs to be enforced by the connected system.

Save a structured draft

A CMS usually separates content into fields. A heading, a summary and a contact link can each have a defined place. The integration should map the request to the actual content model and respect its validation rules.

In the illustration, “Website design” becomes “Websites built around the next enquiry”. A generic summary becomes a description of service information, relevant work and an agreed contact route. These are example copy changes, not claims about a particular client.

The assistant should report what the CMS actually saved, including the entry and its status. A generated answer in the conversation is only a proposal until the CMS confirms the write.

Compare the fields and preview the page

A field comparison shows the old and proposed values. It helps the editor notice an altered contact link or a fact that changed outside the request. The page preview answers a different question: how does that content read in the website?

Check the heading on a phone, the image and its alternative text, and the destination of the contact action. Keep the draft clearly distinguishable from the public page. Where several languages are involved, show which version was edited and which translations still need work.

For the request above, the handoff is a saved draft, a comparison and a preview. “Leave it unpublished” remains part of that instruction.

Apply the publishing rule you agreed

The business decides which actions require review and who may publish. A workflow could require an editor to approve every page. Another could permit routine corrections within a defined scope. The connection must apply that policy and the CMS permissions together.

Drafting and publishing should be distinct actions with clear outcomes. If publication needs approval, present the exact version for that decision. If the agreed policy permits publication, record which rule and authorised action allowed it. A failed permission check should leave the content in its previous state and explain what is needed.

This distinction lets the business choose a useful level of automation while keeping responsibility clear.

Record what happened and how to recover

Keep a record of the request, affected entry, version and action taken. Include the result returned by the CMS. If publication is queued, report that state. Confirm the public page after publication, allowing for the website’s build or cache process.

Version history and rollback depend on the CMS and the integration. Check those capabilities before promising a restore button. Where supported, identify the previous version and the permitted recovery action. Reverting content may also require the website to rebuild or refresh its cache.

If another editor changed the entry in the meantime, surface that conflict before overwriting it.

Separate content work from development

This approach can cover text in existing fields and approved assets where the integration supports them. Navigation changes belong in scope only when explicitly included. Images still need suitable rights and accurate descriptions.

A new page template, a different content model or a change to application behaviour needs a development scope. A conversational request can help describe that work, but it does not make the underlying code change part of a routine content edit.

Check the assistant and CMS connection

MCP is one way to give an assistant defined tools for an external system. OpenAI documents custom MCP connections with read and write tools in ChatGPT, subject to workspace and security settings. Claude documents remote MCP connectors, with organisation and individual access to configure. Check the intended account and CMS before proposing a setup.

Browser WebMCP is a separate, proposed web standard for agents interacting with tools on a webpage. Adding it to a website does not by itself connect that CMS to cloud chat assistants.

The practical starting point is one content type, someone responsible for access and an agreed publishing rule. Try the complete path on a test entry, including a rejected action and a recovery check. That gives the business evidence for deciding whether to extend the workflow.