Losing clicks to competitors? Find out exactly why, and what to fix first.

Show me why
Skip to content

Web Design

Magento SEO: Adobe Commerce Technical Setup Guide

Add saadrazaseo.com as a preferred source on Google

No pressure and no sales script. Just honest answers.

Magento SEO means configuring Adobe Commerce so that every indexable page has one clean URL, a correct canonical tag, controlled filter pages, an accurate sitemap and fast templates. Start with URL rewrites and canonicals, then tame layered navigation, then audit performance and extensions. Most Magento problems come from duplication, not from missing features.

The 2024 Web Almanac SEO chapter found canonical tags on 65% of mobile pages and 69% of desktop pages, and 83.9% of mobile sites returned a 200 status for robots.txt, so these basics are common but far from universal.

Why Adobe Commerce needs a deliberate SEO setup

Adobe Commerce (still widely called Magento) is a powerful catalogue engine. It is also very good at producing URLs. A single product can be reachable through its own path, through each category it belongs to, through sorting and pagination parameters, and through layered navigation filters. None of that is a bug. It is how a flexible catalogue works. The SEO job is to decide which of those URLs deserve to be indexed and to make that decision obvious to Google.

When I audit an Adobe Commerce store, I do not start with keywords. Compared with a content-led CMS such as the one in my Drupal SEO guide, a store catalogue multiplies URLs far faster. I start with the question: how many URLs can a crawler find, and how many of them should exist in search? On catalogue sites the gap between those two numbers is usually where the lost visibility sits. If you are choosing between platforms, my comparison of CMS platforms for SEO explains where Adobe Commerce fits against lighter options.

URL rewrites: get the structure right once

Adobe describes the URL rewrite tool as a way to change the URLs of products, categories and CMS pages, creating permanent 301 mappings so old links keep working. Its URL rewrite documentation also notes that automatic redirects are enabled by default and that generating them when a URL key changes could cause significant performance issues for categories with many assigned products. That single warning shapes how you should work.

My decision rules for URLs on a Commerce store:

  • Choose the URL pattern before launch. Decide whether product URLs include category paths or sit at the root, and stick with it. Changing it later means thousands of redirects.
  • Edit URL keys deliberately. Renaming a product should be a decision, not a side effect of fixing a typo in the title. Each change creates redirect work.
  • Batch changes. If you must rename many categories, do it in a planned window and test the performance impact on a staging copy first, given Adobe’s own warning.
  • Use custom rewrites for campaigns and legacy paths. Adobe lists custom rewrites alongside product, category and CMS page rewrites. They are the right tool for old URLs from a previous platform, which is covered in my website migration SEO checklist.

One more detail from the same documentation: GET parameters are removed during these redirects for security reasons. If your old URLs relied on parameters to show different content, map them explicitly rather than assuming they will carry across.

Not sure if this is hurting your site?

Get the fixes that matter most, in priority order.

Find my blockers

Canonical settings and duplicate product URLs

Adobe’s documentation places the canonical URL options in the same search engine optimisation configuration area as web server rewrites. The practical goal is simple: whichever path a visitor used to reach a product, the page should declare one preferred URL.

Google’s guidance on consolidating duplicate URLs ranks redirects as the strongest signal, rel=”canonical” as a strong signal and sitemap inclusion as a weaker one. It also says none of these are required and that Google decides which version is best if you do not specify. In other words, a canonical tag is a hint, and a messy site can ignore your hint if the other signals disagree.

That is why I check these signals together on a Commerce site:

  1. Open a product page through a category path and through the root path. Confirm both declare the same canonical.
  2. Check that the canonical points to a URL that returns a 200 status, not a redirect.
  3. Check that internal links, breadcrumbs and the sitemap all use the canonical version, not the alternative.
  4. Check that simple products belonging to a configurable product do not compete with the parent in search unless you have a reason for that.

The fourth point is a judgement call. If shoppers search for a specific colour or size as its own query, an individual variant page may deserve to stand alone. If not, point variants at the parent. I would rather see that decision made on purpose than left to a default.

Layered navigation without a crawl explosion

Layered navigation is where Adobe Commerce stores most often leak crawl budget and index junk. Every combination of colour, size, brand and price can become a crawlable URL. Google’s faceted navigation guidance describes the problem as an effectively infinite URL space and lists the main options: block crawling of filter URLs in robots.txt, use URL fragments instead of parameters, point filtered pages at the unfiltered version with rel=”canonical”, or add rel=”nofollow” to links (every link to that URL, for it to work). If filtered pages must be indexable, it recommends standard parameter separators, a consistent filter order and a 404 status when a combination returns no results.

My decision table for a typical catalogue:

Filter typeSearch demand?My default treatment
Brand within a categoryOften yesIndexable, with a unique heading and intro text
Colour or materialSometimesIndex only where people search for it; otherwise canonical to the category
Price range, sorting, page sizeNoBlock from crawling and canonical to the base category
Multi-filter combinationsRarelyBlock from crawling

