How to Have ChatGPT, Claude, Codex or Cursor Edit an Existing Website

Yes. ChatGPT, Claude, Codex, or Cursor can help edit an existing website. But a chat window cannot change a live page by itself. The tool needs access to the site's code, its signed-in editor, or an authorized API. You still need to review the change and confirm how the site publishes it.

Start with one question: Where do you make changes today? If your site comes from a Git repository, use a coding agent. If you change pages in a hosted builder, use its editor in a browser. If the site has a CMS API, use that API for supported content fields. A public URL alone gives the agent something to inspect, not permission to edit.

Route 1: Let a coding agent edit the repository

Use this route when you or your developer can point to the repository that builds the site. Codex can edit files in its workspace. Claude Code reads and edits a codebase and runs commands. Cursor Agent can search, edit, and test code. These are ways to change source files. They are not the same as signing in to a live site's admin panel.

Give the agent the repository, the exact page or component, and one clear result. For example: "On the existing /pricing page, change the plan heading to 'Simple pricing'. Keep prices, links, and layout unchanged. Show me the diff and run the site's checks. Do not deploy." Ask it to identify the source file before it edits. A screenshot and the page URL help when the same text appears in several files.

Review the diff. Check that it did not change a shared component, a price, or an unrelated page. Run the project's checks and open a preview at desktop and mobile widths. Then follow your team's pull request and deployment process. A saved file is not a live update: for example, Vercel treats preview and production deployments as separate steps in its Git workflow. A protected branch can also require reviews and passing checks before a merge, as GitHub documents.

Route 2: Use a signed-in browser for a hosted editor

If your site lives in a builder, there may be no repository you can edit. A browser-capable agent can work through the same editor you use, within the account's permissions. ChatGPT Work can navigate signed-in sites, where that feature is available. Claude Cowork's built-in browser can read, click, and type in sites. These are product-specific browser features. An ordinary ChatGPT or Claude text chat can draft new copy, but it cannot click Publish in your account without a connected browser or tool.

Open the exact page in the editor. Sign in yourself when the tool asks. Do not paste passwords or one-time codes into the chat. Limit the task to one page and name the controls the agent must not touch. Ask it to stop at the preview or draft stage. Review the editor's pending change before you approve publication. Some sites block automated browsers, and some editor controls do not work reliably through browser automation. If the agent cannot make the change, take over or use the site's normal editor.

A browser session can change what the account can change. It does not create access to hidden source code, server settings, or a builder's unsupported features. For a layout change in a closed editor, the AI may need to work within that editor's blocks. It cannot promise a new layout system just because it can click the page.

Route 3: Use the site's API or CMS

This route works when the platform exposes the field you need and you have authorized credentials. For example, the WordPress REST API has an endpoint to update a page, and WordPress documents authentication for API requests. An agent can use an approved integration or script to update supported content. That does not mean the API can change every theme, plugin, or layout setting.

Give the tool only the access it needs. Store credentials in the tool's secure configuration, not in a prompt or source file. First test one draft or staging page. Read the API response and open the rendered page. If your platform has no suitable API, use its editor or ask a developer to make the code change.

Set the limits before the edit

Give the agent a narrow instruction: which site, which page, what text or design must change, and what must stay the same. Say whether it may save a draft, open a pull request, merge, or publish. Those are different permissions. Keep production deployment under a named person's control until the result passes review. Browser access and repository access can expose private data; grant only the access this task requires. Codex and Claude Code each document controls for file and command permissions.

Keep a way back

Before a repository edit, record the current commit and work on a branch. If a published code change is wrong, revert the commit and run the deployment process again. Do not assume that restoring a local file will change production. Before a browser or API edit, save the old copy and images. Check whether your CMS keeps revisions; WordPress lets you restore an earlier revision. If the platform has no revision history, your saved copy is the rollback plan.

Verify the result

• Open the changed page in preview, then on the public domain after publication.
• Check desktop and mobile layout, including text that wraps and images that crop.
• Test links, navigation, and forms. Use a safe test submission when a form sends real data.
• Check the page title, description, URL, and redirects if they changed.
• Confirm that unchanged pages and shared components still work.
• Record the deployed version and the steps to restore the previous one.

For a site published from a Figma file through Figment, edit that source file and republish it through the existing flow. Do not assume that Figment has a production AI editor that these tools can operate. The practical rule is the same for every platform: find the real source, give the agent limited access to it, and verify the live page yourself.