What Do I Do When I Publish Something Wrong?

What do you do when you publish something wrong?

Fix it fast, say what changed, and leave the page where it is. The instinct is to delete quietly and hope nobody noticed. That instinct is wrong on every axis: it breaks links, it hides the correction from the people who read the error, and it teaches you nothing about why it happened.

I write a lot. Across more than 350 published articles on answer engines, schema, and E-E-A-T, the arithmetic is unforgiving. Volume without a correction process is just a larger surface for mistakes to live on undisturbed.

So this is the process I actually use, including the part where I decide whether something is worth correcting at all, which is a real judgement rather than a reflex.

How did I learn this the hard way?

A post on this site once described a product launch that had not happened, with invented figures attributed to real companies. It read well. It was confident. It was also fiction, and it stayed up long enough to be found.

I am not going to dress that up. Nobody misled me and there was no ambiguous source I misread. The piece asserted specifics that did not exist because it was written to sound substantiated rather than to be substantiated, and the difference between those two things is the entire job.

What made it worse was the attribution. Inventing a statistic is bad. Attributing an invented statistic to a real company is a different category of bad, because you have put words in someone else's mouth in public. That is the part I still think about.

Everything I do now on verification came out of that. Every checkable sentence has to trace to a primary source I actually opened, and a sentence that cannot be traced gets cut rather than softened. It is slower. It is worth it, and I have written about the discipline itself in why I verify every fact before publishing.

Should you delete the post or fix it?

Fix it, almost always. Deleting a page removes the URL, which breaks every link pointing at it and every reference someone made to it. The error was public. The disappearance of the error should not be.

My default sequence is to unpublish rather than delete when something needs to come down immediately. Unpublishing reverts a page to draft and keeps the content, which means I can correct it properly and put it back rather than losing the work along with the mistake. Deleting is irreversible and it destroys the record of what was said.

There are cases for full removal, and I would be dishonest to pretend otherwise. If a page is wrong in a way that could harm someone, or if it names a person or company in a claim you cannot support, take it down first and work out the rest afterwards. Speed matters more than tidiness in that specific case.

But the ordinary case is not that. The ordinary case is a wrong figure, an outdated capability, a version number that moved. Those get corrected in place, with a note, and the page carries on doing its job.

How fast does a correction need to happen?

Immediately for anything that puts words in someone else's mouth, and within a day or two for everything else. The clock matters more than the wording, because a wrong sentence keeps working while you draft the perfect correction.

I split it into two tiers and I think most people should. Tier one is anything attributed to a named person or company, anything about money, and anything a reader might act on in a way that costs them. That gets fixed the hour I learn about it, even if the fix is temporary and inelegant.

Tier two is everything else. A misdescribed feature, a date that slipped, a claim that was true when written and is not now. Those can wait for a proper pass, and batching them is reasonable as long as batching does not become never.

The failure mode to avoid is treating the correction as a writing project. I have caught myself starting to restructure a whole article because I was fixing one sentence in it. Fix the sentence. Ship the fix. Restructure later if it deserves it.

What does a correction actually need to say?

What was wrong, what is right, and when it changed. Three facts, plainly, without defensiveness and without a paragraph explaining how the mistake was understandable.

The temptation is to soften. A wrong statistic becomes an earlier estimate. An invented event becomes an anticipated development. That is not correcting, that is rewriting history with better grammar, and readers can smell it. If the original sentence was false, the correction should say the original sentence was false.

Where you put it depends on severity. For tier one I put a short note at the top of the article, because the people most affected are the ones who read it and believed it. For tier two, a dated line at the bottom is proportionate and does not make a small fix look like a scandal.

One thing I do not do is apologise at length. A correction is an act of service, not an act of contrition, and a long apology makes the page about the writer rather than about the reader who needs the right information. Say what changed. Move on.

Who do you tell, and who do you not?

Tell anyone your error touched directly, and resist the urge to announce it to everyone else. Those are different obligations and conflating them usually means doing the easy one instead of the hard one.

If you misattributed something to a named company, that company is the person you owe a message. Not a public post about your commitment to accuracy. A direct note saying what you published, that it was wrong, and what you have done about it. That is uncomfortable, which is roughly how you know it is the right call.

Clients are the second group. If I published something a client might have repeated, or something that affects work I did for them, they hear it from me before they find it. Nobody enjoys that conversation and it has never once gone as badly as I expected.

The broad audience mostly does not need a separate announcement. The corrected page is the announcement. Turning every fix into a public post about the fix is a form of performance, and after a while it reads as reputation management rather than accuracy.

How do you stop the same mistake twice?

Change the process, not your intentions. Every correction I have made that led to a real improvement ended with a rule I could apply mechanically. Every one that ended with resolving to be more careful changed nothing.

After the fabricated launch, the rule was specific: no checkable sentence prints unless it traces to a primary source opened during that piece of work, and a sentence whose source fails gets deleted rather than softened. A rule you can check is a rule that survives a tired afternoon. A good intention is not.

The second rule that came out of it was about attribution in particular. Naming a company in a claim raises the evidence bar, because the cost of being wrong is not mine alone to carry. If I cannot open the page where that company said the thing, the company's name does not appear next to the claim.

The third is a habit rather than a rule, and it is the one I would recommend to anyone publishing at volume. Write down what you cut and why, next to the piece. Reading back a list of things you almost published is a much better teacher than remembering the ones you did. I got this wrong for a while, which I covered in what I got wrong about publishing at volume.

Does this change now that AI engines quote you?

Yes, and not in a comfortable direction. A wrong sentence used to reach the people who read your page. Now it can be lifted into an answer and repeated to people who never visit you at all, which means the reach of an error is no longer something you can see.

I want to be careful here, because I do not know how quickly any given engine re-reads a corrected page, and I have not verified that for any of them. So I treat the refresh time as unknown rather than assuming it is fast, and I plan as if a corrected page may continue to be quoted in its old form for some time.

The practical consequence is that prevention has become worth more relative to correction than it used to be. A correction you publish is a correction you control. A quotation in somebody else's answer is not, and no amount of promptness on your side guarantees it updates.

The mirror image of this problem is when an engine states something wrong about your business that you never published at all, which is a different and more frustrating job. I have written about that separately in what to do when ChatGPT has wrong facts about your business.

What should you do before you need this?

Decide now where corrections go, because deciding during an incident guarantees you choose badly. Pick the format, pick the placement rules for the two tiers, and write them down somewhere you will find them under pressure.

Then do one audit pass on your riskiest content. Not everything, just the pages that name a company, quote a figure, or describe a price. Those three categories hold most of the exposure on any business blog, and reading twenty of them with fresh eyes takes an afternoon.

If you find something wrong in that pass, good. That is the pass working. The uncomfortable truth about publishing regularly is that the question is never whether you have published something wrong, only whether you have found it yet.

What should you do next?

Open the last piece you published and pick out every sentence a stranger could check. For each one, ask whether you could produce the source right now, this minute, without searching for it again. The sentences where the answer is no are the ones that will eventually need a correction.

Then write your correction policy in five lines and put it where you write. What counts as tier one, what counts as tier two, where the note goes, who gets told, and the rule that a failed source means deletion rather than softening. That is the whole thing, and having it written down in advance is the difference between a correction and a scramble.

If you publish a lot and you want a second pair of eyes on how your process handles being wrong, reach out. It is an unglamorous conversation and it is the one I would have wanted to have earlier.