Technical SEO on Magento and Adobe Commerce comes down to three controls most stores get wrong: canonical tags that point filtered and sorted URLs back to one indexable page, pagination that gives every page its own self-referencing canonical instead of the retired rel next and prev markup, and hreflang that maps each store view to a language and region. A Hyva frontend makes all three easier to emit cleanly.
The platform generates a surprising number of URLs that resolve to near-identical content. Left unmanaged, those URLs split ranking signals, waste crawl budget, and bury the pages you actually want ranked. This guide, from the ecommerce team at Bemeir, covers the exact settings, the places native Magento stops short, and what a Hyva build changes.
Why Magento stores leak ranking signals
A single category on Magento can expose dozens of crawlable URL variants. Layered navigation adds filter parameters. Sorting adds more. Pagination multiplies every one of them. Add session IDs, tracking parameters, and multiple store views pointing at the same catalog, and one product can be reachable through a long list of addresses that all serve the same content.
Search engines treat each distinct URL as a candidate for indexing. When many of them carry the same products, Google has to pick a representative itself, and it does not always pick the one you would. The result is split authority, keyword cannibalization across your own pages, and crawl budget spent re-reading duplicates instead of discovering new inventory.
The fix is not a single toggle. It is a layered setup: canonical tags to consolidate, robots directives to control crawling, and hreflang to keep international variants from competing. The pages below take each in turn.
Canonical tags: the setting, and where it still falls short
Magento ships native canonical support. In the admin, open Stores > Configuration > Catalog > Catalog and expand Search Engine Optimization. Set “Use Canonical Link Meta Tag for Categories” and “Use Canonical Link Meta Tag for Products” to Yes. With that enabled, category and product pages emit a self-referencing canonical, which consolidates signals even when no duplicate exists. Adobe documents this behavior in the catalog configuration reference.
Two gaps remain. First, the product canonical, when enabled, points every product URL to the standalone product page regardless of the category path a shopper arrived through. That is usually correct, but if you deliberately rank category-scoped product URLs, confirm the behavior matches your plan before shipping. Second, and more important, the native canonical does not clean up the parameter sprawl that layered navigation creates. A filtered URL will often still carry a canonical that search engines can second-guess, which is why layered navigation needs its own treatment (covered below).
Google’s own guidance reinforces the discipline: a rel="canonical" annotation is “a strong signal that the specified URL should become canonical,” and you should avoid mixing conflicting signals or using robots.txt to try to consolidate URLs. Google’s guide to consolidating duplicate URLs is the authoritative reference. Pair clean canonicals with correct structured data on your Magento and Hyva storefront so the page search engines pick is also the page they can fully understand.
Pagination in 2026: forget rel next and prev
For years the standard advice was to mark paginated category pages with rel="next" and rel="prev". That advice is dead. Google confirmed it no longer uses those tags, and its documentation now states plainly that each paginated page should “give each page its own canonical URL” rather than canonicalizing page two and beyond back to page one.
That last point trips up a lot of Magento stores. Pointing every paginated page at page one hides the products on pages two, three, and deeper from indexing, because the canonical tells Google those pages are duplicates of the first. The correct pattern is a self-referencing canonical on each page of the sequence, combined with real <a href> links between pages so Googlebot can crawl the series. Google’s ecommerce pagination guidance spells this out, including the warning to avoid URL fragments for page numbers because Google ignores them.
Here is how the old approach compares with what works now:
| Pagination control | Old practice | Current best practice |
|---|---|---|
| rel next / prev | Required markup | Removed; Google ignores it |
| Canonical on page 2+ | Point to page 1 | Self-reference each page |
| Page discovery | Relied on rel markup | Crawlable <a href> links |
| Infinite scroll | Acceptable alone | Pair with paginated URLs |
| Filtered or sorted variants | Often left indexable | Noindex or block from crawl |
If a view-all page is reasonable for a category, it can rank well, but only when it loads fast enough to avoid hurting Core Web Vitals. On a heavy Luma theme, a view-all page of several hundred products is often slower than it is worth. This is one of several places where frontend performance and SEO decisions are the same decision.
Layered navigation: the biggest duplicate-content source
Faceted filters are the single largest generator of low-value URLs on most Magento catalogs. A shopper filtering by color, size, and price creates a combinatorial explosion of parameterized addresses, and by default many of them are crawlable and indexable.
Handle them with a deliberate policy rather than hoping canonicals absorb everything:
- Enable “Use Canonical Link Meta Tag for Layered Navigation” where your version or SEO extension supports it, so filter pages point to the parent category.
- Apply a
noindex, followmeta directive to filter and sort combinations you do not want indexed, which keeps link equity flowing while removing the thin page from the index. - Decide which filters, if any, deserve to rank. A filter that matches real search demand, for example a brand or a well-searched attribute, can justify an indexable, canonical-to-self landing page. Everything else should consolidate.
- Watch crawl budget. Large catalogs can have Googlebot spending most of its visits on filter permutations. The performance of those pages matters too, which is why layered navigation speed on Hyva is a ranking issue, not only a UX one.
The goal is a catalog where the indexable set is the set you chose, not the set the URL parameters happened to produce.
Hreflang across store views
If you sell into more than one language or country, hreflang tells search engines which store view to serve each user and keeps your regional pages from competing with each other. The cluster only works when every version references all the others, including itself, and names an x-default.
On Magento, the building blocks are store views. Each view carries its own locale, so a US English view, a Canadian English view, and a French Canadian view are three distinct scopes. The language part of each hreflang value comes from the store view locale under Stores > Configuration > General, and the country part you set per view. You then choose whether the hreflang cluster operates within a single website or globally across websites, depending on how your store hierarchy is built.
The catch: Magento Open Source does not generate complete hreflang annotations natively. Most stores add an SEO extension or a custom module to emit them correctly across products, categories, and CMS pages, and to keep the self-referencing and x-default entries intact. Google’s requirements for localized versions of a page are the standard to build against. For the broader internationalization picture, including RTL and per-locale QA, see our guide to running Hyva across languages and markets.
What native Magento handles versus what you must add
| Technical SEO control | Magento Open Source | Adobe Commerce | What a build usually adds |
|---|---|---|---|
| Self-referencing canonicals | Yes, via setting | Yes, via setting | Verification across templates |
| Layered-navigation canonical | Partial | Partial | Rules for filter indexing |
| Pagination canonical | Self-reference | Self-reference | Audit to catch page-1 mistakes |
| Hreflang annotations | No | No | Extension or custom module |
| Sort and tracking params | Crawlable by default | Crawlable by default | Robots and parameter policy |
| AI crawler citability | Baseline | Baseline | Schema and clean markup |
The pattern is consistent: the platform gives you the switches, and a competent build decides the policy, verifies it renders on every template, and keeps it correct through upgrades.
How Hyva changes the technical SEO picture
A Hyva frontend does not improve rankings on its own. What it changes is the foundation. Hyva replaces the Luma stack of Knockout, RequireJS, and heavy JavaScript with Tailwind and Alpine, which produces far less code and a cleaner document. That matters for technical SEO in three concrete ways.
First, the head section and its meta tags, canonicals, and JSON-LD are easier to control and verify in Hyva templates than in Luma’s layered XML and PHTML. Fewer moving parts means fewer places for a canonical to go missing. Second, Hyva’s speed directly helps crawl efficiency and Core Web Vitals, and Core Web Vitals is a ranking input. A faster category page is both better for shoppers and cheaper for Googlebot to crawl at scale. Third, the lean markup makes a catalog more citable by AI answer engines, which increasingly send qualified traffic; our guide to making an Adobe Commerce catalog citable by ChatGPT and Perplexity goes deeper on that shift.
None of this is automatic. A Hyva migration can break structured data or drop a canonical if the rebuild is careless, which is exactly why the frontend and the SEO layer should be owned by the same team.
A pre-launch technical SEO checklist
Before any Magento or Hyva launch or migration, confirm:
- Category and product canonicals are enabled and render self-referencing on every template.
- No paginated page canonicalizes back to page one.
- Layered navigation filters follow an explicit index or noindex policy.
- Hreflang clusters are complete, self-referencing, and name an x-default.
- Robots rules block tracking and session parameters from indexing.
- XML sitemaps list only canonical, indexable URLs.
- 301 redirects preserve equity for every changed URL in a replatform.
- Structured data validates on product, category, and CMS pages.
Technical SEO beyond Magento
The same discipline applies on every platform we build on. Whether a store runs on Magento, Shopify, Shopware, or BigCommerce, the questions are identical: which URLs should be indexed, which should consolidate, and how do international variants coexist. The platform changes the implementation, not the principles. You can read more about Bemeir and the way we work as an extension of a merchant’s team, and our deep technology partner ecosystem means the SEO extensions and monitoring tools we recommend are ones we have shipped in production.
FAQ
Does Hyva improve SEO on its own?
No. Hyva gives you a faster, cleaner technical foundation, which helps Core Web Vitals and crawl efficiency, but it does not configure canonicals, hreflang, or redirects for you. Rankings move when the frontend speed is paired with correct technical SEO. A sloppy Hyva migration can even remove structured data or canonicals that were working before.
Should I canonicalize page 2 of a category to page 1?
No. Google treats that as telling it the later pages are duplicates of the first, which hides their products from indexing. Give each paginated page a self-referencing canonical and link the pages together with real anchor links so the full series stays crawlable.
Do I still need rel next and prev tags?
Google no longer uses them, so they bring no SEO benefit for Google. Some other engines may still read them, so emitting them does no harm, but they are not a substitute for self-referencing canonicals and crawlable pagination links.
How should layered navigation filter pages be handled?
Give filters a policy. Point most filtered URLs back to the parent category with a canonical, apply noindex to combinations that add no search value, and reserve indexable landing pages for the few filters that match real search demand. The aim is to control which filter pages, if any, enter the index.
Does Magento generate hreflang tags automatically?
No. Magento Open Source and Adobe Commerce do not emit complete hreflang annotations natively. Most multi-region stores add an SEO extension or a custom module to generate self-referencing hreflang clusters with an x-default across products, categories, and CMS pages.
Technical SEO is not a plugin you install once. It is a set of decisions about which URLs matter, enforced across every template and held through every upgrade. That is the work our Magento and Adobe Commerce development team treats as part of the build, not an afterthought. Get it right and, in the words our clients hear from us, your organic search rankings will thank you.
