Magento SEO: the settings and fixes that actually matter
Magento SEO in priority order: the Magento 2 URL settings, layered navigation, pagination and performance fixes that decide how a store ranks.
Magento is capable of ranking extremely well, and a default Magento install is not set up to. Most Magento SEO problems are not content problems. They come from the platform doing exactly what it was configured to do: generating several URLs for one product, letting filter combinations multiply into thousands of crawlable pages, and serving a theme heavy enough to drag every page's performance down.
This guide covers Magento 2 (Magento Open Source and Adobe Commerce). The admin paths below are from Magento 2.4. Menu labels shift slightly between versions and themes, but the settings themselves have been stable for years.
1. Fix the URL settings before anything else
The single highest-impact change on most Magento stores sits in Stores > Configuration > Catalog > Catalog > Search Engine Optimization. These settings decide how many URLs each product has, and every duplicate URL is crawl budget and ranking signal split across addresses that should be one.
Use Categories Path for Product URLs: No
When this is on, a product in three categories is reachable at three category-prefixed URLs plus its own. Turning it off gives each product one URL, and it stops product URLs changing whenever someone reorganises the category tree.
Use Canonical Link Meta Tag for Products and Categories: Yes
Both are off by default. Switch them on so that any parameterised or alternate version of a page points back to the preferred URL.
Create Permanent Redirect for URLs if URL Key Changed: Yes
This makes Magento write a 301 when a product or category URL key is edited. Without it, renaming a product silently breaks its old URL and every link pointing to it.
Generate "category/product" URL Rewrites: No
Where available, turning this off stops Magento writing a rewrite for every product in every category. On large catalogues with several store views, those rewrites are a major reason the url_rewrite table grows into the millions and slows reindexing.
2. Layered navigation is where crawl budget goes to die
Magento's layered navigation writes filters as query parameters, so a category with colour, size, brand and price filters can produce a combination URL for nearly every permutation, and all of them are linked from the page. Search engines follow those links. On a catalogue of any size, filter URLs can outnumber real pages by orders of magnitude, and Google spends its time crawling them instead of your products.
The fix is a deliberate decision about which filtered pages deserve to exist in search. A small number usually do: a brand within a category, or a filter combination people actually search for, such as a material or a use case. Those deserve a clean, static URL, a unique title and some copy, which in Magento means an extension or custom module, because the core does not produce indexable filter landing pages. Everything else should carry a canonical to the unfiltered category or a noindex, so it stays usable for shoppers without competing in search.
Be careful with robots.txt here. Blocking filter parameters in robots.txt stops crawling, which also stops Google reading any noindex or canonical on those pages, so URLs already in the index can linger there. Use robots.txt to stop crawling of URLs that were never indexed, and use noindex or canonicals to clean up URLs that already are.
3. Check what your paginated pages declare
Category pagination in Magento uses a ?p= parameter. The common problem is the canonical. On many Magento builds, the category canonical drops the page parameter, so page 2, page 3 and beyond all declare page 1 as their canonical. That tells Google the later pages are duplicates of the first, and the products that only appear deeper in the category lose the internal links that page 2 onwards was providing.
Paginated pages should declare themselves as canonical. View the source of page 2 of a large category and check. If it points at page 1, that is a theme or module fix and usually a small one. Google no longer uses rel=next and rel=prev as an indexing signal, so there is no need to add them, but plain crawlable links between pages matter.
4. Robots, sitemaps and the pages that should never be indexed
Magento manages robots.txt and the default robots meta tag under Content > Design > Configuration, per scope, in the Search Engine Robots section. XML sitemaps are configured under Stores > Configuration > Catalog > XML Sitemap and generated from Marketing > SEO & Search > Site Map.
Keep internal search results out of the index. Pages under /catalogsearch/ are generated from whatever users type, and they are thin and near-infinite. Keep cart, checkout, customer account and wishlist paths out as well. Check the generated sitemap too: it should list canonical URLs only, not category-path product URLs or out-of-date pages, and on multi-store setups each store view should have its own sitemap.
5. Store views, languages and hreflang
Magento's store views are how most merchants run several languages or regions from one install, and core Magento does not output hreflang tags for them. Without hreflang, the English store view for the US and the English store view for the UK look like duplicates to Google, and the wrong one can rank in each market.
Hreflang needs an extension or a custom module, and it has to be right in both directions: every version lists every other version, including itself, with correct language and region codes. Half-implemented hreflang is common on Magento and is usually worse than a clean absence, because it sends conflicting signals.
6. Structured data
The default Luma theme includes some schema.org markup on product pages, and it is partial and dated. Most stores are better served by generating complete Product JSON-LD with offers, price, currency, availability, brand, GTIN where you have it, and images, plus BreadcrumbList on category and product pages. That is what makes products eligible for merchant listings and rich results, and it gives AI answer engines unambiguous product facts to work from.
Only mark up reviews and ratings that are genuinely collected on your site and visible on the page. Markup that does not match visible content, or ratings that were never collected from customers, breaks Google's structured data policies and risks a manual action that removes rich results site-wide.
7. Performance: the theme is usually the problem
Magento's performance ceiling is high and its default floor is low. The server side is well understood: production mode, full page cache served from Varnish, Redis for cache and sessions, and hosting sized for your catalogue. Most performance-conscious hosts get this right.
The front end is where Magento stores typically struggle with Core Web Vitals. Luma ships a large JavaScript payload built on RequireJS and Knockout, and every extension adds its own. Hyvä, a lightweight alternative theme, removes most of that JavaScript and routinely makes a larger difference to Core Web Vitals than any amount of server tuning. It is a real project, because every extension's front-end needs a Hyvä-compatible version, but for stores where speed is limiting rankings and conversion, it is usually the change worth making.
The order to do this in
Fix the URL settings first, because every other fix depends on Google seeing one URL per page. Then take control of layered navigation, because it is usually the largest source of wasted crawling. Pagination, robots and sitemaps follow and are quick. Hreflang and structured data come next, and theme performance is last because it is the largest project, not because it matters least.
Change settings on staging first and crawl before and after. Changing URL settings on a live store with established rankings without a redirect plan is the fastest way to turn an SEO improvement into an SEO migration.
Common questions
Is Magento good for SEO?
Magento is one of the more capable platforms for SEO, and one of the easier ones to get wrong. It gives you control over URL structure, canonicals, robots directives, metadata and templates that hosted platforms restrict, so a well-configured Magento store has no platform-imposed ceiling on how well it can rank. The catch is that its defaults are not tuned for search. Category-path product URLs, crawlable layered navigation, paginated canonicals and a heavy default theme all work against you until someone deliberately changes them. That is the real trade-off compared with a platform like Shopify: Shopify makes fewer decisions available to you and gets most of them reasonably right, while Magento makes every decision available and assumes you will take them. With an experienced team, Magento's flexibility is an advantage. Without one, the same flexibility produces the index bloat and duplicate content most struggling Magento stores share.
Do I need a Magento SEO extension?
Probably for some things, and not for as many as extension vendors suggest. The core settings covered in this guide, including URL structure, canonicals, redirects on URL key changes, robots.txt and XML sitemaps, are native and need no extension. Where extensions genuinely earn their place is in capabilities core Magento lacks: hreflang across store views, indexable landing pages for selected filter combinations, templated meta titles and descriptions across large catalogues, and complete JSON-LD structured data. Before buying, check whether your theme already covers any of these, particularly if you use Hyvä, and prefer one well-maintained suite over several overlapping modules. Each extension adds code that has to survive every Magento upgrade, and two SEO extensions both trying to write canonical tags is a surprisingly common cause of the duplicate content they were each installed to prevent. Fewer, deliberate extensions are easier to keep correct.
How long does it take for Magento SEO fixes to show results?
It depends on the fix. Configuration changes such as canonicals, robots directives and pagination are picked up as Google re-crawls the affected pages, which on an active store takes days for important pages and weeks for the long tail. Cleaning up layered navigation bloat is slower to show, because Google has to re-crawl and drop large numbers of filter URLs before it redirects that attention to your real pages, and on big catalogues that realistically takes one to three months. Performance improvements affect Core Web Vitals field data on a rolling 28-day window, so a theme change shows in the data about a month after it ships. Watch the Page indexing report in Search Console rather than rankings alone: a falling count of excluded duplicate and filter URLs alongside a stable or rising count of indexed products is the clearest early sign the work is landing.
Services related to this guide
Tell us about your store
A written review of your store covering crawl waste from faceted navigation, category and product page targeting, duplicate and variant URLs, product structured data, and page speed on your real templates, with every finding ranked by likely revenue impact.