There is no single correct interval. A workable default for most ecommerce stores is one full review a year, a short indexation check every month or two, and an unscheduled review within about a week of any change that touches URLs, templates, sitemaps, or crawl rules.
Stores that ship template changes weekly, run large catalogs, or have several people editing pages are closer to a full review every three to four months. A forty-product store that has not changed since launch can go a year or more between reviews and still be fine.
The reason a fixed calendar does not work: an audit earns its cost when something has changed that could break how search engines read your store, or when the cost of being wrong has just gone up — a migration, a peak season, a content budget about to be spent. Both of those arrive on their own schedule, not on yours.
One more constraint that gets ignored: do not audit faster than you can fix. A findings list nobody has time to act on is not a diagnosis, it is a backlog.
Audit triggers: the events that start the clock
Most of the value in auditing sits here rather than in the calendar. Each of these events changes what search engines can see, and each one has a window where a problem is still cheap to fix.
| Trigger | Review when | Check first |
|---|---|---|
| Migration, replatform, or URL-structure change | Before launch, immediately after launch, and again once recrawling exposes what changed | Redirect coverage, canonicals, sitemaps, and indexed URL counts. Google's site move guidance asks owners to watch indexed counts fall on the old site and rise on the new one, and to check regularly for unexpected crawl errors. The redesign and migration guide works through all three passes in detail |
| New theme, or an edit to a page template | Within a week of the change reaching production | Titles, H1s, and body copy in the rendered HTML; structured data; internal links that the template used to output |
| An app or plugin that touches URLs, sitemaps, or markup was added or removed | Within a week | New parameter or filter URLs, duplicated or conflicting markup, and any change to robots directives or canonical output |
| Organic clicks or impressions dropped noticeably | Immediately, and start in Search Console rather than in a crawler | The Performance report first. Google's guidance on debugging traffic drops works through impressions versus position, then the Page Indexing, Crawl Stats, Security Issues, and Manual Actions reports |
| A core update finished rolling out and your positions moved | Wait at least a full week after the update completes | Google's core update page asks site owners to compare the week after completion with the week before the rollout, and warns against quick fixes made on rumour |
| Catalog grew sharply, or you turned on filters and facets | Within a month | How many crawlable URLs the new combinations create, and which of them deserve to be indexable at all |
| You took over a store somebody else built | Before spending money on anything else | Everything. This is a baseline, not a re-check, and it is the single highest-value audit on this list |
| You are about to fund content, ads, or a redesign | Before the spend is committed | Whether the destination pages are indexable, distinct from each other, and pointed at demand that exists |
| Seasonal peak is approaching | Eight to twelve weeks out | Enough lead time that fixes ship, get re-crawled, and settle before the traffic arrives |
The pattern behind the table: every trigger is either a change to what search engines see, or a moment when a mistake becomes expensive. If neither applies, the honest answer is that a fresh audit will mostly repeat the last one.
Baseline cadence when nothing has broken
Between triggers, set the interval by how fast the store changes and how much is riding on organic search. These are starting points to adjust, not rules.
| Store profile | Full review | Between full reviews |
|---|---|---|
| Small catalog, rare changes, no developer on hand | Once a year | A short indexation check each quarter |
| Regular merchandising, occasional template edits, one or two editors | Every six months | A short check monthly |
| Frequent deploys, large catalog, or several people editing pages | Every three to four months | A short check monthly, plus a template check after any release that touches page templates |
| Migration or replatform year | Before the move, immediately after launch, and again when indexed URL counts stop moving meaningfully | Weekly indexed-URL monitoring until the counts stop moving |
| Organic search is the main acquisition channel | Every six months at minimum, regardless of change rate | A short check monthly, because the cost of a silent break is highest here |
| Brand new store, few public pages, no rankings yet | Once there is a real catalog and pages that have been live long enough to be crawled | Auditing an empty store mostly produces a to-do list you already have |
What this looks like in a real store
Four ordinary ecommerce situations, and the cadence each one implies.
A Shopify theme update goes live
Theme code writes titles, headings, breadcrumbs, and product markup. A theme change can silently drop a template's H1 or stop emitting product structured data across the whole catalog at once. Check within a week, on at least one collection and two product templates, in the rendered source rather than in the theme editor.
A WooCommerce filter plugin is switched on
Attribute filters can turn a few hundred products into a very large number of crawlable combinations overnight. Google's faceted navigation documentation covers the trade-offs. Review within a month, and decide which facet combinations have genuine standalone search value before deciding what to block or canonicalise.
Seasonal collections rotate out
Stores that unpublish seasonal collections each year tend to orphan products and break the internal links that guides pointed at. This is a good fit for the short monthly check: confirm that priority products are still reachable through navigation, and that last season's guide links do not lead to removed pages.
The store moves to a new platform
The highest-risk event on the list, and the one where a scheduled annual audit is worst suited. Review before launch, immediately after launch, and again once recrawling has exposed the effects and indexed URL counts have stopped moving meaningfully. Between those points, monitoring is the job — not a fresh full review each week. See what to check at each of those three moments.
The short check between full audits
A monthly or quarterly check is not a small audit. It is a fixed set of questions with yes or no answers, run in fifteen or twenty minutes, whose only purpose is to catch a silent break early.
- Are indexed page counts roughly where they were last time, with no sudden step up or down?
- Do your five or ten most important URLs still return successfully and still carry a canonical pointing at themselves?
- Do those pages still have their intended title and H1 in the rendered HTML?
- Has any new type of URL started appearing — filters, search results, tracking parameters, duplicated variants?
- Are priority collections and products still reachable from navigation and from the pages that used to link to them?
- Has anything in Search Console's coverage or manual-actions reporting changed since last time?
If all six are clean, the full review can wait for its baseline slot. If one is not, you have your trigger. The free ecommerce SEO audit checklist covers the longer ten-step version for when the answer is "something changed".
What a public-page audit cannot tell you
Cadence advice is worth little without knowing what a review of public pages can and cannot establish. Our own audit works from publicly observable evidence plus third-party keyword data, and that boundary is real.
A public-page review can
- Find template-level problems that repeat across a catalog
- Show where titles, canonicals, and structured data contradict the visible page
- Show which important pages are poorly linked internally
- Compare the pages you have against search demand you do not currently answer
- Put findings in an order somebody can execute
It cannot
- Prove why traffic dropped — that needs Search Console history, analytics, and often server logs
- Confirm how Google is actually crawling and indexing every URL
- Detect a manual action, which only appears in Search Console
- Measure conversion or revenue impact
- Cover every URL in a large catalog from a ten-page sample
- Promise a ranking, traffic, or revenue outcome
This matters for cadence in one specific way: if your trigger is a traffic drop, the first move belongs in Search Console, not in a crawler and not in a paid audit. A sampled public-page review can suggest causes and rule things out. It cannot prove what happened.
Signs you are auditing too often
- The last audit's "fix now" items are still open when the next one starts.
- Two consecutive reports say substantially the same thing.
- Findings are being generated faster than anyone can validate them on more than one URL.
- The audit has become a monitoring habit. Monitoring is cheaper and should be doing that job.
Auditing too rarely has an obvious failure mode: something breaks in March and gets found in November. Auditing too often has a quieter one — it feels productive, costs real attention, and displaces the fixing.
Common questions
Is once a year enough?
For a store that changes rarely and has no migration, redesign, or traffic drop in the period, usually yes — as long as something cheap is watching for breaks in between. Once a year with no monitoring means a template problem introduced in month two goes unnoticed for ten months.
Should I run an audit after every Google core update?
Only if your own data moved. Google asks site owners to wait at least a full week after a core update finishes before analysing, and to compare that week against the week before the rollout started. If your positions are stable across that comparison, there is nothing for an audit to act on. If they moved, the useful review is about content quality and page purpose, not a rushed technical sweep.
How often should a brand-new store be audited?
Wait until the catalog is real and the pages have been live long enough to be crawled. Before that, an audit mostly returns the launch checklist you already have. The genuinely useful early moment is just after the store is publicly live and before you start spending on content or ads pointed at it.
Does an automated site scanner replace this?
It replaces part of it. Scanners are good at continuous monitoring — broken links, status codes, missing tags, sudden count changes — and that is exactly what the short between-audit check needs. What they do not do is decide which findings matter for your store, judge whether two pages are competing for the same purpose, or put fixes in a sensible order. Use a scanner for the monitoring rhythm and a review for the decisions.
How long does a focused audit take?
A self-run first pass over ten representative pages is realistically twenty to forty minutes of concentrated work if you already know the store. Our fixed-scope review of up to ten representative URLs is delivered within 48 hours. Neither is a full-site crawl of a large catalog, which is a different and longer job.
Should the same person audit every time?
There is a trade-off worth naming. The person who built the store finds problems faster and misses their own assumptions. An outside review is slower to orient and better at seeing what has been normalised. A reasonable pattern is to run the routine checks in-house and bring in an outside look at the baseline interval, or when a decision is expensive.
When the answer is "something changed"
StoreAuditLab reviews up to 10 representative public URLs by hand, adds up to 10 Ahrefs-backed keyword and page opportunities, and delivers a prioritized plain-English PDF in 48 hours. $100 one time, fixed scope, no implementation upsell.
Get the $100 audit →