Magento SEO

Magento ships with the building blocks for great SEO — canonicals, sitemaps, meta-tag editing, URL rewrites — but those defaults are incomplete and aimed at developers, not search engines. Out of the box, Magento has no structured data on category or product pages, no hreflang for multi-store setups, no llms.txt, weak default meta-templates, layered-nav URLs that bloat the index, and a Luma frontend that drags Core Web Vitals. Most stores never go past the defaults — which is why “Magento SEO” is a paid specialism. The good news: every gap is a fixable engineering problem, not a platform limitation.

An SEO consultant tells you what’s wrong — runs Screaming Frog, looks at GSC, writes a 40-page report, hands it to your dev team. The dev team then has to translate “add Product schema to PDP” into actual Magento layout XML, blocks, and ViewModels.

An SEO developer does both. Audits the site, then ships the fix in code. No translation lag. No “we’ll get to it next sprint.” For Magento specifically this matters — structured data, hreflang, canonicals, llms.txt all live in the codebase, not in a CMS field. Hire the developer.

Three things make it different: (1) URL bloat — layered nav, search results, sort/order params can balloon the index by 10× if not handled. (2) Multi-store / multi-language — hreflang, canonicals across store views, and per-locale URL rewrites are non-trivial. (3) The product/category split — you have category pages competing with product pages competing with CMS pages for the same keywords. Generic SEO advice (“publish blog posts”) doesn’t cover any of this. Magento SEO is mostly a technical problem before it’s a content problem.

Yes — indirectly but measurably. Hyvä gives you Lighthouse 95+ and green Core Web Vitals out of the box, which Google has confirmed as ranking signals. Stores migrating from Luma to Hyvä typically see LCP drop from 4s to under 1.5s, CLS from 0.3 to 0, and Lighthouse SEO score jump from ~80 to ~95. That moves rankings on competitive keywords by 1–3 positions on average. But Hyvä alone doesn’t add structured data, fix hreflang, or generate llms.txt — those are separate work. Hyvä is necessary; not sufficient.

Structured data (JSON-LD) tells search engines what each page is — a Product, an Article, a FAQ, a BreadcrumbList. Google uses it to render rich results (star ratings, prices, availability, FAQ accordions) directly in search, which can double or triple click-through rate on the same ranking position.

Out of the box, Magento ships no structured data. Adding it correctly — Product on PDP, ItemList on category, FAQPage on FAQ pages, Organization site-wide, Person on author bios — is one of the highest-ROI SEO interventions you can make. We ship it via the Panth_StructuredData module on every project.

llms.txt is the robots.txt for AI engines — a structured page index at /llms.txt that tells ChatGPT, Claude, Perplexity, and Google AI Overviews which pages on your site are worth citing. It lists your CMS pages, top categories, blog posts, services, with one-line summaries.

Yes, your Magento store should have one. AI-engine traffic is a fast-growing 2026 channel — Perplexity is sending real e-commerce referrals already. Most Magento stores don’t even know llms.txt exists. Our open-source module auto-generates it on every cron, alongside robots.txt and sitemap.xml. Free win.

Four things: (1) ship /llms.txt — the AI page index. (2) whitelist GPTBot, ClaudeBot, PerplexityBot, and Google-Extended in robots.txt (most templates accidentally block them). (3) use rich, factual content on key pages — AI engines cite pages with clear claims, dates, prices, and structured data. (4) publish content that answers questions directly — FAQ-style headings (“What is X?”, “How do I Y?”) get cited far more often than marketing copy. We do all four as part of the SEO Project tier.

No — and anyone who guarantees first-page rankings is lying. Search results depend on competition, content quality, backlinks, brand authority — none of which are fully under our control. What we do guarantee in writing: Lighthouse 95+, structured data on every page type, hreflang validity, zero index loss vs. baseline, and llms.txt shipping. Those are the technical floors that enable ranking. The actual ranking moves come from the combination of clean technical SEO + content + time. We’re honest about the difference.

Three timeframes: (1) Technical fixes (structured data, Core Web Vitals, hreflang) — 2–6 weeks to show in GSC impressions / position. (2) On-page changes (titles, metas, internal links) — 4–8 weeks for Google to recrawl + reindex + rerank. (3) Content + link-building — 3–6 months for a new pillar page to land on page 1 for competitive terms. Anyone telling you faster is selling snake oil. We send a 30-day position-tracking report after launch so you can see the curve as it bends.

Technical SEO is everything that affects how search engines crawl, render, and index your site — sitemap, robots, structured data, canonicals, hreflang, page speed, mobile-friendliness, redirects, internal linking architecture. It’s the floor. If technical SEO is broken, no amount of content fixes it.

On-page SEO is what’s on each individual page — title tag, H1, meta description, headings, body copy, image alt text, internal links to / from. It’s how you rank for a specific keyword once technical SEO has unlocked indexing.

Magento needs technical SEO first. Doing on-page work on a site with broken hreflang or no structured data is rearranging deck chairs.

Both — and the order matters.

• Before migration: baseline crawl (Screaming Frog), full GSC export, current Lighthouse scores, ranking snapshot for top 100 keywords. This is your “don’t-break-it” reference.
• During migration: preserve URLs, set up 301s for any URL changes, port hreflang and canonicals, port structured data.
• After migration: immediate post-launch crawl, diff against baseline, fix any 404s / redirect chains, resubmit sitemaps to GSC, monitor for index drops over 30 days.

Migrations done without an SEO playbook routinely cause 20–60% organic-traffic drops. Done with one, the loss is zero or near-zero.

Hreflang tells Google which version of a page to serve to users in different countries / languages — e.g. en-GB for UK shoppers, de-DE for German shoppers. Done right, it routes the right user to the right store view and prevents duplicate-content penalties.

It’s almost always broken because of three foot-guns: (1) missing reciprocal tags — if page A links to page B with hreflang, B must link back to A. (2) hreflang loops — A points to B, B points to C, C never points back. (3) wrong locale codes — en_UK instead of en-GB. Magento’s default multi-store setup ships hreflang in the page header but doesn’t validate it. Our audit catches all three on every project.