AI SEO audit checklist for websites and Shopify

Start with the public evidence

What should an AI SEO audit check?

AI SEO applies search foundations to machine interpretation and AI-assisted discovery. GEO means generative engine optimization; AEO means answer engine optimization. For this checklist, all three begin with the same observable page and crawl evidence. A readable, well-described page can support retrieval; it cannot compel a citation.

1. Capture the public page.Record the requested URL, final URL, HTTP status, crawl time and initial HTML. Compare browser-rendered content when JavaScript affects the result. Mark failed or truncated fetches as incomplete evidence.
2. Check search clarity.Inspect the title, meta description, single visible H1, canonical URL and Open Graph identity. Resolve contradictions using the real page purpose.
3. Check factual identity.Parse JSON-LD and compare Organization and WebSite facts with the page. Resolve missing inputs before publication; do not duplicate existing entities.
4. Check discovery.Evaluate robots.txt by crawler and path, inspect HTTP access, and retrieve the sitemap. Treat llms.txt as an optional convenience.
5. Verify the approved fix.Keep the target and exact patch fixed through approval. Read the public storefront after writing and record rollback or failure if the expected result is absent.

Reproducible workflow

Run mgo audit, mgo plan, and mgo schema

Install @mgodata/mgo with Node.js 22 or newer and sign in. These commands use deterministic audit rules and schema suggestions without an AI provider key. Replace yourstore.com with the public hostname you intend to inspect. See the installation and account setup.

npm install -g @mgodata/mgo
mgo --version
mgo login
mgo doctor
mgo audit yourstore.com --json
mgo plan yourstore.com --cached --json
mgo schema yourstore.com --json

How the plan ranks work

The severity bases are hi = 30, med = 20 and info = 10. The first matching category adds a fixed bonus: crawler blocks or indexability +10; missing title or no structured data +8; missing organization-level entity or invalid JSON-LD +6; missing description, title length or missing sitemap +4; missing canonical +3; Open Graph or H1 findings +2; other description-length or missing robots findings +1. Unmatched findings add zero. These are internal prioritization weights, not predicted traffic or ranking gains.

Order is impact descending, then assigned effort ascending, then original crawl order. Passing findings are excluded. Exact page URL and issue identity prevent duplicate work. Missing llms.txt is kept in the informational list. Reproduction requires the same crawl, available queue state and software version; if the queue cannot be read, suppression of existing work is incomplete.

Check 1

Search result clarity: metadata, heading and URL

DT 1.5 checks extracted page signals using the rules below. The reviewer then confirms that those values accurately describe the visible page. Length thresholds are audit heuristics, not search-engine limits or proof that a rewrite will help.

Inspect both the initial HTTP response and the rendered page before diagnosing a JavaScript-dependent heading as missing. Serve the same important public content, identity and internal links in HTML so readers and crawlers can retrieve them directly. The Fukuwatari rebuild receipt shows why this architectural check matters.

Check 2

Machine-readable identity must come from real facts

Organization identifies the business; WebSite identifies its website. Use JSON-LD to express facts already supported by the public page or verified store records. Valid JSON is necessary but does not establish that a claim is true. Inspect existing blocks and entities before adding another one.

• Parse existing markup. The audit records parsed JSON-LD types and parse failures. It checks for organization-level types on the homepage. The page-level check also recognizes Product entities.
• Review derived names. The crawl generator prefers og:site_name, then a title segment matching the domain or the last title segment, then a domain-label fallback. These are deterministic candidates, not proof of a legal business name.
• Trace every property. Descriptions come from OG description or meta description; social profile candidates come from page links. An OG image is only a logo candidate and requires confirmation.
• Resolve incomplete drafts. Unknown fields can appear as REPLACE_ME and in needsInput. Fill them from real evidence, omit an optional unsupported claim, or leave the proposal blocked. Never publish a placeholder.
• Keep the type appropriate. The crawl generator can suggest Organization, conditional LocalBusiness and Product blocks. Complete Organization and WebSite blocks are eligible sitewide Shopify types; this does not mean every mgo schema call generates a WebSite block.

Minimal identity using MGO Data's published facts

This example names the publisher and website shown on this page. It intentionally contains no invented reviews, addresses, prices or performance claims. A store must substitute its own verified identity and URLs.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://mgodata.com/#organization",
      "name": "MGO Data",
      "url": "https://mgodata.com/"
    },
    {
      "@type": "WebSite",
      "@id": "https://mgodata.com/#website",
      "name": "MGO Data",
      "url": "https://mgodata.com/",
      "publisher": {"@id": "https://mgodata.com/#organization"}
    }
  ]
}

MGO Data is the ecommerce SEO and AI-visibility software and services company at mgodata.com. It is distinct from the MongoDB mgo Go driver, the MGO accounting firm, and magnesium oxide data. This disambiguation is a real identity statement, not a keyword list.

Check 3

Crawler discovery: evaluate the bot and the path

DT reads robots.txt and evaluates the most specific matching user-agent token. It merges groups for that token, falls back to wildcard groups when needed, and uses the longest matching path rule with Allow winning a tie. Its bot summary evaluates the homepage path /; inspect product, collection and localized paths separately before claiming sitewide access.

