Magento SEO agency

Magento SEO where it actually leaks: category paths out of product URLs, canonicals set, layered navigation controlled, rewrites kept under control.

Magento stores are usually large enough that a single wrong setting affects thousands of URLs, which is why the SEO work here is more about configuration than content at first. Three settings do most of the damage. Whether product URLs include the category path, which can produce the same product at several addresses. Whether canonical tags are switched on for categories and products, which is not the default in every installation. And which attributes are filterable in layered navigation, because every one you add multiplies the number of crawlable combinations.

On top of that sits the URL rewrite table. Magento can keep the old rewrite when a URL key changes, which is what you want, and the table grows steadily as a result. Left unattended for years it becomes large enough to slow the store and to contain chains that send crawlers through three hops to reach a page.

Store views add another layer, since each language or locale is a separate view with its own URLs and its own hreflang output. Getting that right matters more than any content change on a store selling into several countries.

We work with your developers or bring our own, change one thing at a time, and test on a staging copy before anything reaches production.

Native on Magento / Adobe Commerce

The URL rewrite table, with the option to keep the old rewrite when a URL key changes
Catalog SEO settings for canonical tags on categories and products, and for the URL suffix
Layered navigation built from attributes you choose to make filterable
Store views for language and locale, with hreflang output between them
Sitemap generation scheduled through cron rather than written by hand
Full page caching in front of category pages, which is where the load sits

Settings that matter

Take the category path out of product URLs

When product URLs include the category path, the same product exists at as many addresses as it has categories. Canonical tags mitigate it and do not remove the crawling cost or the internal link dilution. We switch it off, keep the direct product URL as the single address, and add redirects from the category-path versions. On a catalogue of any size this is usually the single biggest technical change available.

Turn on canonical tags for categories and products

Magento can emit canonical tags for both, and in many installations one or both are off. Without them, paginated category pages, sorted views and filtered states all present as separate pages with nearly the same content. We enable them, check the output on a real page rather than in the configuration screen, and make sure pagination is handled consistently rather than being canonicalised to page one.

Limit which attributes are filterable

Every attribute you allow in layered navigation multiplies the combinations a crawler can walk. Colour, size and price are usually worth having. A dozen technical attributes are usually not, at least not as crawlable states. We decide which filters shoppers actually use from your on-site search and behaviour data, keep those, and make sure the filtered URLs they generate are not being indexed unless we have chosen to promote one.

Keep the rewrite table maintained

Rewrites accumulate every time a URL key changes, and a store with years of catalogue churn can carry a very large table with chains and loops inside it. We audit it, collapse chains so each old URL points directly at the final destination, remove entries for products that no longer exist and have no successor, and set a rule for how bulk imports handle URL keys so the table stops growing without reason.

Run cron properly before trusting the sitemap

Sitemap generation is a scheduled job, so a store with a broken or backed-up cron has a sitemap describing the catalogue as it was months ago. We check cron is running, confirm the sitemap regenerates, and verify the URLs in it resolve without a redirect. A sitemap full of redirected URLs is a slow way to tell crawlers your structure changed.

What we avoid

Changing URL keys in a bulk import without keeping the old rewrite, which silently drops every ranking those pages held
Making every product attribute filterable, which turns one category into thousands of crawlable combinations
Testing configuration changes directly on production, where a cache flush on a large catalogue is felt by real shoppers

Questions

No, for almost every store. It creates duplicate addresses for the same product, splits internal linking between them and increases the crawling cost of the catalogue. The argument for keeping it is that the URL reads as a breadcrumb, which is a small benefit for a real cost. Breadcrumb markup gives you the same clarity without the duplication.

Reduce the number of filterable attributes to the ones shoppers use, then control how the filtered URLs are treated. Canonical tags pointing at the unfiltered category, parameter handling, and internal links that never point at a filtered state together keep the crawl on the pages that can rank. Where a specific filter matches real demand, promote that one deliberately with its own content.

If you run more than one language or country version of the same content, yes. Each version should reference the others and itself, and the references have to be reciprocal or they are ignored. Magento can output this from the store view configuration. The common failure is a partial catalogue, where a product exists in one view and not another, leaving references pointing at pages that do not exist.

Usually because cron is not running, or is running but backed up behind a long queue. The sitemap is generated on a schedule rather than on demand, so it fails quietly. Checking the file's timestamp against the last catalogue change tells you in seconds. Fixing cron often improves several other things at once, including indexing and email sending.

Send your Magento / Adobe Commerce store.

The plan is written for your store on the platform it runs on.