How to change a fact everywhere on your website with Claude Code

To change a fact everywhere on a website with Claude Code, first have it find every copy of the old value without changing anything, decide the exceptions yourself, then let it make the change with a rerunnable script on a copy of the site, and prove it worked by counting: the old value should appear zero times outside your exceptions, and running the script a second time should change nothing. The hard part is rarely the replacing. It's finding all the places a fact hides.

A phone number, for example, may be in the footer, the contact page, a click-to-call link, the structured data that search engines read, an old blog post, a PDF, and the business listing on a map. Some of those are in your code. Some are in a database. Some are on other websites and need a person to log in. This guide covers all three.

Where a fact hides

Give Claude Code this list as part of the job, so the inventory covers more than visible text.

Step 1: write a short change brief

Before the first prompt, write down what is changing. A good brief takes five minutes and prevents most mistakes.

• Old value and every format you know of. For a phone number: with brackets, with dashes, with dots, with the country code, and the version inside tel: links.
• New value, in each of those formats.
• Exceptions. Pages that should keep the old value, such as a dated press release or a quote.
• Who approves the inventory and the final diff.

Step 2: run a read-only inventory

Example prompt: Use plan mode. Search the whole repository, including templates, structured data, config and content files, for the old phone number in any format, including tel: links. Don't change anything. Give me a table: file, line, the exact text found, and whether it is visible text, a link, structured data or metadata. Also list images and PDFs whose names or alt text suggest they might contain the number.

Plan mode lets Claude Code read and propose without editing your files. Read the table yourself. Look for formats you didn't think of and for places that surprise you. If the site runs on a CMS, the database needs its own inventory; on WordPress, WP-CLI can search it.

Check: spot-check three pages in a browser and confirm each occurrence you can see is in the table. A person reviews: the full list, marking exceptions.

Step 3: change the source, not the output

Many sites are built: templates and content files produce the final pages. If you change the final pages, the next build overwrites them. On eseospace.com, a publishing step once regenerated every post from its source files and deleted edits that existed only in the built copy. Tell Claude Code which folders are source and which are output, and put that rule in your CLAUDE.md.

Often the best fix is structural: put the fact in one shared setting or include, and have every template read it. Next time the number changes, you edit one line.

Example prompt: The phone number appears in 14 templates. Propose moving it into one shared setting that all templates and the structured data read. Show me the plan before editing.

Step 4: replace with a rerunnable script, on a copy

Work on a branch, with a backup if a database is involved. Our guide to git basics for Claude Code explains branches and reverting for non-developers, and for WordPress sites our WordPress backups guide covers taking a restorable backup first.

Ask for a script rather than hundreds of individual edits. A script can be read, rerun and corrected. The house rule we follow on our own site: run every bulk edit on a copy first, then twice on the real files, and the second run must change nothing. If the second run changes something, the script is matching text it shouldn't.

Example prompt: Write a script that replaces each old format with the matching new format in the source files listed in inventory.md, skipping the exceptions. Print a count of replacements per file. Run it on a copy of the repository and show me the counts.

For WordPress databases, Claude Code can run WP-CLI's wp search-replace with --dry-run, which WP-CLI's documentation describes as: "Run the entire search/replace operation and show report, but don't save changes to the database." The command also "intelligently handles PHP serialized data". Replacing text in a raw database export can break serialized settings when the length of the text changes. Run it on a staging copy first. Our guide to Claude Code on WordPress covers working with a local copy.

Step 5: watch for the classic replace bugs

• Dollar signs in replacement text. In JavaScript's replace, "$1" in the replacement means the first matched group. On eseospace.com this garbled "$1,200". If prices can appear in the new text, ask Claude Code to use a function replacement, then search the output for every price you expect.
• Partial matches. Replacing a year or a short name everywhere hits dates, URLs and other words. Match whole values, and review anything that matched inside a URL.
• Case and spacing variants. Brand names written in capitals, with a line break, or with a non-breaking space are missed by a strict search.
• Silent skips. A script that reports success but processes nothing. Read the counts every time.
• Two sessions at once. If another session regenerates pages while this one edits, edits can vanish. Check git history for changes you didn't make before deploying.

Step 6: prove it worked

1. Search again for every old format. The only hits should be the exceptions.
2. Count the new value. The number should match the inventory, minus exceptions.
3. Run the script a second time. It should report zero changes.
4. Build the site and confirm the build passes.
5. Test structured data on a sample of page types with Google's Rich Results Test, and confirm the new value appears in it. Google's structured data policies say "Don't mark up content that is not visible to readers of the page", so the value in the markup should match the value on the page.
6. Open a few pages in a browser, on a phone too, and tap the click-to-call link.

Example prompt: Search the built site for all old formats and report every hit. Then list every page whose structured data phone value differs from the phone number shown on that page.

Our guide to adding or fixing structured data with Claude Code goes deeper on testing markup at scale.

Step 7: review the diff and deploy

A person reads the diff before anything ships. For a fact change, the diff should be boring: the same small change repeated, with nothing else touched. If you see layout, code or unrelated text changes, stop and ask why. Our guide to reviewing a diff when you aren't a developer shows what to look for.

After the deploy, check the live site against the built output. A CDN can serve a stale copy for a while, so a missing change on the live site doesn't always mean the change failed. Check the build output and git log first.

Step 8: update what lives off your site

Claude Code can't change your map listing, directory profiles or ad accounts unless you've connected them, and those usually deserve a person's attention anyway. Ask it for a checklist from the inventory, then hand it to whoever owns those accounts. Until they match, some people and systems will see the old fact.

Conclusion

Changing a fact everywhere is a small job that fails in big ways when one copy is missed or a script overreaches. With Claude Code, the reliable route is an inventory first, a person's decisions on exceptions, a rerunnable script on a copy, and proof by counting. Our article on Claude Code for technical SEO covers the related parity checks. If you'd rather hand ongoing changes like this to a team, see our website maintenance plans. More guides are in our Claude Code Guide.

Frequently asked questions