WooCommerce AI Readiness Audit: What Our Own Store’s Checkup Found (and Fixed)

We built a free WooCommerce AI readiness audit at imagewize.com/woocommerce-checkup — a tool that scans a store the way ChatGPT, Gemini, and Perplexity would, checking whether an AI shopping assistant can actually read the product, find the price, and trust the site enough to recommend it. On August 31, 2026, we ran it against our own store: the Elayne theme’s live WooCommerce demo at demo.imagewize.com/store. It came back a C.

Worse, it used to be a B. The score had quietly dropped from 88 to 74 since our last scan on June 14 — fourteen points, with nobody noticing, on a store we built to show off what our own WordPress theme can do. So we opened the report, traced every failing check back to its actual cause, and fixed all of them the same afternoon. This is what broke, why, and what shipped as a result — including a real fix to the Elayne theme itself.

The Checkup, in Numbers

The tool grades four categories, plus a rollup for overall AI readiness. Here’s where the store landed before we touched anything:

Of the 21 individual checks behind the AI Readiness score, 9 passed, 6 came back as warnings, 5 failed outright, and 1 was skipped (it couldn’t verify a merchant feed externally). The failures are what mattered — a C isn’t a vague vibe, it’s five specific, fixable things.

Five Things It Flagged

• Mixed content. One insecure http:// asset reference on an otherwise HTTPS page.
• Missing meta description. No <meta name="description"> tag at all — the single most basic on-page signal, and it wasn’t there.
• Conflicting canonical and noindex signals. A canonical tag pointed at the page, while the page was also marked noindex.
• No H1. Not “a weak H1” — no H1 heading anywhere on the page, which is the single most important heading for both AI parsers and visitors to understand what the page is about.
• Publicly listed usernames. A security check, not an AI check, but it failed too: /wp-json/wp/v2/users returned real WordPress usernames to anyone who asked.

What Was Actually Wrong

A checkup that just lists symptoms isn’t that useful. We wanted to know why each one happened, because the “why” is what tells you whether you have one bug or five.

A Missing H1, Baked Into Our Own Theme

The store’s homepage opens with a hero section — “Refined Elegance Defined” in large type over a leather bag photo. That’s the obvious H1 candidate, and visually it reads like one. In the markup, it was a heading block with no level specified, which Gutenberg defaults to an H2. Nothing else on the page carries a heading above that, so the page genuinely had zero H1 elements.

That hero isn’t hand-written page content — it’s a reusable block pattern that ships with the Elayne WordPress theme, the same theme this demo store exists to showcase. One missing attribute in one pattern file meant every site built from that pattern started life without an H1. We fixed the pattern source, shipped it as Elayne 4.9.3, and ran it through the theme’s full four-pass validation suite (structural, compliance, a real-browser runtime check, and CI) before merging. If you’re weighing WooCommerce themes and want this level of scrutiny applied to your own build, that’s exactly the kind of work covered on our WooCommerce development services page.

A Stale HTTP Image URL

The same hero section’s background image was pointing at http:// instead of https:// — hardcoded at some earlier point when the pattern was inserted into the page, and never refreshed after the site moved to full HTTPS. WordPress themes generate a lot of their own URLs dynamically, but once a URL like that gets saved into a page’s content, it’s frozen at whatever value it had that day. Fixing the theme code doesn’t fix pages that already used it; we had to patch the saved content directly, on top of the theme fix.

No SEO Plugin, At All

This was the one that actually surprised us. imagewize.com runs The SEO Framework, and we assumed every site in our stack did too. The demo site — a separate WordPress multisite install that hosts nine theme showcases, Elayne’s store demo among them — had no SEO plugin active anywhere. Not misconfigured. Not disabled by mistake. Never installed.

That one gap explained three of the six warnings on top of the meta description failure: no Organization schema on the homepage, and no discoverable sitemap. We added The SEO Framework to the demo site’s Composer dependencies, activated it on the store subsite, and set a meta description. Organization schema and the sitemap started working immediately, as a side effect of just having a real SEO plugin running — they weren’t separate fixes.

