SEO Services for Magento and Adobe Commerce Stores

The same handful appear on most Magento stores. Layered navigation is usually the biggest: every filter adds a URL parameter, and combinations of filters, sort orders and page sizes can produce far more crawlable URLs than the store has products. Next is URL structure, where product URLs that include category paths create several addresses for the same product and inflate the url_rewrite table. Store views are a frequent third, because Magento 2 has no built-in hreflang, so translated or regional stores compete with each other in search. Performance problems follow close behind, particularly blocks marked uncacheable that switch off full page cache for whole templates. Finally, default themes and older extensions often output incomplete or duplicated structured data. Each of these has a known fix in Magento configuration, templates or extensions, and most can be resolved within the first couple of months.

For most stores, no. Magento has a setting called Use Categories Path for Product URLs, and when it is enabled a product assigned to three categories becomes reachable at three different addresses, plus the version without a category. Canonical tags can tell Google which one to prefer, but the duplicates still consume crawl budget, your internal links end up split between versions, and the url_rewrite table grows with every combination of product, category and store view, which slows down reindexing and saving products. Keeping product URLs at the top level gives each product one address that does not change when it is moved between categories. Breadcrumbs can still show the category path for shoppers. Changing this setting on an established store needs care, because every old URL has to redirect correctly, so we map and test the redirects before switching.

We start by finding out which filtered views people actually search for. A category filtered by a single popular brand or material often matches a real query and deserves its own indexable page, with a clean URL, a unique title and description, and some introductory copy. Those pages are created deliberately, either through an SEO landing page extension or as dedicated categories, and linked from the main category. Every other combination, such as multiple filters, price ranges, sort orders and page sizes, is kept out of the index with canonical tags or noindex, and where crawl waste is severe, with crawl rules as well. The right combination depends on how your layered navigation is built, whether you use native filtering, Elasticsearch or OpenSearch, or Adobe Commerce Live Search, so we test each rule against Search Console data after it ships.

It can help a great deal with speed, and speed feeds into both rankings and conversion. The default Luma front end loads a large amount of JavaScript through RequireJS and KnockoutJS, which is a common cause of poor Largest Contentful Paint and Interaction to Next Paint scores on Magento stores. Hyvä replaces that front end with a much lighter stack, and stores that switch usually see substantial improvements in Core Web Vitals. What Hyvä does not fix is anything structural. Layered navigation waste, duplicate product URLs, store-view conflicts and missing structured data all survive a theme change unless they are dealt with separately. A Hyvä rebuild is also a real project, with extension compatibility to check and templates to rebuild. We treat it as one option within an SEO plan, recommended when performance is the main constraint, rather than as a cure-all.

Yes. Magento and Adobe Commerce development, upgrades and support are a core part of what we do, which is why our Magento SEO work is implemented rather than just recommended. The same team that finds a layered navigation problem can build the fix as a module or configuration change, test it on staging and release it through your normal deployment process. That matters on Magento in particular, because many SEO issues are really development issues, and a recommendation that ignores how your store is built often gets shelved. If you already have a Magento developer or agency, we can work alongside them instead, writing each change as a specification they can implement and checking it after release. We also review extension updates and deployments for SEO side effects, since a single extension update can quietly change canonical tags or URL structures across the whole store.