How to rank in ChatGPT

A Google result page has ten slots and a measurable position within them. A ChatGPT answer has a paragraph. You are named in it or you are not, and if you are named, you are either the recommendation or one of several or an afterthought at the end of the sentence. There is no page two to be found on, which is the part that makes this channel unforgiving: absence is total rather than gradual.

So the useful replacement for “position” is three separate questions, and they move at different speeds. Are you mentioned at all. Where in the answer. And is what it says about you actually true. The third one surprises people, and it is the one that does damage while you are winning: an assistant confidently telling a buyer a price you do not charge is worse than not being mentioned.

One more thing worth knowing before optimising anything: ChatGPT answers in two modes. When it searches live it downloads pages and cites them, and your site is directly in play. When it answers from training data it downloads nothing and repeats what its corpus held about you. Work on the first pays off in weeks. Work on the second pays off in months and does not run through your website at all.

Read your robots.txt first, because it takes a minute. Then read the layer that actually blocks people: the bot-protection rule at your CDN. Those products allow-list Googlebot by default and mostly do not allow-list GPTBot, so a site can rank perfectly and return a 403 to every AI fetcher without anything in the analytics saying so. Request your own page with GPTBot’s user agent and compare the status code to what a browser gets.

The evidence that settles it is your server logs: hits by user agent over thirty days. Zero hits from an agent you believe you allow means the block is somewhere you have not looked yet.

Roughly what remains is what an assistant can cite. Google renders JavaScript; assistant fetchers generally do not, and take the HTML in the first server response. If a header and a footer are all that survive, that is the entire problem and there is no need to look further.

This bites in pieces as often as it bites wholesale. A site can be server-rendered and still hide the three things a buyer wants: prices loaded from an API call, an FAQ built by a script on mount, reviews pulled from a third-party widget. Those are exactly the sections a model would have quoted.

One check almost nobody runs: look at the HTML your server returns, not the DOM in developer tools. Developer tools show you the assembled document, including everything JavaScript added. A fetcher receives the other one.

Four rules that apply to any page:

• Explicit subject in every claim that matters. Your company’s name, not “we”. A fragment whose subject is “we” is unusable away from your site.
• The unit inside the sentence. “Costs 49 a month”, not “costs 49” with the currency in a table header three rows up.
• One claim per paragraph. A paragraph carrying five ideas gets retrieved whole or not at all, and whole rarely fits.
• A real FAQ, with the question written the way a buyer would type it. It is the format that fits retrieval best, because the question restates the query and the answer is self-contained.

Write one sentence defining your company: what it is, who it serves, where. One sentence, one or two lines. Then put that exact string on your site, on your LinkedIn, on your Google listing, in your trade directories and in the byline of anything you publish elsewhere. Same string, same company name, same city.

It sounds like housekeeping and it is the highest-leverage of the four. When several independent sources describe a company identically, a model asserts. When they contradict each other, it hedges or changes the subject — and hedging is indistinguishable from absence to the buyer reading the answer.

The second half of this work is slower still: being present in the documents assistants retrieve when somebody asks for a recommendation in your category. In most sectors that means roundup articles, trade directories and specialist publications. It is writing and relationships rather than technical work, and it is one of the few places where a small company beats a large one, because hardly anyone is doing it deliberately.

What works is a fixed set of twenty to forty buying questions, written down and frozen, asked on the same day each month, in a clean session with no history, and logged on three metrics: were you named, where in the answer, and was the description factually correct. A difference between two one-off queries is noise. A trend across thirty questions over three months is a signal.

Expect the four checks to pay off on different schedules. Access moves in days to weeks — Perplexity usually reacts first because it searches live almost always. Rendering moves in weeks. Rewriting moves position over weeks to months. Consensus moves in months, and it is the one that gets you into answers that never searched at all.