Adobe Commerce & Magento

 Magento SEO is the practice of making a Magento or Adobe Commerce store crawlable, indexable, and fast enough for Google to reward it, and most of that work sits in platform configuration rather than content. Magento generates duplicate URLs through layered navigation, ships default metadata that does not scale past a few hundred products, and often performs poorly on Core Web Vitals without dedicated caching. Treating these as content problems is why so many stores plateau after the tenth blog post.

We have audited enough Adobe Commerce and Magento Open Source stores to see the same pattern repeat. A merchant follows every content checklist, publishes consistent copy, and still watches a competitor on a simpler platform pull ahead in the rankings. The difference is rarely content quality. It is usually layered navigation throwing off thousands of crawlable duplicates, a robots.txt file blocking the wrong resources, or a theme that cannot get Largest Contentful Paint under 2.5 seconds.

Why Is Magento SEO a Technical Problem Before It Is a Content Problem?

Most SEO advice assumes a platform that behaves predictably: one URL per page, metadata under the editor’s control, and reasonably fast delivery by default. Magento requires more technical SEO oversight. Depending on configuration, it can expose multiple URLs for the same catalog content, use auto-generated metadata values, and generate large volumes of URL rewrite data as catalogs grow.

This matters because content strategy cannot fix a crawl budget problem. If Googlebot spends its allocation crawling filtered category permutations that will never rank, it has less budget left for the product and category pages that actually drive revenue. This is why our approach to Magento SEO always starts with a crawl, not a content audit.

How Does Layered Navigation Generate Thousands of Duplicate URLs?

Layered navigation is the filter sidebar on category pages, and it is a major source of duplicate content on a Magento store. Take one category, Women’s Shirts, with 4 filterable attributes: color, size, material, and brand. If color has 6 options, size has 5, material has 4, and brand has 8, that one category can generate close to 960 unique filter combinations, each with its own crawlable URL, such as:

https://store.com/womens-shirts.html?color=blue&size=medium&material=cotton&brand=acme

None of those 960 pages offer a search engine anything the base category page does not already provide. They are the same products, resorted. This is exactly the pattern that turns up in an SEO Magento crawl: a handful of real category pages surrounded by thousands of near-duplicate filter URLs competing for the same rankings.

When we run an SEO Magento review, layered navigation is usually the first thing we check, because it is the fastest way to see whether a store is bleeding crawl budget. The fix is not to disable layered navigation. Customers rely on it. The fix is canonical tags pointing every filtered variation back to the base category page, combined with robots.txt rules that stop Googlebot from crawling filter parameters at all.

Left unfixed, this is a quick way to sink Magento SEO performance on an otherwise healthy catalog, because Google keeps discovering new URLs faster than it can index the ones that matter.

Why Does Default Metadata Break at Catalog Scale?

Magento’s default metadata pattern works fine for a 40-product catalog and falls apart at 4,000. The out-of-the-box template repeats the same title structure across every page, which means search engines see thousands of title tags that differ only by product name. That is not duplicate content in the strict sense, but it gives Google little to differentiate one page’s relevance from another’s.

The fix is a templated approach built from product attributes already in the catalog: brand, category, material, and price tier, so metadata varies meaningfully without a copywriter touching every single page. A title like “Buy [Product Name] by [Brand] | [Category] | Free Shipping” uses data Magento already stores. Category pages need the same treatment, built from each category’s own attribute set rather than one global template.

Getting this right is one of the more overlooked parts of Magento SEO, because it looks like a content task on the surface, but it is really a data and templating exercise.

Core Web Vitals on Magento: What Actually Moves the Number

Core Web Vitals gets treated like the whole of technical SEO, and it is not, but it is where Magento stores lose the most ground. The Luma theme was never built with performance as a priority, and Largest Contentful Paint on a default Luma installation regularly sits above a few seconds on product pages, mostly because RequireJS loads JavaScript in a waterfall before the page can render anything useful.

Some interventions move the number. Others get recommended constantly and barely register. What actually helps:

1. Switching from Luma to Hyvä, which removes RequireJS entirely in favor of Alpine.js and Tailwind, cutting JavaScript payload substantially on stores running Magento 2.4.7.
2. Varnish isn’t a “turn it on and forget it” feature. Proper configuration is important to getting the performance benefits of full-page caching. Adobe strongly recommends Varnish for production, noting that the built-in full-page cache is much slower.
3. Serving properly sized, next-generation image formats instead of relying on the browser to scale down full-resolution originals.
4. Moving catalog search to Elasticsearch, which reduces database load on category and search pages and improves response time across the site.

What barely moves the number: a “performance” extension that adds its own JavaScript on top of an already bloated theme, minifying JavaScript and CSS in the admin without addressing the RequireJS waterfall underneath it, and adding a CDN in front of a site that still has render-blocking resources. A CDN speeds up delivery, not rendering.

