ChatGPT recommendsyour competitor.WellCited changes that.

A root-level block is the only thing scored here, because it is the only thing that decides whether an engine may fetch the page. Nine crawlers feed the answers people now read instead of a list of links (GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, PerplexityBot, Perplexity-User, Google-Extended, CCBot and meta-externalagent), and each one is either allowed in or it is not.

The check resolves groups the way a real crawler does: a group that names GPTBot beats the wildcard group. So a site can refuse scrapers in general and still admit the engines it cares about. Most sites that fail this did not decide to fail it: a security plugin, a copied robots.txt or a well-meaning ops ticket did it for them, and nobody has read the file since.

The fix is one file and it takes ten minutes. Open robots.txt, find any group whose rules include Disallow: / (most often the wildcard group) and either remove that line or add a named group for each crawler you want to admit, with Allow: / underneath it. The named group wins, so a blanket refusal can stay in place for everything else. Deploy, then re-run the check: robots.txt is fetched live every time, so the result reflects what is being served rather than what somebody intended. If you are excluding an engine deliberately, that is a legitimate business decision and this check will go on reporting it accurately; a score is a measurement, not an instruction. What it should never be is an accident that nobody in the company knows about.

Ten points for having structured data at all, five for a block that identifies the organisation, five for a rich type: FAQPage, Product, Article, HowTo, SoftwareApplication, BreadcrumbList or Review. Machines use it to resolve identity without inferring it from prose, and inference is exactly where somebody else's name gets substituted for yours.

This is not a ranking trick. It is the difference between a model knowing your product's name, category and homepage as facts, and reconstructing them from a headline and a nav bar. The cheapest available win on most sites is a single Organization block on the homepage: five minutes of work, and missing from the majority of the sites we audit.

Start with one Organization block on the homepage and nothing else. It needs a name and a url, plus, if you have them, a description, a logo and the profile URLs you already link to in the footer. Paste it into the head as a script of type application/ld+json; it changes nothing a visitor sees and nothing about how the page renders. Once that validates, add the rich type that matches what the page actually is: FAQPage where you answer questions, Product where you sell something, BreadcrumbList where there is a hierarchy. Do not add a type the page does not support. Structured data describing a page that does not exist is worse than none at all, because it is the one signal a machine is inclined to trust without checking.

Eight points for three or more question-shaped headings, four for two or more lists, two for a table, six for a detectable FAQ section. None of it is about keywords. It is about whether a model can lift a self-contained answer out of your page without reassembling it from four paragraphs of narrative first.

The fastest fix is usually to rewrite a heading as the question its section answers, then put the answer in the first sentence underneath rather than the fourth. It reads better for people too, which is the only reason worth doing it. Tables and lists score because they are the two structures that survive being extracted with no surrounding context at all.

Take your three most important pages and read only their headings. If they are nouns like Features, Platform or Solutions, you have a brochure. Rewrite each one as the question a buyer would actually type, then make the first sentence underneath the complete answer and put the elaboration after it instead of before it. Add a table wherever you are comparing things and a list wherever you are enumerating them, because those two structures survive extraction with no surrounding context. And check that any FAQ answers are in the HTML rather than behind a script that reveals them on click: we found exactly that bug on this page, which is why our own FAQ is now a plain disclosure element that keeps every answer in the source whether it is open or shut.

We fetch the page once, with no browser and no JavaScript engine, and measure how much readable text is actually in that response and how much of the payload it represents. Most crawlers do the same thing. A page that assembles its content in the browser arrives as an empty shell, and an empty shell cannot be quoted no matter how good the content would have been.

This is the check that most often surprises a well-built site. A single-page app with excellent writing can score two out of seventeen, and a heavily hydrated server-rendered page can still come in thin because so much of what it ships is machinery rather than words. The fix is not subtle: server-render the pages you want quoted, and give them enough substance to be worth quoting.

Server-render the pages you want quoted. In a modern framework that is a configuration decision rather than a rewrite: mark the marketing and documentation routes as static or server-rendered and leave the interactive parts as islands. Then read the check's second number, the proportion of the response that is genuinely text. A page can be perfectly server-rendered and still come in thin, because hydration payload, class names and inline scripts outweigh the words. The remedy for that is not a smaller framework; it is more substance. If a page ships forty kilobytes of machinery to deliver two hundred words, the honest reading is that the page does not yet say very much, and this section of this site exists because our own audit said exactly that to us.

Two points for a title, three for a description between 50 and 170 characters, three for a complete Open Graph set, two for a canonical link. Boring, foundational, and about five minutes of work, which is why losing points here is the most annoying way to lose them.

The description carries more weight than it used to. It is short, it is written by you rather than extracted from you, and it is the single sentence most likely to be quoted back when a model needs one line about what a page is. A great many descriptions on the web were written for a search snippet years ago and have not been read by their owners since.

Write the description as a sentence rather than a keyword list, and keep it between fifty and a hundred and seventy characters: long enough to say what the page is, short enough to survive being quoted whole. Fill the Open Graph set with a title, a description and an image, because those three are what an answer engine and a chat client both fall back on when they need a preview. Add a canonical link even on pages with no duplicates, since it costs one tag and the failure mode without it is silent. Then read the title out loud. If it does not identify the company and the page in one breath, no amount of markup underneath it will repair the impression it makes.

llms.txt is a proposed convention: a plain-text file at the root of a domain saying what the site is and which pages are worth reading first. Adoption is not universal and we will not pretend otherwise, which is precisely why it is worth eight points here and not thirty.

We require plain text, not an HTML page that happens to answer at that path. Sites that serve their app shell for every unknown URL fail this check, and correctly: a file that returns a rendered page is not a file. Writing one is cheap, it cannot hurt you, and the exercise forces the same clarity the checks that definitely matter also reward.

Write it by hand, or generate it (the tool on this site does it from your live pages in about ten seconds) and then check three things. It has to be served as text/plain at the root of the domain, not as a rendered page answering at that path. It has to open with a single line describing the business the way you would describe it out loud, because that line is the most quotable thing in the file. And the links under it have to be the pages you actually want read first, in that order, rather than a dump of the sitemap. A short honest map beats a long automated one: if part of the site is not worth a model's attention, leaving it out is the useful signal.

Either a sitemap.xml that parses as one, or a Sitemap: line in robots.txt pointing at it. Five points, because it is the cheapest item on this list and every framework has a plugin, a route helper or a build step that produces one.

AI search indexes lean on the same crawl infrastructure as classic search, so a declared crawl path is still how a new page gets found quickly rather than eventually. It matters most for sites that publish often, which is most sites trying to get quoted in the first place.

Generate one at build time and reference it from robots.txt with a Sitemap: line. Every framework has a plugin, a route helper or a build step that produces it, and if yours does not, a hand-written file listing a dozen URLs still scores and still works. Include only pages you want indexed: a sitemap full of redirects, noindex pages and duplicates teaches a crawler to trust it less, which is the opposite of the point. Set lastModified from a real timestamp rather than from the build clock, because a sitemap in which every page changed this morning is a sitemap in which that field carries no information at all.