Rewrite the page after you know what people came for

The rewrite that starts in the wrong place

A marketing lead tells me the product page needs rewriting. I ask what is wrong with it. The answer is usually some combination of it is too long, it is not clear enough, and it does not really say what we do now.

All of that might be true. None of it came from a visitor. It came from somebody who has read that page four hundred times, knows the product completely, and is bored of it. That is the least representative reader the page has.

So the rewrite happens, it is shorter and clearer, everybody feels better, and the thing the page was actually failing at is untouched because nobody ever established what that was.

Two weeks changes what you rewrite

The proposal I make is always the same and it feels like a delay: before rewriting anything, spend two weeks finding out what people are trying to get from that page.

It is not a delay in practice, because the listening is mostly asking two people some questions and reading things that already exist. It takes hours spread across two weeks rather than two weeks of effort.

What it changes is more than tone. In my experience it usually changes which page gets rewritten. The product page turns out to be broadly fine and the pricing page is where people are actually stuck, or the integrations page is generating three questions a week that nothing answers. The rewrite you were going to do was not wrong, it was aimed at the wrong page.

That is the return on listening first. Not a better version of the planned work. A different decision about what the work should be.

The person who wants the rewrite has read the page four hundred times. That is the least representative reader it has.

What listening actually means here

It does not mean user research in the formal sense, which is valuable and slow and needs a budget. It means reading and asking, using channels that already exist.

Sales calls, where a question appears at the same point in the conversation every time. Support threads, where somebody has typed the same clarification forty times. Site search, if you have it, which is people telling you in writing what they came for and could not find. Pre sales email, which is the highest intent text in your company and the least examined. And onboarding, where somebody asks what a thing does after they have already paid, which is a fairly direct statement about the site.

None of that requires anything to be built and none of it requires permission. The reason it does not happen is that nobody owns the route from those channels back to the pages, not that the information is hard to get.

Five things listening changes

It is worth being specific about what moves, because listen to your customers is advice nobody can act on.

Page priority. Which page you work on next, and this is the biggest one. Almost every time I have run this, the ranking of pages by how much they are costing changes.

Internal links. Questions asked on page A that are answered on page B tell you exactly which link is missing, and where. That is a five minute fix that no amount of thinking about information architecture would have surfaced.

FAQs. Which questions genuinely belong in one, which is far fewer than most sites have. An FAQ entry earns its place when the question is real and the answer does not fit naturally in the main flow of the page.

Objections. The reasons people hesitate, in their words rather than in the words your positioning uses. These almost never appear in search data because nobody searches for a reason not to buy.

Content gaps. The pages that should exist and do not, which is the category everybody expects from this exercise and is actually the smallest of the five.

The signal that tells you the most

One pattern is worth more than the rest and it is the one people dismiss: somebody asking a question on a page that already answers it.

The instinct is to treat that as noise. Somebody did not read. But when it happens repeatedly, on the same page, with the same question, it is the clearest possible evidence about that page. The answer is present and not findable, or present and not believed.

Those two have different fixes and both are cheap. Not findable is usually a heading that names a topic instead of answering a question, and it takes five minutes to change. Not believed is usually vagueness, and the fix is stating something specific enough that it could be wrong.

Neither fix is a rewrite. Both are more valuable than one. And you would never find either by thinking about the page, because from the inside the answer is obviously there.

There is a related signal worth watching for, which is a question asked on a page that is one click away from the answer. That is not a content problem at all, it is a linking problem, and it is the cheapest fix available on any website. It also almost never shows up in analytics, because the person did not navigate anywhere, they gave up and asked.

The objection about representativeness

The pushback I get is worth answering because it is the reasonable version of a real concern.

It goes: the people who ask questions are not representative. They are the ones who did not read carefully, or the ones who would have bought anyway. Optimising for them means optimising for a self selected minority rather than for the silent majority who converted fine.

The true part is that askers are self selected. The part that does not follow is that this makes them less useful. Being engaged enough to ask is a qualification. Somebody who emails about your identity provider is further along than any anonymous session, and their question is about the thing that will decide whether they buy.