Exposed WordPress Usernames

WordPress’s REST API exposes a /wp/v2/users endpoint by default, and by default it’s public. Visit it on an unprotected site and you get back real usernames — in our case, three of them, feeding directly into any brute-force login attempt against /wp-login.php. This isn’t an Elayne problem or a demo-site problem; it’s stock WordPress behavior, and none of our three production sites had ever closed it.

<?php

/**
 * Plugin Name: Restrict REST User Enumeration
 * Description: Blocks unauthenticated access to the /wp/v2/users REST
 * endpoints so usernames can't be harvested for brute-force login attempts.
 */

add_filter('rest_endpoints', function ($endpoints) {
    if (is_user_logged_in()) {
        return $endpoints;
    }

    foreach ($endpoints as $route => $handlers) {
        if (str_starts_with($route, '/wp/v2/users')) {
            unset($endpoints[$route]);
        }
    }

    return $endpoints;
});

We deployed it to all three of our own WordPress sites — the demo store, imagewize.com, and aseonomics.com — not just the one the checkup happened to scan. A gap like this is never really about one page.

What We Left Alone

Not every flagged item got changed. The canonical-tag-versus-noindex conflict is real, but it’s not a bug: demo.imagewize.com is deliberately blocked from search engines site-wide. It exists to show off our WordPress themes in a live environment, not to compete for rankings under our own name, and having nine theme showcases with placeholder business content indexed as if they were real businesses would be actively worse for us. The checkup is correct that the signals look inconsistent to a crawler. That inconsistency is the accepted cost of a decision made for other reasons, not something to “fix” by turning indexing on.

We also left llms.txt alone. It’s genuinely cheap to add, and our own tool flags it, but server-log data from AI shopping assistants shows they rarely check for it in practice yet — not worth prioritizing over things that measurably matter today.

The Point of Running This on Ourselves

We built the WooCommerce checkup because we kept telling clients the same thing — a message we first laid out in Will ChatGPT Recommend Your WooCommerce Store?: AI shopping assistants are already recommending products, and most WooCommerce stores have never been checked for whether an AI can actually read them. It would have been easy to ship that message without ever pointing the tool at our own storefront. We didn’t skip that step, and it’s a good thing we didn’t — a theme-level bug that had been shipping with every new Elayne install since it was written is a very different kind of finding than a typo in a meta tag.

One thing the checkup did confirm as already working: cookie consent. It detected the Warder Cookie Consent signature in the page and passed the check outright — no fix needed there, because it was already active on the demo site before this audit started.

Frequently Asked Questions

• What is an AI-readiness checkup for a WooCommerce store? A scan that checks whether an AI shopping assistant like ChatGPT, Gemini, or Perplexity can actually parse your store — reading product prices from raw HTML, finding valid Product schema, seeing an FAQ or Organization block, and confirming nothing blocks AI crawlers in robots.txt — alongside standard speed, accessibility, and security checks.
• Why did a WordPress theme’s own demo store fail its AI-readiness score? In this case, one attribute missing from a Gutenberg block pattern (a heading with no level set, defaulting to H2 instead of H1), combined with the demo site never having an SEO plugin installed. Both were structural gaps in the site’s setup, not content problems.
• Does a missing H1 tag actually matter for AI and SEO? Yes. The H1 is the strongest single signal a page gives about what it’s actually about, for both search crawlers and AI parsers extracting page structure. A page with no H1 at all — not a weak one, none — is missing that signal entirely.
• Is WordPress REST API user enumeration a real security risk? Yes. The /wp/v2/users endpoint is public by default in WordPress and returns real usernames, which feed directly into brute-force login attempts against wp-login.php. It’s a stock WordPress behavior, not specific to any theme or plugin, and most sites never explicitly close it.
• Should every page on a site be indexed by search engines? No. A canonical tag alongside a noindex directive looks like a conflict to an automated scan, but it can be a deliberate choice — for example, a theme demo or staging environment that’s meant to be reachable and functional without being ranked under a brand’s name.