Treat the table as a starting point, not a rule. Check your own search data before deciding that a filter has demand. If a category page is the one you want to rank, make sure it has real copy and sensible internal links, and remember that a hosted alternative such as the one in my BigCommerce SEO store checklist handles some of this for you.

Sitemaps, robots.txt and metadata

Adobe Commerce can generate XML sitemaps for products, categories and CMS pages from the admin. I do not take generation for granted. I open the live sitemap and compare it with what I want indexed. A sitemap should list canonical, indexable, 200-status URLs only. If it includes disabled products, redirected URLs or filter pages, fix the source configuration, because a sitemap that contradicts your canonicals weakens both.

For robots.txt, keep it short and intentional. Block the genuinely useless crawl paths (internal search results, cart, checkout, account pages, filter parameters you have chosen to exclude) and nothing else. Never block CSS or JavaScript files that the page needs to render. For metadata, set patterns for titles and descriptions at category and product level, then override them for the pages that earn revenue. Templates save time, but a thousand identical-looking title patterns do not help anyone choose your result.

Product structured data matters on a shop. Whatever your theme or extension outputs, validate a sample of product pages with Google’s testing tools and confirm that price, availability and reviews match what is visible on the page. If you are planning a headless front end on top of Commerce, rendering and metadata become a front-end job, which I cover in my Next.js SEO guide.

Performance and extensions: where Commerce stores slow down

Adobe Commerce is heavy by nature, and speed on category and product templates depends on hosting, caching, theme code and third-party modules. Slow templates cost shoppers patience at exactly the moment they are ready to buy, so measure rather than guess. Use field data from the Chrome UX Report where you have it, and look at LCP, INP and CLS for your product and category templates separately, because they behave differently.

Extensions deserve caution. Every module that injects JavaScript, adds a widget or rewrites URLs is a potential SEO side effect. My routine is:

  1. List every installed extension and what it changes on the front end.
  2. Remove anything unused, rather than just disabling it in the admin.
  3. Test each SEO-related extension on staging: check canonicals, meta robots, structured data and sitemap output before and after.
  4. Re-test after every upgrade, because extensions can change behaviour between versions.

I would not install an SEO extension to fix a problem I cannot describe. First identify what is wrong (duplicate canonicals, missing structured data, slow templates), then choose the smallest change that fixes it.

A launch and maintenance checklist for Adobe Commerce

Use this as your running list. It pairs well with the broader website launch SEO checklist if you are going live on a new build.

  • URL pattern decided and documented; redirect map prepared for any legacy URLs.
  • Canonical output tested on category-path and root-path product URLs.
  • Layered navigation rules set per filter type, with a crawl test to confirm.
  • Sitemap reviewed against the indexable set; submitted in Search Console.
  • robots.txt reviewed; rendering resources not blocked.
  • Title and description patterns set, with manual overrides on top pages.
  • Product structured data validated on a sample of templates.
  • Extensions audited and tested on staging.
  • Core Web Vitals checked separately for home, category, product and checkout-adjacent pages.

If you run several storefronts or languages, add hreflang to the list. Google’s documentation says every alternate version must link back to the others and that annotations can be ignored if the return links are missing, so test it with a crawl rather than trusting a configuration screen.

Questions people ask about Magento SEO

Is Adobe Commerce good for SEO?

It can be, because it gives you control over URLs, metadata, canonicals and sitemaps. But it does not do the thinking for you. Default behaviour can create duplicate product URLs and crawlable filter pages, so the result depends on how carefully the store is configured and maintained.

Do I need an SEO extension for Magento?

Not always. Check what your build already provides for canonicals, metadata templates, sitemaps and structured data first. Add an extension only to fill a specific gap, and test it on staging, because extensions can change page output in ways that harm indexing.

How should I handle layered navigation filters?

Decide filter by filter. Index the combinations that match real search demand, such as brand within a category, and keep sorting, price and multi-filter combinations out of the crawl. Google’s faceted navigation guidance lists robots.txt, canonicals and nofollow as the main tools.

Will changing a URL key hurt my rankings?

It can if the redirect is missing or slow. Adobe states that 301 redirects are generated by default when URL keys change, but you should still verify them and avoid unnecessary renames, because large categories can see performance costs.

Next steps

Adobe Commerce rewards a methodical technical review: URLs, canonicals, filters, sitemaps and speed, in that order. If you would like an expert pair of eyes on your store, I offer a free audit through my SEO web design and development service, and you can contact me here to request it.

More in this series (SEO by website platform): start with Best CMS for SEO: WordPress vs Shopify vs Webflow vs Custom, then explore:

Is this holding your site back?

Share your website and I will look at the technical issues holding it back.

Your details are only used to reply to your request. No spam.

Grow my trafficCall