There is also a version of the concern that is genuinely right, and it is worth holding onto. Fixing one loud person's problem is not the same as fixing a common one. That is what sorting by both frequency and stage in the sales cycle is for. Frequency tells you how widely a question is held. Where it appears in the cycle tells you what it costs to leave unanswered. Neither is sufficient alone, and volume alone is the one most teams default to.

A framework for doing it

Four steps, and the last one is the one that gets skipped, which is why most teams do this once and conclude it was interesting rather than useful.

Listen for two weeks without changing anything. Resist fixing things as you find them, because early fixes contaminate what you are trying to observe and you will not know afterwards which finding was real.

Decide, and write down the expectation. Pick the two or three things you will act on and, for each one, write what should stop happening. Not a metric. Sales stops sending the workaround link. Nobody asks about seat counts on discovery calls.

Change one thing per finding. Not a rewrite. The smallest edit that could plausibly cause the expectation, because if you change six things at once you learn nothing about which one worked.

Listen again to the same channel. Six weeks later, ask the same person the same question. Did it stop. This is the step that makes it a loop rather than an exercise, and it is the reason to have written the expectation down.

The whole cycle is about eight weeks and most of it is waiting.

Why the fourth step is the one that gets skipped

Almost every team does the first three. Almost none does the fourth, and I include our own past client work in that.

The reason is not laziness. It is that by week eight the team has moved on to the next thing, and going back to check on a change that already shipped feels like looking backwards rather than working.

But the check is where the learning is. Without it, you have a list of changes you believe helped, which is the same epistemic position you were in before the exercise. With it, you find out that two of the three worked and one did not, and the one that did not tells you something about that page that no amount of listening would have.

The mechanism that makes it happen is unglamorous: a calendar reminder at six weeks, with the expectation written in the invitation so the person opening it does not have to remember what they were checking.

Where teams get this wrong

Listening only to the loudest channel. Support tickets skew toward existing customers with problems. Sales calls skew toward people already engaged. Use at least two channels, because each one has a shape.

Collecting into a document nobody owns. A list of questions in a shared file, with no route to a page and no person responsible, is a record of the problem rather than progress on it.

Treating volume as priority. The question asked once by the largest prospect can be worth more than the one asked twenty times by browsers. Frequency tells you how widely something is held. It does not tell you what it costs.

Rewriting instead of editing. The finding is usually specific and the response is usually a heading, a link, or a sentence. A rewrite is a way of not having to decide which of those it was.

Doing it once. Questions change as the product changes. This is a rhythm, not a project, and the version that works is somebody spending an hour a month rather than a team spending a week a year.

What good looks like

A team doing this well has a short list of live questions the site does not answer well, visible to sales and marketing together, with a state against each.

New page work arrives with a reason attached rather than as a calendar item. Sales stops explaining the same thing and starts linking to it. And when somebody proposes a rewrite, the first question in the room is what people are currently coming to that page for, which is a different meeting from the one that starts with opinions about the copy.

The tell is the direction of information. In most companies the content plan flows outward from marketing. Here a meaningful share of it flows inward from people who spoke to buyers this month.

Where Creobot fits

Creobot is the conversation engine we are building and it is in private development, so this is the reasoning rather than a description of something shipped.

The premise is exactly the gap above. Every company already has these channels and none of them connects to the site. A site assistant that answers from your pages is useful, and the more valuable output is the questions it could not answer, because that is visitor intent, in the visitor's own words, on a specific page, with no interpretation needed.

That is the same artifact the two week manual exercise produces, arriving continuously instead of when somebody schedules a conversation. The design commitment that makes it work is treating a failed answer as a first class output rather than as something to minimise, because an assistant optimised for answer rate has an incentive to invent one.

Creogen is the other end, where a recorded question becomes a change to a named page with an expectation attached and a check at six weeks. That is the fourth step, which is the step humans skip, and it is the part I most want a machine to hold.

None of it is needed to start. The two week version costs a few hours and will tell you whether the exercise is worth anything for your company, which is worth knowing before anybody builds or buys a tool for it.