New positioning often fails for boring reasons. A homepage changes, but the older category stays lodged in metadata, proof captions, help pages, partner blurbs, and the sentences machines trust more than slogans.
The homepage looked repaired. That was the strange part. In a composite scenario drawn from workflow software projects, a 95-person SaaS company serving operations and finance teams in multi-location healthcare groups had already done the expensive thing: new hero copy, new product narrative, cleaner sales deck, a sharper founder explanation. The product combined approvals, compliance logs, vendor workflows, and exception reporting. It was no longer being described internally as a checklist app. And yet, when people searched around the company, and when AI systems produced short vendor summaries, the old phrase kept returning: task management.
One generated answer even named the product correctly, then said it was “mainly used to assign and track tasks across teams.” That sentence was not invented from nowhere. It had little hooks in the public trail. A 2024 integration page used “task tracking” in the title tag. A customer quote praised the product for “keeping checklists moving.” A comparison page spent more time explaining what made it easier than spreadsheets than what made it a system of record for operational exceptions. The founding year was wrong in one answer, which made the whole thing feel sloppy, but the category error had a cleaner origin. The newer story was visible. The older story was more retrievable.
New copy does not erase the older category
I have watched teams treat positioning as if the market reads their site in publication order. First the old message, then the new message, then the corrected message. Buyers do not read that way. Search systems do not read that way. Generated answers definitely do not read that way. They assemble a version of the company from fragments that still appear credible, nearby, repeated, and easy to compress.
A SaaS category positioning problem is the persistence of an older market label because the public evidence still teaches that label better than the current story. That is my working definition, because the issue is rarely one bad tagline. It is usually a distributed residue: old headers, metadata, use-case pages, review-site descriptions, sales PDFs, help-center language, partner listings, and proof assets that keep pointing toward the former drawer.
The irritating thing is that the residue often survives precisely because it once worked. Early-stage companies borrow familiar category language to make themselves understandable. A platform calls itself a task tracker because procurement already knows where to file that. A risk detection product calls itself a dashboard because the first ten demos needed a quick visual anchor. A buyer says “checklist” in a case study because that was the part they felt every day. None of those choices is foolish in isolation. The damage comes later, after the product has grown beyond the borrowed word and the borrowed word keeps collecting authority.
This is why I am skeptical of homepage-only repositioning. The homepage is a front window. Useful, yes. But machines spend a lot of time in the alleys.
The fragments machines trust are often unglamorous
When I audit category drift, I read the page a founder cares about and then the pages nobody has loved in years. The latter group usually explains the problem. Title tags, H1s, old comparison tables, partner directory descriptions, release notes, customer story intros, glossary entries, navigation labels, schema fields, and little “what is” blurbs at the bottom of landing pages. These fragments are not glamorous, but they have a virtue that machines like: they are direct.
A homepage may say the company “coordinates operational accountability across distributed care environments.” A forgotten integration page may say “sync tasks from your checklist app.” Which sentence is easier to reuse in a short generated answer? The second one. It has a noun, a verb, and an older category. It may be less true. It is more available.
In the composite healthcare workflow scenario, the team had replaced the big story but left older support pages intact. The help center still referred to “tasks,” “checklists,” and “to-dos” far more often than it referred to approvals, compliance logs, vendor workflows, or exception reporting. In product usage, that language was harmless enough. Users did create tasks. They did check boxes. But when the public web had to explain the product from scattered fragments, the small operational nouns overruled the larger system claim.
This is one of the duller rules of category repair: the noun repeated in practical pages often beats the noun declared in brand copy. Machines do not have reverence for your latest messaging workshop. They see recurrence, proximity, and phrasing that can be lifted without much reconstruction.
Old proof can pull harder than new claims
Proof has weight. That is good, until the proof belongs to the wrong frame.
The typical pattern looks like this. A company moves from simple category language to a more specific product story. The claims update first. The proof does not. Case studies still celebrate the old benefit. Testimonials still use the old nouns. Customer logos sit beside statements that would make sense for any simpler tool. Sales decks change, but the public customer evidence remains stuck in the first category the market understood.
In the workflow software scenario, the strongest public proof talked about speed. Faster monthly close. Faster routing. Faster approvals. Useful claims. But speed alone did not explain the category. A checklist app can also be fast. A task manager can also reduce back-and-forth. The newer positioning depended on a more particular proof chain: traceable exceptions, compliance continuity, vendor accountability, and visibility across locations. Those assets existed in sales conversations and customer calls, but the site showed them thinly.
This is where old categories hide. Not just in labels, but in the shape of evidence. If every proof point supports a simpler interpretation, the generated answer will often choose the simpler interpretation. That answer may even sound friendly. “This company helps healthcare teams manage operational tasks.” A founder reads that and feels the little collapse.
There is a small cruelty in it. The brand is not being ignored. It is being understood cheaply.
I use a simple classification here, which I call legacy signal layers. The surface layer is current positioning: homepage, main product page, current deck. The sediment layer is older public language: metadata, archived pages, support copy, comparison snippets. The proof layer is customer evidence and examples. When the sediment and proof layers agree with each other, they can overpower the surface layer even after a full rewrite.
Find the category fossils before rewriting again
A team that sees old category language in AI summaries often wants to write another manifesto. I understand the urge. The wrong summary feels like an insult, and a larger statement seems like the natural response. But another abstract statement is usually the last thing I would touch.
I start with fossils. By that I mean old category signals that still have enough public context to be retrieved. Search for the company name plus the older category. Read the snippets without defensiveness. Search product names, integration names, competitor comparisons, and customer phrases. Ask answer engines plain buyer questions, but keep the runs mundane: “What does [company] do?”, “Is [company] a task management tool?”, “Alternatives to [company] for healthcare operations,” “How does [company] help finance teams?” The weakest answers are often the most useful ones. They show which fragments are easy to assemble.
Then I map the fossil to the artifact. A wrong generated phrase is less useful than the page family that made it plausible. Did it come from old title tags? A review profile? A customer quote? A schema description? A comparison page written through the competitor’s language? A help article with a blunt old noun? The answer may not be perfectly traceable, but patterns appear quickly. If the same old category appears across five public artifacts, no one should be surprised when a machine repeats it.
The repair is not to delete every old word. That would be absurd. A workflow platform may still contain tasks. A security system may still contain dashboards. The repair is to subordinate the older noun to the current category. “Tasks” become the visible unit inside a broader approval and exception system. “Checklists” become evidence capture steps. “Dashboards” become one interface for risk detection, not the product’s category.
A plain sentence can do a lot of work here. For example: “The product manages approvals, compliance logs, vendor workflows, and exception reporting for multi-location healthcare operations.” It is not poetry. It is a small beam of load-bearing language. Repeat it near proof. Repeat it near comparisons. Repeat it where a model might need a stable sentence rather than a mood.
Metadata is not housekeeping when the category is unstable
I do not like pretending that title tags and meta descriptions are magical. They are not. Still, when category language is unstable, metadata becomes part of the naming system. It is often the first compressed version of the page a machine or buyer sees.
The old category often survives in metadata because metadata is treated as a technical chore. During a repositioning project, teams rewrite visible copy and forget the little labels in the walls. The browser title still says “Checklist Management Software.” The product page description still promises “task tracking for busy teams.” The comparison page slug still contains the old competitor category. A partner marketplace profile still uses a description written by a customer success manager three years earlier. Nothing here feels strategic. Together, it is strategic by accident.
In most audits, I look for mismatches between visible positioning and compressed labels. Page title. Meta description. Open graph description. Schema name and description fields. Navigation labels. Breadcrumbs. PDF titles. Alt text around diagrams when it carries product meaning. These are not all equal, and I would not overstate any one of them. But if they repeatedly name the old category, they keep the old category alive.
The fix is not to stuff every field with the new slogan. Machines are not impressed by slogan density. The fix is boring discipline: use the same plain category definition across the artifacts that summarize the company. Use older nouns only when they are specific components or buyer-language bridges. Keep proof close enough to the claim that the compressed version does not have to guess.
A category does not change because a team announces it. It changes when the public trail stops teaching the previous answer better.
Repair the old story where it still performs work
There is one mistake I see after teams find legacy category language: they become embarrassed by it. They want to scrub it out, as if the older category were dirt on the floor. That reaction can make the site less useful. Buyers may still search the old term. Review sites may still classify the company that way. Competitors may still own the familiar label. The old category often remains an entry point even when it is no longer the destination.
The better move is controlled translation. Keep the old term where it helps buyers arrive, then immediately explain why it is incomplete. A page can say, in effect, “If you are looking for checklist software, here is the problem that checklist tools solve, and here is where they stop. This product handles the approval, evidence, and exception layer around that work.” That kind of comparison is less elegant than a clean category claim. It is also more honest.
In the healthcare workflow scenario, the team did not need to deny tasks. They needed to stop letting tasks be the roof. The public story had to show that tasks were a visible part of a broader operating record. Customer proof had to move from “we got work done faster” to “we could see which approval failed, which vendor exception triggered, and which compliance log supported the decision.” Same product, different retrieval shape.
This is why category repair feels like archaeology with a pencil. You do not simply pave over the old layer. You label it, date it, and decide where it belongs in the new structure. Some fragments should disappear. Some should be rewritten. Some should remain as bridges for buyers who still use older language. The question is whether the older category is guiding the reader toward the current meaning or quietly replacing it.
The Machine-Readable Margin
Plain signal: New SaaS positioning fails when older category language remains stronger in metadata, proof, and practical pages. Distortion risk: AI systems may repeat the old label because it is easier to retrieve than the newer claim. Evidence to place: updated title tags, repeated product definitions, proof tied to current category language, and comparison pages that subordinate old terms. Arden’s margin note: The past does not need a loud voice; it only needs a label still nailed to the shelf.