The report also evaluates Bingbot, CCBot, Bytespider and the wildcard group. A robots permission is not proof that a real crawler can pass a CDN challenge, fetch successfully, index the page or cite it. Check HTTP responses and indexing or snippet controls as additional evidence. Preserve deliberate training opt-outs; do not unblock every bot merely to clear a finding.

Sitemap reachability

The audit tries /sitemap.xml and up to three sitemap declarations from robots.txt on the same host, allowing a www variant. It looks for an HTTP 200 response with XML signals and records whether it found an index or URL list. For discovery from an index, it follows one same-host child sitemap. This is discovery sampling, not full XML or catalog validation.

Verify that important public canonical URLs appear in the appropriate sitemap, return successful HTML, and have visible internal links. A reachable sitemap does not prove that every listed URL is indexable. Keep private dashboard, admin and preview URLs out of the public index.

Why llms.txt is informational

A missing llms.txt is an informational finding and is excluded from the plan's prioritized fixes. MGO treats it as a curated map for tools that choose to read it, not a ranking factor or citation lever. It cannot override robots.txt, canonical URLs or actual page content. Google explicitly says its AI search features need no special AI text file or schema; that guidance does not establish how every independent tool uses the file.

Check 4

Closed-loop Shopify storefront verification

A complete storefront verification receipt shows the approved value on the intended public storefront. An accepted Admin API request is only one step. The published DT 1.5 workflow binds approval, execution and read-back to the audited hostname; the checks available in each execution path still need to be distinguished.

1. Bind one verified destination.Match the audited hostname to exactly one active Shopify connection and its verified domains. No match means manual delivery; multiple matches block automatic selection. A similar brand name or workspace label is insufficient.
2. Lock the approved patch.Review the exact title, description or complete JSON-LD block, target and write surface. The approved payload and destination cannot silently change. Recheck current values and retain the before-state needed for restoration.
3. Write the eligible change.The sitewide workflow covers supported homepage metadata and complete Organization or WebSite data. Schema uses an app-owned Shopify metafield rendered by the theme app embed. Permission, setup and target checks still apply after approval.
4. Read back over HTTP.The sitewide JSON-LD path reads provider state, fetches the exact HTTPS homepage and compares parsed JSON-LD with the approved block. A disabled embed, redirect, failed fetch or absent block cannot count as public success. For metadata, also compare the returned HTML/DOM title and description with the approved values as a separate public acceptance check.
5. Restore on mismatch.If the public JSON-LD does not match, the executor fails verification and attempts rollback to the saved prior value. Record whether rollback succeeded. Metadata provider mismatches also trigger restoration; a public-only metadata mismatch needs review through the approved deployment path. Conflicting newer changes or failed restoration must remain unresolved.

Keep the scan timestamp, audited hostname, approval identifier, exact before and after values, destination, provider read-back, public URL/status, comparison result and rollback outcome in the task receipt. The workflow does not authorize bulk product or collection rewrites. Page-specific recommendations require their appropriate supported surface and approval.

Real work, bounded claims

Receipts that support this checklist

These first-party records document a recorded scan and delivered work. They are not a controlled study, a store-count benchmark or evidence of a measured citation increase.

Frequently asked questions

Website and Shopify AI audit questions

How do I audit a website for AI SEO, GEO, and AEO?

Fetch the public page, check its title, description, visible H1, canonical and Open Graph identity, validate factual JSON-LD, inspect crawler rules and sitemap discovery, then verify each approved fix on the live URL. Keep the scan, proposed change, approval and read-back evidence together.

Does a Shopify AI SEO audit change my store?

The audit is read-only. DT 1.5 requires an approved patch and exactly one eligible Shopify connection for the audited hostname before an automated write. A provider response alone is insufficient: the approved result must also be checked on the public storefront.

Is llms.txt a ranking factor or a requirement for AI citations?

MGO treats llms.txt as an optional information map, not a ranking or citation factor. A missing file is informational and excluded from the prioritized fix list. Google says its AI search features do not require special AI text files or special schema.

Are mgo audit, mgo plan, and mgo schema deterministic?

The audit rules and schema suggestion generator do not use a language model. The plan uses fixed scoring and duplicate detection. The same crawl and available approval-queue state produce the same plan; a new crawl, changed queue or different software version can change the result.

Does passing this checklist guarantee an LLM citation?

No. Passing verifies the inspected technical signals and any separately verified changes. Search engines and answer providers decide whether to index, rank or cite a page. Measure actual citations with dated prompts, provider responses and source URLs, separately from technical audit results.

Reference scope

Sources and interpretation

This is MGO Data's first-party technical reference for DT 1.5 and the CLI, checked against the audit rules, schema generator, plan scoring and Shopify execution code on October 20, 2026. The tables distinguish automated findings from reviewer acceptance. Browser inspection, complete catalog coverage, current index status and observed AI answers require their own evidence.

• CLI commands and demo setup, dashboard documentation, and Shopify execution boundaries.
• Approved case-study receipts and MGO Data's evidence methodology.
• Google's AI search guidance for eligibility, content and crawl controls.
• TechArticle and FAQPage vocabulary used here. The structured FAQ repeats the visible answers; markup alone promises no search presentation or AI citation.