The Magento 2 SEO Settings Most Stores Never Configure

Every Magento 2 SEO setting that matters most is buried three menus deep in the admin, under Stores > Configuration > Catalog > Search Engine Optimization, and most merchants never open that screen after initial setup. A handful of toggles determine whether the platform helps or hurts organic performance by default.

Here are the 6 settings we check first on every store:

1. Use Web Server Rewrites, under Stores > Configuration > General > Web, which controls whether URLs are readable at all.
2. Use Categories Path for Product URLs, which determines whether a product’s URL reflects its category structure.
3. Create Permanent Redirect for URLs if URL Key Changed, which prevents broken links every time a product name changes.
4. Use Canonical Link Meta Tag for Categories, off by default and directly responsible for the duplicate content problem covered above.
5. Use Canonical Link Meta Tag for Products, the product-page equivalent of the setting above.
6. The default robots.txt template, which often still reflects rules written for an older platform version and rarely gets revisited after an upgrade.

Most Magento 2 SEO settings take minutes to change once someone knows where to look. The harder part is knowing which ones matter, because Magento does not flag any of this in the admin dashboard.

If your store has not been upgraded in several major releases, some of these settings may not exist yet in your version, which is a conversation we usually have as part of our Magento upgrade service rather than as a stand-alone fix. None of this is exotic. It is closer to routine maintenance, but it gets skipped because Magento SEO rarely has an obvious owner inside a merchant’s team.

Structured Data for Magento Product and Category Pages

Magento Open Source provides basic structured data out of the box, but product pages may require additional implementation to fully support the properties that can make them eligible for rich results in search. A product page should include Schema.org Product markup with relevant properties such as name, SKU, brand, image, and an offering object covering price, currency, and availability. Valid aggregateRating markup can also make a product eligible for review snippets that display star ratings in Google Search.

Category pages benefit from ItemList or BreadcrumbList markup, which helps search engines and AI-driven answer engines understand how a page fits into the site’s structure. This matters as much for how AI Overviews summarize a page as it does for classic organic rankings, since both systems rely on explicit signals rather than inferring context from prose.

We treat structured data as a checklist item on every Magento SEO project, not an enhancement to consider later, because it is one of the cheaper fixes on this entire list relative to the visibility it returns.

Multi-Store and International Magento SEO

Adobe Commerce SEO for a multi-store setup introduces a problem that does not exist on a single-store install: competing store views. A merchant running separate store views for Canada and the United States, both in English, risks having Google rank the wrong country’s page for a given searcher, or having the two store views cannibalize each other’s rankings entirely.

This is where Adobe Commerce SEO gets genuinely complicated, because Magento’s multi-store architecture does not generate hreflang tags automatically between store views. Each store view needs hreflang link elements referencing every alternate version of that page, validated with a crawl tool such as Screaming Frog.

What a Magento SEO Audit Should Cover?

A proper Magento SEO audit goes well beyond a plugin scan or a generic checklist built for a different CMS. It needs a full crawl simulation using a tool like Screaming Frog, cross-referenced against Google Search Console data for coverage, indexing, and Core Web Vitals.

Here are the 7 areas every Magento SEO audit we run covers:

1. Crawl simulation and indexation rate, comparing pages generated against pages actually indexed
2. Canonical tag implementation across categories, products, and paginated URLs
3. Robots.txt and XML sitemap accuracy
4. Layered navigation configuration and filter parameter handling
5. Structured data validation for product and category templates
6. Core Web Vitals baseline by page template, not a single site-wide average
7. Multi-store and hreflang configuration, where applicable

Where to Start If Your Store Has Never Had a Technical SEO Review

Some Magento SEO problems are cheaper to fix than to work around, and some are the opposite. If a store on an older Magento Open Source version has fewer than a few thousand SKUs and the core issues are layered navigation and metadata, a focused technical project usually resolves it faster than a replatform would.

If the store runs a heavily customized, multi-year-old codebase with performance problems baked into custom modules, and the business is already weighing a platform move, it is often cheaper to solve that problem by replatforming than by patching a foundation that was never built for its current traffic. The way to tell which situation applies is the audit itself. It tells you whether you are looking at configuration work or a structural rebuild before you commit a budget to either one.

For teams that already understand this and just need it executed, that is the point where Magento SEO services make sense. The fixes above require Magento development experience, not general SEO experience.

A generic SEO agency can tell you layered navigation is a problem. Implementing the fix without breaking checkout or catalog search is a different skill set, which is closer to what our Magento SEO services  cover on a daily basis.

If you want a clearer picture of where your own store stands, the next reasonable step is a technical crawl and a Search Console review, not another round of content edits. We run this as a standalone engagement for stores that want the findings before deciding what comes next.

Support