Software, AI and digital products for start-ups, enterprises and governmentsBook a free call
Services
Web & Digital PlatformsCustom SoftwareMobile ApplicationsAI & AutomationAR / VR SolutionsTechnology AdvisoryAll services
Industries
Government & Public SectorFinance & FinTechHealthcare & MedTechRetail & E-CommerceEducation & EdTechReal Estate & PropTechAll industries
Company
About UsOur TeamPortfolioInsightsGlobal Offices
More
Our ApproachContactFAQBook a Free Consultation
Search & AEO

Your site is invisible to AI answer engines — and you cannot see it in your analytics

Pages can look perfect yet stay invisible to AI answer engines, with no sign in analytics.

7 min read

There is a specific kind of website failure that nobody notices for a year. The site loads fast. It looks right on every device. Search Console reports the pages as indexed. And yet when a prospective customer asks an assistant a question your business is the obvious answer to, you are not in the answer — and there is no report anywhere that tells you why.

The cause is usually that the page's content does not exist in what the server sent. It is assembled afterwards, in the browser, by JavaScript. Human visitors never notice, because their browser runs that JavaScript in a few hundred milliseconds. Search crawlers mostly cope, because they have spent a decade building the capacity to render pages. The systems that answer questions conversationally frequently do not: many fetch the document, read what is in it, and move on.

What the two kinds of visitor actually receive

It helps to be concrete about the difference. When a page is server-rendered or statically generated, the response body contains the words. Headings, paragraphs, the answer to the question, the price, the eligibility criterion — all of it is in the text of the document. Anything that can read HTML can read the content.

When a page is client-rendered, the response body is close to empty: a root element, a few script tags, and nothing else. Everything a reader sees is produced by executing those scripts. The document a non-rendering fetcher receives contains no product description, no service explanation, no answer to anything.

The check is a single request. If the words are not in the response, only clients that execute JavaScript can see your site — and an increasing share of the ones that matter do not.

You can test this in under a minute without any tooling: fetch the page and search the raw response for a sentence you know is on it. If the sentence is not there, the page is client-rendered and you now know something important about your site that no dashboard was going to tell you.

Why this got worse, not better

For most of the last decade the trade was acceptable. Search engines rendered JavaScript, users got a fluid interface, and the cost was a slower first paint. The calculation changed when a meaningful share of research questions started being answered conversationally rather than as a list of links.

Those systems have different economics. A search engine amortises the cost of rendering a page across every query that page might answer, for years. A system fetching sources to compose one answer has a latency budget measured in seconds and no reason to spend it running someone's application. So the pragmatic behaviour is to read what arrives and use what is there.

The result is an asymmetry worth internalising. Being absent from a search results page is visible: rankings move, impressions drop, somebody notices. Being absent from an answer is invisible. There is no impression to lose, because you were never a candidate.

What to change, in order of return

1. Put the content in the response

This is the whole fix, and everything else is refinement. Modern frameworks make rendering a per-route decision rather than a per-project one: a page can be statically generated at build time, regenerated on a schedule, rendered per request, or left to the client. Marketing pages, service descriptions, documentation and anything answering a question should never be in the last category. Authenticated dashboards can be, because no crawler will ever see them.

Retrofitting this is real work, but it is bounded work, and it is far cheaper than the alternative most teams reach for — which is to keep the architecture and add a separate pre-rendered copy for machines. That path creates two versions of the truth and eventually they disagree.

2. Structure the content so a machine can tell what it is

Once the words are in the document, structured data tells a reader what kind of thing it is looking at: an organisation, a service, a question with an answer, a step in a process. This is not a ranking trick. It is the difference between a system inferring that a paragraph might be an answer and knowing that it is one.

Two disciplines matter more than the schema choice itself. First, structured data must describe content that is actually on the page — a set of questions and answers in the markup that a human visitor cannot find is a violation, and it is the most common way sites lose rich results. Second, one page should carry one of each entity type. A page describing two different sets of frequently asked questions is ambiguous, and ambiguity is resolved by ignoring it.

3. Answer the question in the first paragraph

If a page exists to answer something, the answer belongs near the top, stated plainly, in a sentence that survives being quoted on its own. This is good writing regardless, but it is now also a retrieval property: what gets cited is what can be lifted out of the page without carrying its context along.

4. Let the crawlers in, explicitly

Most robots files were written when the only visitors worth naming were search engines. The crawlers used by assistants are separate agents with their own names, and a default-deny policy — or a permissive one that nobody has revisited in three years — silently excludes them. This is a five-minute change with an outsized effect, and it is worth making a deliberate decision rather than inheriting one.

How to know whether it worked

The honest answer is that the feedback loop is poor and will stay poor for a while. Traffic from assistants is under-attributed: referrers are often absent, and a person who reads an answer and then searches your brand name arrives as direct or organic traffic. You will see the effect in branded search volume and in the phrasing of inbound enquiries before you see it in a channel report.

What you can verify directly is the mechanism. Fetch each important page without executing JavaScript and confirm the content is present. Validate the structured data and confirm every entity it declares corresponds to something visible. Check the robots policy names the agents you want. Those three checks are objective, they take an afternoon, and passing them is the part that is actually within your control.

Facing a similar challenge?

Tell us where you are today. We will explain what the work involves and whether you need us at all.