SEO

Insights → SEO scores every indexable product, collection, category, page and blog post against a fixed rule set, and lists the ones with issues, worst first.

The storefront publishes schema.org markup, sitemap.xml, robots.txt and RSS from live data. Nothing is exported or regenerated by hand.

Renaming a product, collection or page keeps the old URL working as a permanent redirect.

The report lives at:

Insights → SEO
/admin/seo

It requires the analytics:view permission.

A checklist, not a crawl

The report judges data the app already holds. It does not crawl your storefront, and it does not call an external service.

That choice has a consequence worth understanding: every finding is something you can fix by editing a record, because every finding came from a record in the first place. There is no category of "the crawler could not reach it".

Findings are grouped into seven sections:

• Missing metadata
• Title quality
• Duplicate titles
• Descriptions
• Page copy
• URL slugs
• Image previews

Each row links straight to the record that fixes it.

The thresholds

The rules are fixed, and they are the same for every entity type.

meta title         30–60 characters
meta description   70–160 characters
on-page copy       under 50 characters is flagged as thin

A title shorter than 30 characters is usually not describing the thing; longer than 60 and search results truncate it. The description range works the same way. The 50-character floor on body copy catches the page that was published with a placeholder sentence.

Duplication is checked across entities, not just within a type. Three things are flagged:

• Duplicate titles
• Duplicate descriptions
• Duplicate body copy

Two products sharing a meta description are competing with each other for the same result, which is why the check spans the whole catalog rather than each list separately.

How a page is scored

Every page starts at 100. Each finding costs it points, by severity:

error     25 points
warning   10 points
info       3 points

The weighting is the argument. Four errors take a page to zero; it would take more than thirty info findings to do the same. Working the list from the most severe down is therefore the fastest route to a better score, and the ordering of the report already does that for you.

Structured data

The storefront emits schema.org markup on every relevant page type, built from live data.

A product page emits a Product node carrying:

• Offers
• AggregateRating
• Up to ten Review nodes
• additionalProperty attribute pairs
• keywords from tags
• isRelatedTo links

Collections and categories emit CollectionPage with an ItemList.

Blog posts emit Article.

None of this is a separate thing to maintain. It is generated from the same records you edit in the admin, so a product whose attributes and related links are filled in produces richer markup without any extra step.

Sitemap, robots and feeds

sitemap.xml is built from your published records and revalidates hourly.

It is capped at the sitemaps.org limit:

50,000 URLs per entity type

robots.txt disallows three paths:

/admin/
/auth/
/dashboard/

There is also a Discourage search indexing setting, which flips the whole site to disallow. That is the switch for a staging copy of the store — without it, a staging deployment competes with production in the index.

The catalog is also published as RSS:

/rss/products.xml
/rss/collections.xml

Renaming without breaking links

Products, collections and pages each carry a list of their previous slugs (previousSlugs on the record).

When you rename one, the old slug is folded into that list in the same write — there is no separate step to remember and no window in which the old URL is dead.

A storefront 404 then checks that history and resolves the old address to the current URL as a permanent redirect.

old URL requested
    ↓
404 lookup finds the slug in the record's history
    ↓
permanent redirect to the current URL

Categories are deliberately excluded. A category's URL is a slug path rather than a single slug, and old-URL preservation for them is not implemented. Renaming a category breaks its existing links.

What you set, and where

Per record, you edit metaTitle and metaDescription directly on the record's form.

Store-wide, you set:

• A title template
• A default social image
• A Twitter handle
• A Google Search Console verification token

The store-wide values are the fallback, so a record with nothing filled in still produces a sensible title and social card.

What the AI can do here

AI assistance on this page covers the meta title and description, and nothing else.

It prefills the fields in the form you are editing. Nothing persists until you save. You read it, change it if it is wrong, and save it yourself — there is no path where a generated string reaches the storefront without you agreeing to it.

The same page also carries the Google Merchant panel, showing the product feed's connection and its last sync.

Working the checklist

Open the report and work the rows from the most severe down. The scoring weights mean the errors are where the points are.

Fill in the meta fields on each record as you go, or generate them and correct what comes back.

Publish. The sitemap, the RSS feeds and the structured data all read live data, so they pick the change up on their own.

Then check the Google Merchant panel on the same page for the feed's connection and last sync.

The question to ask on any given row is not "does this rule pass?" but:

Would a person reading this in a search result know what the page is, and would they know it is different from the other twelve pages I sell?

Related