There is a version of this problem everyone knows how to handle. The engine states something false about you, you find the stale page it came from, you get it corrected, the answer changes within a cycle. Annoying, tractable, a known job.
This is the other version. The buyer asks about you and the engine mentions the outage. Or the lawsuit. Or the layoffs. Or a consistent theme in your reviews about support response times. You read it, you look for the error, and there is not one. It happened. The engine is describing it accurately, in a neutral tone, to somebody who was about to book a demo.
There is no page to correct. That changes the entire shape of the work, and most of the advice in this space does not account for it.
Why it keeps coming back years later
The reflex is to assume the engine is being unfair, dredging up something old and giving it more weight than a human would. That is not usually what is happening.
Look at what is actually on the record for most incidents. The event was covered thoroughly, because breakage is news. The resolution was covered thinly or not at all, because repair is not. Your status page updated and then rotated out. Your postmortem, if you wrote one, went to affected customers in an email nobody can cite. The lawsuit filing produced a dozen articles and the settlement produced none. Six months later the public record contains a well-documented problem and no documented ending.
The engine is not choosing to omit the resolution. It is summarizing a record that does not have one. It is being accurate about an incomplete story, which is a different failure and needs a different fix.
That is the reframe worth holding: the problem is usually not that the bad thing is on the record. It is that the ending is not.
Suppression is the move that does not work anymore
The old reputation playbook was built for a ranked list. Publish enough positive material, push the bad result to page two, and for most people it effectively stops existing.
An answer engine does not give you that. It is not ordering ten links, it is composing a claim, and it will happily compose a claim that reflects a thing it found on any of them. There is no page two to push something onto. Volume of unrelated positive content does not dilute a specific negative fact, because the two are not competing for the same slot. They are not even answering the same question.
There is also a failure mode specific to trying. A burst of favorable material appearing at once, in similar language, is the same pattern that makes coordinated review pushes and seeded threads backfire: it reads as what it is. And if a critical piece ever gets written about the campaign itself, you have handed the engine a new, more recent, more interesting source on exactly the topic you were trying to bury.
The instinct to make it go away is the instinct to fight the accuracy of the record. You will lose that, and you should.
Put the ending on the record
The move that works is unglamorous: complete the story publicly, in a form something can cite.
Publish the resolution as a durable, dated, specific page. Not a reassurance, an account. What happened, when, what changed as a result, what is different now, with dates on all of it. This is the same principle that makes any proof work in AI search, which is that specific and verifiable beats confident and vague. A page that says “we take reliability seriously” is not responsive to anything. A page that says what the failure was and what was rebuilt afterward, with a date, is a source an engine can use when the incident comes up. And it will come up regardless, so the only question is whether the record has your ending in it.
Then get the ending corroborated, because your own account of yourself is the weakest input in the pile and this is the case where that discount bites hardest. A company saying it fixed its own problem is exactly the claim a careful reader discounts most. The outlet that covered the incident is often willing to note the resolution if you actually give them one. An analyst who flagged the risk can update the note. A customer who stayed through it can say so somewhere findable. One credible outside sentence confirming the ending is worth more than a page of your own reassurance, and it is usually easier to get than people assume, because journalists and analysts are not hostile to a real update.
The recency dimension matters too. Retrieval engines and memory-default engines refresh on very different schedules, so expect the answer to change unevenly, and expect the version that lives in a model’s memory to lag well behind the corrected public record. That lag is not a sign the work failed.
When it is not a reputation problem at all
One case deserves separating out, because treating it as communications work wastes a quarter.
If the negative thing is a single event, the record-completion approach above is the whole job. If it is a theme, appearing consistently across independent reviews and threads and write-ups, then the engine has not dug up an incident. It has correctly summarized what your customers repeatedly say. Reviews in aggregate function as a corroborated source, and a consistent complaint is the most corroborated thing about you.
No amount of source-layer work fixes that, and attempting it is the closest thing to genuine dishonesty available in this discipline. What fixes it is fixing the thing, and then documenting the fix so the record shows a before and an after rather than a permanent present tense. The engine surfacing the theme did you an expensive favor: it turned your quietest churn reason into something you can no longer avoid looking at.
What I got wrong
I ran the suppression play once, and it did not work in a way that was instructive.
A client had a real incident in their past. Resolved properly, genuinely different afterwards, and still the first thing an engine reached for when asked about them. I treated it as a visibility imbalance, which is the framing my SEO instincts handed me. So we published: strong customer stories, a technical depth series, several genuinely good pieces. More positive material than the negative material by a wide margin.
The answer did not move. Not slightly.
The reason took me embarrassingly long to see. Everything we published was about how good the product was. Nothing we published was about the incident. So when the engine was answering a question that touched the incident, none of our material was responsive to it, and it went to the only sources that were. We had produced a large amount of content that was invisible to the exact query we built it for. I was drowning out a signal, which is a strategy that works on a ranked list and does nothing at all to a system that composes an answer.
What changed it was smaller than everything we had already done. The client published a plain, dated account of what had gone wrong and what they rebuilt afterwards, including specifics they were not comfortable putting in public. I asked the outlet that covered the original story whether they wanted the follow-up, and they ran a short update. Within a refresh cycle, the engines that had been mentioning the incident bare started mentioning it with the resolution attached.
The incident never disappeared, and I stopped trying to make it. It stopped being the whole story, which was always the achievable outcome, and which is what a buyer actually needs in order to keep going.
The short version
You cannot correct a true thing, and you should not try to bury it. You can make sure the record is complete.
Publish the ending, dated and specific. Get one credible outsider to confirm it. Expect the engines to update unevenly and check on a schedule rather than reacting to a single query, because a single check on a non-deterministic system is a coin flip. And if the negative thing is a theme rather than an event, stop treating it as a marketing problem, because it is telling you something accurate.
If you want to find out what the engines are currently saying about your worst moment and get the ending onto the record, that is the work we do and the method we use.