An ecommerce site audit is not a general website audit with products on it. A shop generates classes of problem that a brochure site cannot generate at all, because a shop has filters that multiply URLs, inventory that changes underneath its own pages, copy that arrives from a supplier already published elsewhere, and one page at the end where all the money actually changes hands. Audit a store with a general checklist and you will produce a tidy document that misses every one of them.
This walks through the five problems that belong only to shops, what Google’s own documentation says about each, and how to order the findings so you fix the thing touching revenue first. If you want the general ground covered properly rather than repeated here, our website audit hub is where that lives. Treat the five as your ecommerce SEO checklist, because the longer lists are mostly general website checks with products standing next to them.
What an ecommerce site audit checks that a general audit does not
Start by being honest about the overlap, because most of a store audit is the same work every site needs. The pages have to load, the pages have to be reachable, the right page has to answer the right query, and somebody has to be able to use the thing without a mouse. None of that is special to retail and none of it is repeated here. Our guide to how to conduct a website audit covers the general passes, and SEO performance step by step covers the search side as a procedure you can run.

What is left after you subtract that is small, specific and expensive. Five things exist on a shop and nowhere else.
- Faceted navigation. Filters that combine, and in combining create more addressable URLs than you have products.
- Inventory lifecycle. Pages that stop being sellable while remaining published, which no brochure site has to think about.
- Supplied copy. Product text written by a manufacturer and shipped to every retailer who stocks the item.
- Variants. One product, many sizes and colors, and a decision about how many URLs that should be.
- The checkout. A funnel that search engines never see and that determines whether any of the other work was worth doing.
Those five are the whole argument for treating store audits as their own discipline. A tool will not surface most of them either, which is a separate problem. Our comparison of website checkers sets out what the automated crawlers actually look at, and filters and stock states are mostly not on the list.
Faceted navigation, and how filters generate infinite URLs
This is the defining technical problem of retail search and Google documents it directly. Its crawling guidance describes faceted navigation as a feature that lets visitors change how items are displayed, then says that its most common implementation, based on URL parameters, “can generate infinite URL spaces which harms the website in a couple ways” (Google, Managing crawling of faceted navigation URLs, read 16 September 2026).
The two harms it names are worth quoting because they explain why this matters even when nothing looks broken. On overcrawling, it says “the crawlers will typically access a very large number of faceted navigation URLs before the crawlers’ processes determine the URLs are in fact useless”. On the knock-on effect, it says that “if crawling is spent on useless URLs, the crawlers have less time to spend on new, useful URLs”. Your new products are the useful URLs in that sentence.
The arithmetic is why this escalates so fast, and you can do it for your own store in a minute. Take one category with four filters, each offering five options. Every filter is either unset or set to one of five values, which is six states, and four independent filters give six to the fourth power. That is 1,296 addressable URLs for a single category page. Add a fifth filter and it is 7,776. None of those numbers is a statistic about anybody’s site, it is just multiplication, and that is exactly the point.
So the audit question is not whether you have faceted URLs, it is which ones you have deliberately allowed. Google’s guidance is blunt about the default, saying “Oftentimes there’s no good reason to allow crawling of filtered items, as it consumes server resources for no or negligible benefit”. It sets out two ways to prevent crawling, a robots.txt disallow on the parameter patterns, and moving filters to URL fragments, noting that “Google Search generally doesn’t support URL fragments in crawling and indexing”, which makes fragment-based filtering invisible to crawling either way.
Note what the same guidance asks you to keep open while you close the rest. It suggests you “allow crawling of just the individual items’ pages along with a dedicated listing page that shows all products without filters applied”. That last clause is the part audits miss. Blocking the filter parameters without leaving one unfiltered route through the category can cut off the path to the products themselves, which turns a crawl-efficiency fix into a discovery problem. So the check is two-sided, that the combinations are closed and that a clean path to every product is still open.
The out of stock and discontinued product decision
Every store accumulates pages for things it can no longer sell, and most stores have never made a deliberate decision about them. The audit finding is rarely that the handling is wrong. It is that there is no handling, and each case was settled by whoever happened to be in the admin that day.
Separate the two cases first, because they are not the same problem wearing different labels. A product that is temporarily out of stock is coming back. A product that is discontinued is not. Treating the first like the second throws away a page that was earning, and treating the second like the first leaves you maintaining pages for things nobody can ever buy.
For the temporary case, keep the URL and keep it honest. The page stays, the availability is marked accurately, and the visitor is offered something to do other than leave. Google’s product structured data documentation asks you to “Provide availability data to help customers know when you have a product in stock”, which is the mechanism for saying so in a form a search engine can read.
For the permanent case, the question is whether a genuine replacement exists. If it does, redirect to it, because a redirect is described in Google’s canonicalization guidance as “A strong signal that the target of the redirect should become canonical”, and the page’s accumulated links go somewhere useful. If nothing replaces it, let the URL go rather than redirecting everything to a category page, which teaches nobody anything and lands visitors somewhere they did not ask for.
Why your product descriptions are identical to your competitors’
If you stock other people’s products, your descriptions probably arrived in a feed, and the same feed went to every other retailer carrying that line. This is the most common finding on a store audit and the one owners are most surprised by, because nothing on the page looks wrong. It reads well. It was written by the manufacturer. That is the problem.
Understand what actually happens rather than reaching for a penalty story. Google’s guidance on duplicates is about selection, not punishment. It explains that if you do not specify a preference, “Google will identify which version of the URL is objectively the best version to show to users in Search”. Across the whole web, for identical manufacturer copy, the version it picks is frequently not the small retailer’s.
So the audit output here is not a list of every duplicated description, which on a large catalog is simply the catalog. It is a decision about where original writing is worth buying. Rank your products by revenue, take the head of that list, and write those properly. Everything in the tail keeps the supplied copy, because the arithmetic of rewriting a few thousand descriptions to protect a handful of sales does not work and pretending otherwise is how audits become shelfware.
What counts as writing it properly is narrow. Add what the manufacturer cannot, which is your own handling of the thing. Sizing that runs small, what it ships in, what people return it for, what it replaced. That is information the feed does not contain and no competitor can copy.
Variant URLs, and which version of a product should rank
One shirt in four colors and five sizes is twenty sellable things and somewhere between one and twenty URLs, depending on decisions your platform may have made for you years ago. Google names the concept precisely, saying “Each combination of product attributes is referred to as a product variant”.
Its recommendation is more definite than most people expect. The documentation says “To help Google understand your product variants, make sure that each variant can be identified by a separate URL”, and offers two shapes for doing it, a path segment or a query parameter. So the default answer is not to collapse everything onto one URL and hope.
The canonical handling is where stores get this wrong, and the guidance is specific. It says that if you use optional query parameters to identify variants, “use the URL with the query parameter omitted as the canonical URL”, which keeps the variants addressable while consolidating the signals onto the parent product. The same page also asks you to “Use the same URL in internal links, sitemap files” and canonical tags, which is the check most audits skip and the one that most often explains why a store’s own signals disagree with each other.
While you are in there, look at what else is in those URLs. Google asks for “long-term, persistent URLs” and specifically warns against internally linking to temporary parameters like session identifiers and tracking codes, which is how a store ends up with thousands of one-time URLs it never meant to create.
Auditing the checkout, the only conversion that pays for everything else
The checkout is the strangest thing in an ecommerce site audit, because it is the one part of the store search engines are never supposed to see and the only part where revenue is actually recognized. Every other finding in the document is a bet that more people will reach this page. If this page is broken, every one of those bets loses.

