Platform League Table: WordPress, Next.js, Astro and Shopify Across 728 Sites

Every few weeks someone asks which platform produces the most agent-ready sites. WordPress, Next.js, Astro and Shopify all have fans, and a ranked table is the answer people expect. We have the data to build one: 728 sites scanned by AIScan, each with a detected platform and a full report stored. So we built the table, and then checked whether it was measuring what it appeared to measure. Part of it is. A large part of the gap between WordPress and Next.js comes from how the rubric treats a site it classifies as an app, not from what either site publishes.

On 14 October 2026 we queried production for the newest site-scope scan of every host. Five platforms have 15 or more sites: not detected (279), WordPress (189), Next.js (165), Astro (35) and Shopify (16). Their mean scores run from 46.3 to 67.7. When we compare only the ten checks that every site is scored on, the order changes, and the Next.js deficit against WordPress shrinks from 13.7 score points to 3.6 pass-rate points. The rest of this article shows the table, the reason it moves, and what each platform's owners can do.

Quick summary

What the data says: a platform label predicts a score partly through the content a site publishes and partly through a switch in the scanner. Both effects are real. Only the first is something a site owner can act on.

Best for a site owner reading a platform ranking: compare yourself with sites on your own platform, on the checks you can change. For anyone quoting a league table: ask how many sites in each row were scored on the same checks, because ours were not.

How we measured it

The limits come first, because they decide how far to trust the rest.

All figures come from a query run on 14 October 2026 against production. We used site-scope scans under rubric version 2026.08.2, in service since 24 August 2026. The scans in the table run from 25 August to 14 October. We reduced each URL to its host and kept the newest scan per host, which gives 728 hosts. aiscan.site is excluded, since our own scans score 100 and would flatter every row. Page-scope scans are excluded. No scanned site is named in this article.

The platform comes from AIScan's detector, which reads a site's homepage and its response headers. It has known errors, which we documented in the state of agent readiness study, and it can only name a stack it can see. We kept platforms with at least 15 sites, which leaves five rows and 684 of the 728 hosts. The other 44 hosts are spread across ten platforms (Lovable has 13, Vue 6, Nuxt, Framer and SvelteKit 5 each, then smaller groups) and are too few to rank.

The sample is self-selected: these are sites someone chose to scan. It over-represents people who care about the subject and people who are curious about competitors. A scan also reads one URL's neighbourhood from one datacentre address on one day. What follows is an observational comparison. It says how scanned sites on each platform score, not what a platform does to a site.

The query that builds the base table:

WITH latest AS (
  SELECT DISTINCT ON (lower(regexp_replace(regexp_replace(url,'^https?://',''),'/.*$',''))) 
    lower(regexp_replace(regexp_replace(url,'^https?://',''),'/.*$','')) AS host,
    platform, score, result
  FROM scans
  WHERE rubric_version = '2026.08.2' AND scope = 'site'
    AND url NOT ILIKE '%aiscan.site%'
  ORDER BY 1, created_at DESC
)
SELECT coalesce(platform,'null') AS platform, count(*) n,
       round(avg(score),1) mean,
       percentile_cont(0.5) WITHIN GROUP (ORDER BY score) median
FROM latest GROUP BY 1 ORDER BY n DESC;

The league table

Three things stand out before any adjustment.

Astro has the best mean and the best median. Its median (78) sits 10 points above its mean (67.7), which says the group is lopsided: a cluster of sites near the top and a tail near the bottom. The next section puts numbers on it.

WordPress, Astro and Shopify land within 1.3 points of each other on the mean. A table that ranks them first, second and third is ranking noise. The Shopify row has 16 sites, so one store moves its mean by about 2 points.

Next.js is 13.7 points below WordPress on the mean and 19 on the median. The state of agent readiness study reported a similar gap at 473 sites, 15.8 points on the mean, and called it a verdict on defaults. We still think defaults matter. What we did not know then is how much of the gap is arithmetic.

Ceiling and floor

A mean hides the shape. The ceiling is how high the best sites on a platform get, and the floor is how low the worst ones fall.

Each platform has a different story.

Astro has the highest ceiling and a wide spread. Its 90th percentile is 100, and 15 of 35 sites reach 80 or higher. Its 25th percentile is 50. In the blocked-probe study we found that four Astro sites refused our probes and averaged 9.0, and those four are the bottom of this range. Without them the other 31 average 75.3. The Astro setup guide covers the files that put the top group where it is.

WordPress has the highest floor. Only 6 of 189 sites score under 40, and the 10th percentile is 49. WordPress core serves rendered pages, generates a sitemap and sends a Link header pointing to its REST API, so a site that has done nothing still collects points on discoverability. The ceiling is lower than Astro's: 42 sites reach 80, and the best 10% start at 92.

Next.js has a floor problem. One site in three scores under 40, and the bottom quarter sits at 36 or below. The top is healthy: 33 sites reach 80, and the 90th percentile of 90 is within 2 points of WordPress. So Next.js is a platform where the best sites do as well as the best WordPress sites and the typical site does not. That bimodal shape is consistent with the idea that the framework gives you the ability and leaves the work to you.

