How to AI Score.
The AIRank AI Score is a 47-point rubric, weighted against real citation-rate data. Most sites score 40–60 on first scan. This is the checklist that reliably moves that number to 70+ inside two weeks.
The short answer
Moving the AI Score twenty points means fixing the highest-weighted checks rather than the easiest ones: ship llms.txt, put FAQPage markup on three high-intent pages, rewrite H1s as declarative claims, pull reviews into server-rendered HTML, date and byline every article, then publish unique-claim pages and link them properly.
Before you start
Run a baseline scan first and keep the report. A full 47-point audit plus a citation sweep completes in 30 to 60 seconds for most sites, and without the before-state you will spend the next fortnight arguing about whether anything moved. Your plan sets how fast you can re-check: Free re-scans every 24 hours, Pro every 6, Team every hour. That cadence is a hard ceiling on your feedback loop, and it is worth knowing before you start shipping.
- Template access — H1s, article metadata and review markup usually live in theme or component code, not in the CMS body field.
- An author record per writer, with a real bio page to link to.
- Root path control for llms.txt, and server-side head injection for schema.
- A baseline scan report saved before the first change lands.
Two to four hours of hands-on work spread across a week is honest for a site under a hundred pages, and most of it is step six. What blows the estimate is ownership: an agency-managed marketing site, a frozen design system, or a headless setup where H1s arrive as component props all convert a fifteen-minute edit into a two-week request. Find out which of those you are in before you promise a date.
Why this works
The rubric is four pillars over 47 checks, and content extractability carries 40% of the total weight on its own — twice any other pillar. That weighting is not aesthetic; it is why this checklist is ordered the way it is. Three of the six steps are extractability fixes, and they are placed where they are because a point of extractability is worth roughly twice a point of anything else in citation terms.
What the score actually proxies is how much of your site survives being chunked. A page whose reviews are in JavaScript, whose H1 is a slogan and whose claims appear verbatim on forty competitor sites produces no span a model can safely quote and attribute. Below 50 means effectively invisible to AI; above 85 puts you in the top decile of everything we scan. Most of the distance between those is removing reasons a chunker cannot cut cleanly.
The score is a proxy for extractability, not a ranking position. There is no ranking to hold — two engines asked the same question return different answers.
The steps
- 01
Ship llms.txt (3 points)
A present, well-formed llms.txt is worth three points on the rubric's technical-readiness pillar, and the llms-full.txt companion adds a fourth. It is also the fastest thing on this list — a single Markdown file at your apex path with an H1, a blockquote description and ten to thirty described URLs. The check is binary on presence and graded on form, so a malformed file scores worse than a short correct one. Write the short correct one today and expand it later. See How to set up llms.txt.
Check
You'll know it worked when your next scan shows the llms.txt check flipped from fail to pass inside the technical-readiness breakdown.
- 02
Add FAQ schema to three pages (4 points)
FAQPage JSON-LD on a high-intent page is worth four points — the single largest schema-coverage item in the rubric. Five to eight questions per page, each with a 40–120 word answer, rendered visibly in the same HTML. The points land once the first high-intent page passes, so pages two and three are not about the score; they are about giving retrieval more than one pre-cut chunk to reach for. Do not expect a Google rich result from this. See How to add FAQ schema.
Check
You'll know it worked when the schema-coverage pillar shows FAQPage passing and validator.schema.org returns zero errors on all three URLs.
- 03
Rewrite your H1s as answers, not taglines (2 points)
'Introducing Acme, the tool your team will love' is a tagline. 'Acme is a Shopify analytics tool used by 3,400 stores' is an answer. Rewrite your top five H1s as declarative statements containing the brand name and one specific, checkable claim. The rubric grades this because an H1 is the strongest available hint about what a page's chunks are about, and a tagline gives a retriever nothing to match a query against. This is fifteen minutes of writing that changes how every chunk beneath it is interpreted.
Check
You'll know it worked when each rewritten H1 contains your brand name plus one specific claim and reads as a complete sentence rather than a slogan.
- 04
Surface hidden reviews and testimonials (2 points)
If your reviews lazy-load or live inside a JavaScript-only carousel, crawlers never see them, and the rubric scores them as absent because from the outside they are. Move them into the initial HTML response. A static list of three quotes with real names and company names is worth more than an animated widget holding twenty hidden ones. The same logic applies to any content behind tabs or accordions: collapsed is fine, absent is not. Test with curl rather than devtools, because the rendered DOM will tell you what you want to hear.
Check
You'll know it worked when curl -s on the page piped through grep finds a reviewer's name in the raw HTML — if it only appears after JavaScript runs, the crawler never saw it.
- 05
Add dates and authors to every article (4 points)
Dates on articles are worth two points and a verifiable author byline another two, which makes this the largest single block of points available for rote work. Go through your blog and add a visible publication date plus an author attribution that links to a real bio page. 'Team' is not an author. The reason both are weighted is that they are the cheapest available signals of whether content is maintained and attributable — and a retrieval layer choosing between two similar pages will use exactly that.
Check
You'll know it worked when every post in your blog index shows a visible date and a byline linking to a bio page with a named person behind it.
- 06
Write one unique-claim page per week (4 points over 2 weeks)
The unique-claims check is worth four points and is graded against a reference corpus, so the requirement is genuinely novel text rather than well-written text. Each page should contain a blockquote with a specific, verifiable, brand-attached claim: 'Acme processes 240M invoices per quarter', or 'Acme is the only Shopify app with native Google Merchant integration'. These pages disproportionately drive citations because they are the only place a model can source that sentence. Link each one from three existing pages so it is reachable in three clicks.
Check
You'll know it worked when the unique-claims check moves off fail and the new page is reachable from your home page in three clicks or fewer.
How to verify it worked
Re-scan and read the change log, not the headline number. The score can move for reasons you did not cause — a page got re-crawled, a check that was previously indeterminate resolved, a third-party signal updated. The verification you want is check-level: the specific checks you targeted flipped from fail to pass, and no unrelated check regressed. That is a claim you can defend in a review; a number going up is not.
Citations lag the score by one to two weeks, because the score measures your site's state while citations measure what retrieval has since done with it. If you want to know which fix mattered, do not ship all six in one deploy. Two batches a week apart costs you nothing and buys you attribution, which is the only way this checklist gets better on your second site.
Cadence
On the Free plan you cannot re-scan for 24 hours. Ship the whole batch before you trigger it rather than burning the window on a single fix.
Three ways this goes wrong
- The score-without-citations plateau. Symptom: the number climbs fifteen points over two weeks and your citation count does not move at all. Cause: you took the cheap technical checks — sitemap, canonicals, response time — and skipped extractability, which carries 40% of the weight and nearly all of the causal relationship with being quoted. Fix: audit which pillar your gains came from. If technical readiness accounts for most of it, go back and do steps three through six properly.
- The cached-scan false negative. Symptom: you shipped a fix, re-scanned, and the check still reports fail. Cause: either your plan's scan window has not elapsed, or a CDN served the scanner a cached copy of the old page. Fix: check the scan timestamp against your deploy timestamp before assuming the fix failed, then fetch the URL through curl with a cache-busting query string and confirm the change is in the bytes. Purge the CDN path and re-scan once.
- The unique-claim orphan. Symptom: you published four claim pages, the unique-claims check passes, and nothing downstream changed. Cause: nothing links to them. The rubric separately requires every key page to be reachable within three clicks, and retrieval strongly favours pages that co-occur with related content. Fix: link each claim page from at least three existing posts using the target query as the anchor text, and add them to your main navigation or a hub page.
What to expect
The full checklist produces a 16–24 point AI Score lift in our data, measured 14 days after completion. The variance is driven almost entirely by step 6 — unique claim pages compound differently depending on how well they're surfaced in your internal link graph.
Why did my AI Score drop after I published new pages?
Because several checks are averages across your pages, not counts. Publishing thin, undated, unbylined posts lowers the mean on freshness, author attribution and chunk density even though your best pages did not change. This is working as intended: the score models what a retrieval layer sees across your site. Fix the new pages to the same standard as the old ones and the average recovers.
How fast can I re-scan after shipping a fix?
It depends on your plan. Free re-scans every 24 hours, Pro every 6, Team every hour. That is the ceiling on your feedback loop, so batch your fixes to fit it rather than spending a window on one small change. A scan itself takes 30 to 60 seconds, so the wait is entirely about cadence rather than compute.
Is a 20-point jump realistic if I'm already at 70?
No, and you should not aim for it. The checklist is calibrated for sites in the 40–60 band, where several high-weight checks are outright failing. At 70 you have already collected the cheap points, and the remaining distance is in authority signals and unique claims — slower, less controllable work. Above 85 puts you in the top decile, and getting there is a quarter's project rather than a fortnight's.
Do I have to fix all 47 checks?
No. The checks are weighted, and several are conditional — Product schema does not apply to a site with nothing to sell, and llms-full.txt is legitimately not applicable to a marketing site. Work the ordered fix list in your report, which sorts by expected delta rather than by effort. Chasing a one-point check while a four-point one fails is the most common way to waste a week here.
Does the score include anything I can't control?
Yes. The authority and freshness pillar includes referring domains, citations from communities like Reddit and Stack Overflow, press coverage and third-party directory presence. You can influence those, but not ship them. That is roughly 20% of the score sitting outside your deploy pipeline, and it is the main reason a technically perfect site can still sit in the seventies.
Written by
The AIRank Editorial Team
Research & editorial, AIRank
The AIRank editorial team runs the 47-point scanner, the Observer pings, and the GEO research programme every week. Writing is reviewed by the core engineers who build the Injector, Blaster, and Surgeon agents.
Last reviewed
About the team →