Why one big page cannot be cited

The Miravi landing page is one HTML file of about 1.4 MB. It covers what the product is, who it is for, how the agent works, the brand brain, the canvas, four personas and a FAQ. Every word of it is on a single URL.

Which means if someone asks an assistant "how do I tell whether AI is reading my blog", there is no page of ours to cite. There is a site that discusses it, somewhere inside a very long document that is also about nine other things. Those are not the same, and the difference is invisible until you go looking for it.

What an engine has to work with

When an AI search product answers a question with sources, the unit it deals in is a URL. It fetched a URL, it matched some passage of that URL against the question, and it renders a link to that URL next to the sentence the passage supported. The whole mechanism is built on the assumption that a URL is about something.

A single-page site breaks that assumption in three specific ways.

Your relevance signals come as a set of one

One page gets one <title>, one meta description, one canonical, one H1, one schema block. Those are the cheapest and clearest statements you can make about what a document answers, and a single-page site spends its entire budget on a generic company summary. Ours says what Miravi is. It does not say "here is how to detect AI crawlers", because it cannot: it also has to introduce the company.

The passage that matters competes with everything else on the page

Retrieval scores chunks, not sites. The two paragraphs on our landing page that genuinely address crawler detection sit among hundreds of paragraphs about other topics. Even when the matching works perfectly, the page as a whole reads as weakly related to the question, because on balance it is.

People reach for anchor links here, and they help humans more than engines. /#canvas still resolves to the same document, with the same title and the same everything else. You have given the reader a scroll position, not the engine a subject.

You cannot tell which topic anyone wanted

This is the part that annoys me most, and it only shows up once you start measuring. A user-triggered fetch from ChatGPT-User is a strong signal: a person asked something and an assistant went to read your page to answer it (the three classes are here). On a granular site, the URL tells you the topic. Four hits on /blog/robots-txt-for-ai-engines means buyers are asking about robots.txt.

On a one-page site every fetch is a hit on /. Somebody asked something. That is all you will ever know.

A URL is the only place an engine can put a citation, and the only label your measurement has to work with. One URL, one topic, or you lose both.

The test

Write down the questions a buyer asks before they pay you. Not keywords, actual questions, the ones you answer in sales calls. Then, for each one, name the URL that answers it.

Two failure modes show up immediately. If several questions map to the same URL, that URL is doing too many jobs and will lose to a competitor who wrote one page about one of them. If a question maps to no URL, you are not in that answer at all, and no amount of posting adjacent content changes it.

For us the answers were /, /, /, /, and "nowhere". Hence this blog, which until today was a page that said "Coming soon" while telling crawlers not to index it. Two mistakes stacked: nothing to cite, and an instruction not to look.

What granular actually means

Not more pages. One page per question you can answer better than anyone else. The distinction matters, because "publish more URLs" is exactly how sites end up with fifty thin pages that each say very little, and an engine is measurably good at ignoring those. Thin pages are worse than one thick one, because now you have diluted the site and gained nothing.

What works is boring:

• A stable, readable URL that describes the subject, not a date or an ID.
• A title that matches how somebody would actually ask the question.
• The answer in the first paragraph or two, before any preamble. If a passage has to be extracted to be useful, put the useful passage where it is easy to extract.
• Specifics that only you have. Real numbers, real user-agent strings, real limitations. Generic advice is already covered by the model's weights and adds nothing worth citing.
• Enough depth that the page is genuinely the best answer, and no filler beyond that.

The unglamorous part is that this is just writing one good page about one thing, which is what editors have wanted all along. The change is that the reward is now legible: you can watch a retrieval crawler index a specific URL, then watch user-triggered fetches arrive on it, and know which question they came from.

What we are doing about ours

The landing page stays one page, because as a landing page it works: a visitor scrolls it and understands the product. It was never the thing that was going to get cited. What was missing is everything underneath it, one URL per real question, starting with the three posts published today.

Splitting the landing page itself is a bigger job and it is on the list, honestly somewhere below shipping the thing that measures whether any of this worked. I would rather tell you the ranking than pretend the site already looks like the advice.