So audit it, but audit it as a function rather than as a search surface. There is nothing to optimize for a query here. There is only whether it works, on the devices people actually hold, on connections worse than yours, with a payment method that is not the one you tested with.
The findings that matter are mundane and they are found by doing, not by crawling. Complete a real purchase on a phone. Complete one as a guest, if guest checkout exists, and note it as a finding if it does not. Complete one with a discount code applied. Watch what happens when a card is declined, because the error state is the part nobody tests and the part that silently returns visitors to the cart with no idea what went wrong.
Then measure the funnel rather than describing it. Count how many sessions reach the cart, how many reach the first checkout step, and how many finish, and you get three numbers that tell you which step is leaking. A store that converts poorly overall usually has one bad step rather than a uniformly weak funnel, and without the step-by-step counts every conversation about it is guesswork dressed as opinion. Those numbers come from your own analytics, so they are measured rather than estimated, which is more than can be said for most figures in an audit.
Speed belongs in this section too, and it belongs here rather than in the general pass, because a slow category page costs you a browse and a slow payment step costs you the order. Our guide to analyzing a website covers measuring that properly instead of trusting a score from a laptop on office broadband.
Product structured data and what it actually earns you
Structured data is the one area where a store gets something a brochure site cannot get, and it is worth auditing for that reason alone. Google’s product documentation says that when you add it, “your product information can appear in richer ways in Google Search results”, and lists what can surface, including price, availability, review ratings and shipping information.
The distinction to check first is which class you should be using. The documentation splits product markup in two, and defines one of them plainly, saying product snippets are “For product pages where people can’t directly purchase the product”. A store where people can buy is the other case, and stores routinely ship the wrong one because a plugin chose for them.
Then check that the markup agrees with the page. This is the actual audit work and it is boring. Markup saying a product is in stock while the page says sold out, a price in the structured data that the template stopped updating, review counts that survived a migration. These do not usually announce themselves, because the page looks correct to a human and the disagreement is only visible to the machine reading the markup.
Keep the expectation honest while you are doing it. Google describes these enhancements as shown at the discretion of each experience, so correct markup makes you eligible and eligibility is not a placement. An audit that promises rich results in exchange for a schema fix is promising something the documentation does not.
What your platform and its version change about the audit
Most of what a store audit finds is decided by the platform and the theme rather than by anything the owner typed. How variants become URLs, whether filters are parameters or fragments, what a sold-out page does, whether canonical tags are emitted at all. So record the platform and, more importantly, the version, because that second thing is where audits find genuine risk.
Adobe Commerce, which most people still call Magento, makes the point well because it publishes dated support windows per release line. Its released versions page shows 2.4.9 released on 12 May 2026 with regular support running to 31 May 2029, while the 2.4.6 line’s regular support ended on 11 August 2026. Adobe’s own advice on that page is that it “recommends installing or upgrading Adobe Commerce to the latest security patch available for each release” (Adobe Commerce Documentation, Released versions, page dated 12 August 2026).
That is the audit point, and it generalizes past Magento to every platform you might be on. The platform is not end of life, but your particular release line can be out of regular support while the store runs perfectly well and shows you nothing. A version check takes a minute and occasionally outranks every other finding in the document.
If you sell across borders the platform question widens again, because currency, language and country targeting are mostly platform decisions too. That ground is its own audit, covered in our explanation of an international SEO audit.
How to sequence the findings when everything looks urgent
A store audit produces more findings than a general one, and the temptation is to order them by severity labels a tool assigned. Do not. Order them by distance from the checkout, because that is the only ranking that reflects what a fix is worth to you.
That gives you a sequence you can defend to whoever is paying for the work. Anything blocking a purchase comes first, because it is costing money today. Anything affecting your best-selling products comes second, since the revenue is concentrated and so is the return. Crawl waste comes third, because it is real but it compounds slowly rather than bleeding now. Catalog-wide tidying comes last, and a good deal of it should never be done at all.
Set the re-measure date before you fix anything, and record what the numbers were on the day of the audit. Without that you cannot tell a recovery from a seasonal upswing, which on a retail site is a very easy mistake to make in either direction. Our guide to benchmarking SEO covers establishing that baseline honestly.
Then write it so somebody will act on it. A finding needs the page, what is wrong, what it costs, and who changes it. Findings that name no owner do not get fixed, whatever priority label they carry. How that document should be built is covered in our breakdown of what goes in an SEO report.
What we would check first, and what to ask us
Given a store and an afternoon, we would do four things in this order. Buy something on a phone and watch where it hurts. Count the indexable URLs against the number of products, because the gap between those two numbers is the faceted navigation story and it takes one crawl to see. Sort the catalog by revenue and read the top twenty descriptions to find out whose words they are. Check the platform version against its support window.
That deliberately leaves most of a conventional audit undone on day one, and it is the right trade. Those four cover the problems that are specific to selling, and the general passes keep just as well for day two.
Now point this at us, because we sell audits and you should read the previous paragraphs with that in mind. If an agency hands you a store audit, ask how many of its findings could have been produced without opening your store, since a document that is mostly generic crawler output is a template with your logo on it. Ask which findings touch the checkout. Ask what it decided not to tell you to fix, because a list with nothing deprioritized is a list nobody thought about. Those questions apply to our documents as much as to anyone else’s.
The cheapest place to start is your own checkout on your own phone, and it costs nothing. If you would rather have somebody else look first, our free website audit is where to start.



