What to Do When a Live Website Change Goes Wrong

You publish a change.

Then the client texts.

“The form isn’t working.”

Or:

“Mobile looks broken.”

In that moment, you don’t need a theory.

You need a playbook.

If you want the full system behind this, start here:

edit client websites without developers

First: Don’t Diagnose Yet

Your first job is not to find the root cause.

Your first job is to restore the money path.

Restore the Money Path Before Anything Else

If any of these are broken, you roll back first:

• Primary CTA route
• Lead form submission
• Booking step
• Checkout step

You can diagnose after the site is stable.

Step 1: Roll Back First (If a Trigger Hits)

Roll back is not admitting failure.

Roll back is keeping the blast radius small.

If rollback is hard, you will ship less.

If rollback is easy, you will ship more.

If you need the rollback workflow, use:

rollback website changes

The Rollback Triggers Checklist

If any trigger hits, roll back first:

• The primary form does not submit
• The confirmation step does not appear
• The primary CTA goes to the wrong destination
• Mobile layout collapses on key devices
• A key event stops firing
• The conversion record stops showing up
• The page becomes dramatically slower on mobile

Then investigate.

Not before.

Step 2: Verify the Basics (In 10 Minutes)

After rollback (or after the fix), verify the basics.

Keep it tight.

Keep it testable.

Mobile, Links, Forms, Tracking

Run this routine:

• Check the page at 375px and 414px
• Tap the primary CTA and complete the next step once
• Submit the primary form once
• Confirm the key event fires
• Confirm the conversion record appears

If you want the safe publish workflow that prevents most incidents, read:

How Agencies Make Website Changes Safely on Live Client Sites

If you want the guardrails that prevent the most common breakage patterns, start here:

prevent breaking client websites

Step 3: Confirm What Changed (So You Don’t Chase Ghosts)

Incidents feel chaotic when you don’t have a record.

So you rely on memory.

And memory is unreliable under stress.

The fix is a minimum audit trail.

If you don’t have one, start here:

track and audit website changes across client sites

What Proof to Save

Save proof that is fast to capture:

• Before screenshot (desktop + mobile)
• After screenshot (desktop + mobile)
• Publish time
• One-sentence change statement
• What was verified (mobile / links / form / key event)

Step 4: Ship the Smaller Fix

After the site is stable, re-ship the fix.

But do it smaller.

Smaller changes are easier to verify.

They are also easier to undo.

One Change, One Goal, One Definition of Done

Write the change like this:

• One page
• One goal
• One thing you are changing

Then preview.

Then verify.

Then publish.

How to Talk to the Client (Without Panic or Blame)

Clients don’t need drama.

They need clarity.

They need confidence you’re in control.

A Simple Update Template

Use a message like this:

We identified an issue after the change shipped.
We reverted to the last known-good version to restore the conversion path.
Next, we’ll re-ship a smaller version of the change after preview and verification.
I’ll update you again once the new version is live and verified.

Getting Started: Run a Rollback Drill This Week

The best time to learn rollback is not during an incident.

It’s during a calm week.

Practice on a Low-Risk Page

Pick a page with traffic.

But low business risk.

Then practice the routine.