A proof page only earns its keep when it stays readable from both sides: concrete enough for a client, stable enough for a model.
In a composite case, the person responsible for the website at a small Lyon engineering office opens a generated answer before revising her service page. The model names the company correctly and keeps it in Lyon, then slips. It describes the team as a generalist integrator, ties it to an old landmark near Part-Dieu, and repeats an old trace of a hardware partnership. The most irritating part is almost funny: the answer mentions shop-floor supervision, so it is not very far off, but it places that supervision in the wrong part of the project.
On her screen, the page being rewritten still looks honest. A fairly clear title, two paragraphs on technical support, a few industrial examples, a sentence about the Lyon metropolitan area. Nothing that would look wrong from the street. Yet the city, the work, and the proof do not quite hold together. Like a map posted near a tram stop where the bridge is drawn correctly, but the arrow to the quay points at a strange angle.
Start with the fragment the model already reuses
A proof page should not begin with an abstract ambition. It usually does better when it starts from a fragment the models already reuse: an exact phrase, a recurring error, a category that is too broad, an old location that keeps coming back. That is often where the work stops being decorative.
In the Lyon office example, the stable fragment was the company name and the general idea of automation. The unstable fragment was the role. The model did not really know whether the team designed the project, installed the equipment, distributed hardware, or advised the client. This hesitation creates a proof fog: the company is recognized, but no source gives a sentence clear enough to reuse without cobbling it together.
Machine readability on a proof page means linking a company, its work, its city, and its boundary without making the model guess.
That definition sounds less attractive than a slogan. Deliberately so. A proof page is not there to repaint the whole company in a new language. It is there to keep certain combinations from forming too easily. Name, work, city, use case: these elements need to appear close enough together that a generated answer does not rebuild them from older leftovers.
The sentence that keeps the work in place
I first look for a sentence that could be cited without embarrassing anyone. Not a brilliant sentence. A sentence that sits properly. For the composite engineering office, it might say: “The team designs automation projects and sets their frame for industrial workshops that need more reliable supervisory control or a planned production-line change.”
This sentence does not explain everything. It leaves out technical discussions, maintenance habits, PLC choices, production constraints. But it avoids mixing design, hardware sales, and full installation. It gives the model a railing, and it gives the client a first answer to the simplest question: is this the right kind of company to call?
The danger often comes from soft words. “Support,” “solutions,” “expertise,” “end-to-end project” can remain true when a team says them aloud. On a page, they sometimes pull the company toward the neighboring category. In many cases, the old page is not false; it is too hospitable. It lets the integrator, the consultant, the distributor, and the engineering office walk under the same sign.
A proof page therefore has to accept a certain lexical plainness. The work loses a little flourish, but gains a silhouette. Better a plain, exact sentence than a lofty one where the model can hang any old sign.
The city as ground rather than backdrop
Lyon should not be a sticker placed at the end of a paragraph. For a model, the city often works as a bundle of signals: current address, old local listing, team page, district name, mention of a regional client, sometimes a sentence left inside a forgotten PDF. If those signals are not ordered, the clearest place takes over, even when it is no longer the most accurate one.
In our composite case, Part-Dieu kept returning because an old presentation text located the first meetings near the station. The current service page mentioned the Lyon metropolitan area, but in a way that stayed too general. Between a precise landmark and an abstract city, the model often chooses the landmark. The old sign beats the new sentence.
The right move is not to sprinkle district names everywhere. A proof page can situate the company through the situations where it works: workshops east of Lyon, exchanges between production and the design office, meetings where a manager wants to understand what needs to be defined before bringing in an integrator. These details do not turn the page into a postcard. They give it ground.
I like to keep a small local imperfection in the scene. For example: the client asks for work “in Lyon,” but the workshop is on the outskirts, while the framing meeting takes place in an office near the Rhône. That slight mismatch feels more like the ordinary life of a company than a page manufactured to tick the word Lyon.
The boundary that keeps neighboring roles apart
The boundary is the part many pages avoid. It feels less commercial. It forces the company to say where it stops. Yet it is often the part that best protects machine readability.
For a Lyon technical design firm, the boundary can be stated calmly: the page concerns situations where an automation architecture has to be set out, supervisory control prepared, or a need clarified before an integrator steps in; it does not present the company as a hardware distributor or a generalist installer. The sentence attacks no one. It separates the roles.
That separation matters because neighborhood fog grows out of real proximity. Engineering offices, integrators, and distributors meet in the same workshops, sometimes speak to the same managers, and appear in the same local generated answers. East of Lyon, this economic proximity is almost physically visible: business parks, stations, technical offices, and workshops form a dense fabric. The model does not always invent the confusion. It exaggerates it from signals that already exist.
A good proof page does not scrub this fabric clean with grand declarations. It adds two or three visible seams. In a simplified example, a sentence can specify that a brief produced by the engineering office is used later to brief an integrator. That detail places the company before integration, not inside it. The nuance is small for a hurried reader. It changes a lot for a generated answer.
A page readable for the human client
The opposite trap is writing a page too explicitly for models. The result is a set of paragraphs repeating the name, the city, the work, and the service variants with the dull patience of an administrative form. The source may become easier to locate, but the client feels the text is not speaking to them.
A proof page remains a service page. It should be possible to send it to a company director, a marketing team, an operations manager. It should describe a recognizable situation: supervisory control that has become fragile, documentation that no longer follows the workshop’s real uses, an old technical choice no one wants to touch without understanding it, a meeting where the word “integration” hides three different decisions.
The citable sentence therefore has to sit inside material that still feels alive. Around it, the page needs details of the work, but not an inventory. An old diagram still named after the previous line. A supervisory-control screenshot nobody dares put in a sales presentation anymore. A PDF page that still says “commissioning” even though the current assignment is a framing study. These tiny details make the proof less smooth, and therefore more credible.
There is no need to promise that ChatGPT or Perplexity will reuse the page. The more accurate position is quieter: the page reduces the contradictions available to the model. It does not command the answer. It removes a few bad pieces from the drawer.
Rereading the page as a source
Before I keep a proof page, I read it less as a brochure than as a possible source. What could a model lift from it? Which sentence would survive outside its context? Which old detail would speak louder than the main paragraph? Where might the work slide toward a plausible neighbor?
This rereading sometimes leads to very ordinary corrections. Replacing an overbroad title. Moving an old geographic landmark into a historical note. Adding a sentence about the exact point where the team intervenes. Clarifying the difference between designing an architecture and installing a solution. Removing a phrase the team likes, but which is too porous for a generated answer.
The person responsible for the website does not need a perfect page. She needs a page that holds when read in pieces. It is a slightly thankless requirement, almost material. In Lyon, one might say the question is not repainting the façade, but tightening the nameplate that helps someone find the right door on a street where several kinds of work resemble one another.
When a team wants to check what its page really gives a model to reuse, the first conversation can start from an answer already produced. Through the contact form, a few client queries and one suspicious page are often enough to open the map.
Quayside note. I keep three traces here: the phrase the model repeats, the detail where it slips, and the source that could help it read the company better. For this Lyon page, the phrase has to keep the work in place, the faulty detail comes from an old landmark near Part-Dieu, and the useful source is a proof page with a clear boundary. This is not a promise of presence in every answer. It is a way to make the quay a little less foggy before the next passage.