Shopify is narrow. The middle half of 16 stores falls between 64 and 72, and the 90th percentile is 80. That is plausibly what a hosted platform does: stores share one stack, so they differ less from each other, at the cost of a lower ceiling. Sixteen stores is a small sample, so read the shape and not the decimals.

The same checks, on equal terms

The mean score weighs checks differently on different sites. To compare platforms on equal terms we need checks that every site is scored on. Ten checks qualify: B2, C1, C2, C3, D1, D2, D3, E1, E3 and E4 have a pass, partial or fail result on every one of the 684 hosts in the five platform rows. The pass rate for each is below, as a share of the sites on that platform.

On these ten checks Next.js trails WordPress by 3.6 points, not 13.7. Next.js beats WordPress outright on C2 (50.9% against 49.2%), C3 (66.7% against 59.3%), B2 (42.4% against 26.5%) and E1 (92.1% against 85.2%). It loses badly on D3 (43.0% against 93.1%) and E4 (54.5% against 82.5%).

Those two losses have a clear cause. D3 passes on WordPress because core adds an api.w.org Link header and a head link to the REST API on every page, a point we covered in the Link header study. E4, the canonical host check, loses points when both the apex domain and the www host return a page, a failure that depends on how the host is configured and is covered in the canonical host study. So on these ten checks the Next.js gap comes down to two specific shortfalls, both with documented fixes.

Astro leads this table with 76.0%, and Shopify is a close second with 74.4%. The Shopify figure rests on 16 stores. Its profile is lopsided: 75.0% on C1 and 87.5% on C2 but 25.0% on B2 and 43.8% on D3.

Where the platform scores diverge: the capabilities dimension

If the ten shared checks produce a 3.6 point gap, something else produces the remaining 10 points. The stored reports show it.

AIScan groups its checks into dimensions: discoverability, content, bot access, capabilities and, where commerce applies, commerce. Each dimension has a weight, and the overall score is the earned points divided by the weight of the checks that apply. We rebuilt scores this way in the blocked-probe study and matched the stored mean exactly. The weight is not the same on every site. We read the capabilities dimension's weight out of each stored report and averaged it by platform:

On a Next.js or Astro site the capabilities dimension is almost a third of the score. On a WordPress site it is 2%. Three of its checks are P1 (API discovery), P4 (OAuth discovery metadata) and E2 (an OpenAPI-style description). The status mix for those three shows the mechanism:

The pattern is unambiguous. On Next.js and Astro sites a missing API catalogue, OAuth metadata file or OpenAPI description is a fail. On WordPress and not-detected sites the same absence is info, a status with weight zero that leaves the score untouched. The stored reports for these platforms contain no failure on P1, P4 or E2 at all. Each stored report carries an isApp flag in its platform data. It is true on every one of the 200 Next.js and Astro reports and false on every WordPress, Shopify and not-detected report. We read this from the stored reports and have not read the scorer's code. The behaviour matches what an "app" classification would do: a site that looks like an application is expected to publish machine-readable interfaces, and a site that looks like a content site is not.

That may be a sensible rule. An application with a login and an API is a different thing from a brochure site, and P4 only makes sense for something that issues tokens. The trouble is that the flag appears to follow the framework, not the site. A Next.js marketing page with no API, no login and no OAuth is classed as an app because its homepage loads a /_next/static/ asset, and then it is marked down for not publishing an OAuth file that it has no reason to publish. The size of that effect is visible in the Next.js group:

Of 165 Next.js sites, 120 (72.7%) fail all three and average 41.6. The 18 that fail none average 94.7. On Astro, the 9 sites that fail none average 99.8 and the 15 that fail all three average 37.9. These groups differ in other ways too, since a site that publishes three machine-readable files is probably careful about the rest. But a 53 point spread inside one framework is a long way from "platform predicts score". On these two platforms, the number of capability files published decides most of the score.

We cannot rebuild the exact counterfactual, since the stored per-check weights do not reproduce the stored overall score for app-classified sites the way they do for the others (a plain earned-over-weight rebuild lands within a point of the stored score on 116 of 189 WordPress sites and on 19 of 165 Next.js sites). So we do not publish a "Next.js without the penalty" number. The direction is clear and the magnitude on the ten shared checks is 3.6 points.

Which check is weakest on each platform

C1 is the weakest on four of five rows. We took apart C1's own measurement in the Markdown study and found that 38.1% of its passes carry a non-Markdown content type, which means even the low pass rates here are generous. Serving Markdown to agents is the least adopted habit on every platform we can measure, and the platform with the best C1 rate (Shopify, 75.0%) is the clearest case: when we looked on 8 October, 12 of 17 Shopify stores passed with a non-Markdown content type and one served real Markdown. Treat that figure with the same caution.

B2 is the second recurring weakness. Between 25% and 27% of sites on three platforms name an AI crawler in robots.txt in a way the check accepts. Astro's 71.4% is the outlier.

"Not detected" is not a platform

The largest row in the table is the one with no name. 279 sites, 38% of the corpus, have no detected platform, and they score 46.3 on average. It is tempting to read that as "custom stacks score badly". Two things argue against it.

