When an assistant such as ChatGPT or Perplexity answers a question, it reads a number of pages and cites only a few. The pages that get cited tend to share a family resemblance: you can tell quickly what they say, and what they say can be checked.
When we write pages and articles, for ourselves and for clients, we stick to a short set of rules. Here they are.
The answer goes up top
If a page answers a question, the answer sits at the top, in one or two sentences. Background, history and nuance come afterwards.
A generative engine needs to find the quotable bit immediately. Human readers, who are in as much of a hurry as the machine, appreciate it too.
One question per section
Each section answers a single question, and its heading says which. "How much does a bespoke management system cost" is a useful heading. "Our approach" tells nobody anything, machines included.
Figures with a date and a source
A number without a date ages badly, and a number without a source cannot be checked. We write "according to such-and-such, as of October 2026" and add the link.
That is why the articles on this site end with their sources.
Proper names and clear places
"Software development studio in Naples" is a phrase an assistant can reuse when someone asks for a studio in Naples. "We stay close to our clients" gives it nothing to work with.
City, sector, product names and technologies get spelled out in full at least once, with nothing taken for granted.
Author and date on show
Every article says who wrote it and when. Readers use that to weigh what they read; search engines use it to judge whether the content is current.
No text hidden behind a click
Tabs, accordions and "read more" buttons are fine as long as the text is already in the page. If it is loaded with JavaScript only after the click, a crawler that does not run scripts will never see it.
One page per topic
A page covering five topics is rarely the best answer for any one of them. We prefer separate pages, each with its own question and heading, linked to one another.
Update rather than duplicate
When information changes, we update the existing page and change its date. Two near-identical pages compete with each other, and an engine may well end up citing the stale one.
An example: our FAQs
The FAQs on our site are written as question and answer because that is the format generative engines are happiest to cite. The searcher's question matches ours, and the answer is ready to lift.
The same questions are also described with schema.org FAQPage structured data in JSON-LD, a format search engines read directly. Stripped to the bone, the structure looks like this:
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [{
"@type": "Question",
"name": "Question text",
"acceptedAnswer": {
"@type": "Answer",
"text": "Answer text"
}
}]
}The text in the JSON-LD must match what is on the page. Structured data that says something different from the visible text is the quickest way to lose a search engine's trust.
What we avoid
No keywords crammed in, and no long copy written to look authoritative. Assistants pick up clear sentences, and a wall of text contains very few.
If you want to review your own pages this way, start with the most visited one and ask which question it answers. If the answer is not in the first few lines, that is where the work begins.
