Magento is a serious platform for stores with complicated catalogues, multiple store views and real merchandising requirements. It is also, out of the box, extremely good at generating URLs.
That is the root of most Magento SEO problems. A Shopify store with 800 products has roughly 800 product URLs. A Magento store with 800 products, layered navigation switched on across six filterable attributes and three store views, can expose Google to hundreds of thousands of crawlable URLs, nearly all of them variations of pages that already exist.
Generic ecommerce SEO advice does not cover this, because the causes are specific to how Magento is configured. Here are the ones that matter, in the order they usually cost you the most.
Layered navigation is the biggest single problem
Every filter combination a shopper can click produces a crawlable URL. Six attributes with five values each is not thirty URLs, it is tens of thousands of combinations, and Googlebot will happily work through them while your actual category pages wait.
Worth noting: Adobe’s own layered navigation documentation covers display, price ranges and filterable attributes, and says essentially nothing about crawling, canonicalisation or indexing. The platform does not warn you about this. You have to know to look.
Google’s guidance is clear about the fix and about the order of preference. Blocking crawl is the recommended approach, because filtering “consumes server resources for no or negligible benefit.” URL fragments work passively, since “Google Search generally doesn’t support URL fragments in crawling.” And notably, rel="nofollow" and canonical tags are described as “generally less effective in the long term” than either.
That last point contradicts what a lot of Magento extensions do. Plenty of SEO modules canonical every filtered URL back to the category and call it solved. It is not solved. Google still has to crawl each one to see the canonical, which is the cost you were trying to avoid.
The practical setup for most stores: disallow filter parameters in robots.txt, then deliberately open up the handful of filter combinations that have genuine search demand (brand plus category, usually) as proper indexable pages with their own titles and copy. Google also advises returning a 404 for combinations with no results rather than an empty page, which Magento will otherwise serve happily.
The settings to check in the admin today
Several Magento defaults and near defaults cause duplicate content, and all of them are a few clicks to inspect.
Category path in product URLs. If this is switched on, every product accessible from three categories has three URLs. Adobe’s documentation addresses this directly and recommends either excluding the category path or using canonical tags to stop duplicates being indexed. Excluding the path is the cleaner answer for most stores.
Canonical tags for categories and products. Check both are enabled under Stores, Configuration, Catalog, Search Engine Optimization. On many installations, particularly upgraded ones, one or both are off, and nobody has ever looked.
The URL rewrite table. Magento generates rewrites automatically and rarely removes them. On a store that has been through a few catalogue restructures, this table can hold hundreds of thousands of rows, including chains that redirect three or four times before landing. Audit it. Chains cost crawl and they cost load time.
Store view and session parameters. URLs carrying ?___store or similar switching parameters get crawled and indexed if nothing stops them. Handle these in robots.txt alongside your filter parameters.
Pagination. Magento’s default paginated category URLs need canonical handling and usually need ?p= excluded from crawl beyond a sensible depth. Decide deliberately rather than inheriting whatever your theme does.
Speed, which on Magento is a front end decision
Magento’s reputation for being slow is partly deserved and mostly a theme problem. The default Luma theme ships a large amount of JavaScript, much of it Knockout and RequireJS, and on a mid range Android phone that is where your Interaction to Next Paint goes.
The thresholds are not negotiable: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1, assessed on real visits at the 75th percentile.
Before anyone proposes a replatform, do the boring things. Varnish full page cache configured properly, not just enabled. Production mode with merged and minified static content. Images served as WebP at sensible dimensions, which on a catalogue of thousands of products means an automated pipeline, not a manual pass. Third party scripts audited, because most Magento stores are carrying four analytics tools and two review widgets.
If you have done all that and mobile performance is still poor, then the front end is the constraint, and a Hyvä theme rebuild is the usual answer. It strips out the Knockout and RequireJS layer and tends to produce a dramatic improvement in field metrics. It is also a full front end rebuild with a real budget and a real timeline, so treat it as a replatform decision rather than an optimisation task.
A headless PWA build can also work, but it reintroduces the JavaScript rendering questions you avoid with a server rendered theme. Pick it because your business needs it, not because it sounds modern.
Markup, category content and the migration trap
Magento’s default Product structured data is usually incomplete. Check what is actually rendering and make sure price, currency, availability and the review aggregate are present and accurate, because stale availability data is a common cause of losing rich results. Adobe warns that structured data violations can attract a manual action, so accuracy is not a stylistic preference.
Category pages are where most Magento stores leave the largest opportunity. They are the pages with the strongest commercial search demand and they usually contain a heading, a grid, and nothing else. A short piece of genuinely useful buying guidance at the top or bottom of the category, the kind a good salesperson would say, is often the highest return content work available on the site.
On migrations, the trap is predictable and expensive. Magento 1 to 2, or Magento to anything else, changes URL patterns. Without a complete redirect map built from a crawl of the old site, you lose the rankings you spent years building, and you find out six weeks later. Build the map before the migration, test it in staging, and keep the old crawl data so you can verify afterwards.
The platform agnostic side of ranking an ecommerce site (category depth, product descriptions, internal linking) is covered in our piece on improving ecommerce rankings; this article deliberately sticks to what is Magento specific.
Priority order and what to expect
Start with crawl control, because on Magento it is the constraint everything else runs into. Filter parameters, store view parameters and the rewrite table, in that order. Then the canonical and URL settings. Then caching and images. Then category content. Theme rebuilds last, and only if the data says the front end is genuinely the problem.
Timelines, honestly: crawl control changes show up in Search Console within two to four weeks as crawl distribution shifts, though ranking effects take longer. Speed work changes conversion almost immediately and rankings gradually. Category content and consolidation takes three to six months to settle. A theme rebuild is a quarter of work before it delivers anything.
Magento rewards this kind of attention more than most platforms, because the gap between a default installation and a well configured one is unusually wide. If you want someone to go through your configuration and tell you which of these apply, we do Magento technical audits and we will be specific about what is worth doing and what is not. Contact Canopy Media Now.