First, the bucket is partly a firewall bucket. The blocked-probe study found that a scanner refused at the homepage cannot fingerprint anything, so a refused site lands here. Re-running today a slightly looser pattern for a refused probe (a failing C1, C2 or D1 row whose evidence names 403, 429 or a 5xx) finds 80 of the 279 sites. Those 80 average 21.1. (The blocked-probe study counted 75 of 270 with its stricter pattern and an earlier, smaller corpus.) The other 199 average 56.5, which is 10 points above the bucket's headline mean and 10 below WordPress.

Second, the capabilities dimension is nearly absent here, with a mean weight of 2.0, so the not-detected bucket is scored the way WordPress is, on discoverability, content and bot access. On the ten shared checks it passes 38.5% of the time against WordPress's 68.2%. Part of that is the blocked sites, whose D1 and D2 results are fails. Part of it is that a site with no recognisable stack is less likely to have a generator writing its robots.txt, sitemap and canonical redirects. D3 is the sharpest case: 27.2% against 93.1% for WordPress, and the difference is the REST API link that WordPress adds for free.

So "not detected" is better read as the sites nobody has automated for. It is not a platform to compare against.

What each platform's owners can do

The data points at different first moves.

WordPress. The floor is high and the ceiling is the opportunity. The weakest checks are C1 (25.4%) and B2 (26.5%), and C2 sits at 49.2%. Those are all single-file jobs: an AI-bot block in robots.txt, an llms.txt file and a Markdown route. ThinkRank fits the first two jobs, because it manages robots.txt, robots meta, schema and llms.txt from one place instead of several plugins competing over /robots.txt, and it imports settings from Rank Math, Yoast, AIOSEO and SEOPress, so the switch does not mean re-entering anything. Rank Math, Yoast and AIOSEO can also edit robots.txt. The rule that matters is that exactly one plugin owns each file. The WordPress setup guide walks through it.

Next.js. Decide first whether your site is an application. If it is, the three capability files (P1, P4 and E2) belong on your list, and the Next.js setup guide covers them. If it is a marketing site with no API, expect to see three fails that describe a feature you do not have. Do the shared-check work either way: the two largest gaps against WordPress are D3 (43.0%) and E4 (54.5%), both configuration jobs measured in minutes. The canonical host guide fixes E4.

Astro. The top group is excellent and the bottom group is mostly a blocked-probe story. Check what status your host returns to a non-browser client first. Then the weak spots are C1 and E4 (both 62.9%). The Astro llms.txt guide and the Markdown guide for Astro cover the first.

Shopify. Stores score in a tight 64 to 72 band, and B2 is the weakest check at 25.0%. The platform generates robots.txt and most routes itself, so check what Shopify allows before planning a B2 fix. StoreSEO generates llms.txt from products, collections, pages and articles, and handles the schema and AEO basics a store otherwise lacks. It does not change what the platform decides about robots.txt. The Shopify setup guide lists what a merchant can change.

If you would rather check by hand, none of this needs AIScan: curl -I https://yoursite.com/ shows the Link header (D3), curl https://yoursite.com/robots.txt shows what B2 reads, and curl -sI -H "Accept: text/markdown" https://yoursite.com/ shows the C1 response. The scan runs all of them at once and prints the evidence next to the check ID.

What AIScan cannot see here

• Why a site is on its platform. The detector reads signals. It does not know whether a Next.js site was chosen for its team's skills or inherited from an agency.
• Anything about the site's audience. A league table of agent readiness says nothing about whether agents visit, cite or buy from a site. Whether readiness changes any of that is a separate question.
• The size of the scorer's isApp rule. We observed its effect in the stored reports. We could not read its code, so the description of the rule above is an inference from the data.
• Time. Each host contributes its newest scan, from a window of seven weeks. A site that fixed something yesterday and was last scanned last month is counted as it was.
• Small platforms. Lovable (13 sites), Vue (6), Nuxt, Framer and SvelteKit (5 each) and the rest are too few to rank and are left out on purpose.

Product notes for the AIScan team

Four changes would make the table easier to trust.

1. Say why a check applies. A Next.js site that fails P4 should see "scored because the site was classified as an application, on this evidence". The report today shows a fail and the remediation, and the reader has no way to tell whether they are in scope.
2. Classify on the site, not the framework. An isApp flag derived from a login route, an API path or token endpoints is a better predictor of P4's relevance than a /_next/static/ asset.
3. Show the weight of every dimension on the report. The weights differ by up to 14 points between sites, and the overall score is not comparable across them without that number.
4. Publish a platform table that uses the shared checks. If a ranking exists, rank on checks every site is scored on.

We filed the first two as a site issue for the scanner team.

Run it on your own site

Enter your URL at aiscan.site or run npx aiscan-cli yoursite.com in a terminal. Read the capabilities line first: if it shows weight and fails for P1, P4 or E2 on a site that has no API, you are being scored on a feature you do not offer. Then work through B2, C1 and C2 on the bot access and content check pages, D3 and E4 on the discoverability page, and P1, P4 and E2 on the capabilities page. The guides list a fix for every check, by platform. Scan again in a week and compare against the median of your own platform, not against the league table.