Hyvä Theme SEO Guide: Speed Gains, Schema Risks, and How to Protect Your Rankings

Magento stores running the Luma theme load an average of over 200 separate JavaScript and CSS files on a single page. Hyvä loads five. That single number, drawn directly from Hyvä's own technical documentation, explains most of why the theme has become the default recommendation for Magento merchants chasing better Core Web Vitals scores in 2026.

But speed is only half the SEO story. The other half rarely gets mentioned in Hyvä sales pitches: switching frontends can quietly strip out structured data your store already had, and losing that schema can cost you the rich results, star ratings, and price snippets that were driving clicks before you migrated. This guide covers both sides honestly: what the performance data actually shows, where the schema risk comes from, and the specific steps to protect your rankings through the switch.

What Does Hyvä Actually Change on the Frontend?

Hyvä is not a visual skin you drop onto Magento's existing frontend. It is a full rebuild. The theme removes RequireJS, KnockoutJS, jQuery UI widgets, and LESS, the stack that Luma has relied on since Magento 2 launched, and replaces it with Alpine.js for interactivity and Tailwind CSS for styling. Every template, every layout XML file, and every piece of JavaScript gets rewritten from a blank starting point.

That rebuild is exactly why the performance gains are real and not marketing spin. It is also exactly why anything Luma was quietly doing for you under the hood, including default structured data output, does not automatically carry over. You are not upgrading a theme. You are replacing the entire presentation layer of your store.

The Speed Gains: What the Data Actually Shows

Start with the numbers Hyvä publishes directly. According to Hyvä's own technical documentation, a typical Hyvä storefront loads 5 page requests compared to roughly 230 on a standard Luma store, a 98% reduction. Page weight drops from around 3MB uncompressed on Luma to about 0.4MB on Hyvä, an 86% reduction. Those aren't isolated demo store numbers; they describe the structural difference between a theme built on legacy Magento frontend libraries and one built from scratch.

Where does that translate on the open web? HTTP Archive's 2025 Web Almanac, which analyzes real Chrome User Experience Report data across millions of live sites, found that 48% of mobile pages and 56% of desktop pages achieved a good Core Web Vitals score in 2025, up from 44% and 55% respectively the year before. Broken down further, 62% of mobile pages hit a good Largest Contentful Paint score and 77% hit a good Interaction to Next Paint score. Those are the exact metrics Hyvä is engineered to pass by default, since removing render-blocking JavaScript and cutting DOM complexity directly improves LCP and INP.

Several Hyvä partner agencies also cite figures from HTTP Archive's Core Web Vitals Technology Report, a public dashboard that lets you compare CWV pass rates by CMS and frontend technology. As of a November 2025 snapshot cited by multiple Hyvä agencies, Hyvä-based Magento stores were passing Core Web Vitals at roughly 65%, compared with around 41% for standard Luma stores. That dashboard updates continuously, so treat any specific percentage as a point-in-time figure rather than a permanent benchmark, and check the live report yourself if you want the current split for your comparison set.

The pattern across all these sources agrees on direction, even where the exact numbers vary: Hyvä stores pass Core Web Vitals at meaningfully higher rates than Luma stores, and the gap is large enough to matter for a store sitting near the needs-improvement threshold.

Does Speed Alone Move Rankings?

Here is where a lot of Hyvä content oversells the story. Google's own Search Central documentation is explicit: there is no single signal, and Google's core ranking systems consider a variety of signals that align with the overall page experience. Core Web Vitals are one input among many, not a standalone ranking factor you can max out and expect a guaranteed jump.

Google's guidance goes further, warning site owners against treating a perfect Core Web Vitals score as an SEO shortcut: getting a good score in Search Console's Core Web Vitals report does not guarantee top rankings, since page experience is evaluated holistically alongside content relevance, quality, and other systems. Where Core Web Vitals matter most is as a tiebreaker. When two pages are otherwise similarly relevant and useful, the faster, more stable one tends to win the edge.

That is still a meaningful reason to migrate. If your product pages are competing against other Magento stores on Luma, and yours loads in under a second while theirs takes three or four, you are not guaranteed the top spot, but you have removed one variable that could be costing you the tiebreak. The honest framing is that Hyvä buys you a fair shot at ranking on merit rather than losing to slower competitors on a technicality.

The Schema Risk Nobody Warns You About

This is the part most Hyvä migration guides skip entirely, and it's the reason a straightforward speed upgrade can quietly turn into a rankings problem.

Magento's default Luma theme outputs basic Microdata for products directly in its templates. It's incomplete by most SEO standards, missing several recommended fields, but it exists by default, hardcoded into the theme's meta tags across multiple templates. When your store runs on Luma and no dedicated SEO extension is installed, you are still sending some product-level structured data to Google, even if it's thin.

Hyvä does not include that. Because the theme is built from a blank slate, it ships with no product schema out of the box. If your store's structured data was coming entirely from Luma's default markup rather than from a dedicated extension, migrating to Hyvä without replacing that schema means your product pages go from some structured data to none the moment you flip the switch.

Why that matters comes straight from Google's own documentation on how structured data works. Google's intro to structured data guide cites several real case studies of the click-through impact: Rotten Tomatoes measured a 25% higher click-through rate on pages enhanced with structured data compared to pages without it, the Food Network converted 80% of its pages to enable search features and saw a 35% increase in visits, and Nestlé found that pages appearing as rich results earned an 82% higher click-through rate than non-rich results. Structured data does not move your ranking position directly, Google has confirmed that repeatedly, but it strongly influences whether your listing gets the click once it's on the page. Losing your schema during a Hyvä migration doesn't drop your rank; it quietly erodes the click-through rate you were getting at that rank.

The good news is this problem is entirely preventable, and it does not require abandoning Hyvä. It requires treating schema replacement as a required migration task rather than an afterthought.

How to Protect Your Rankings During a Hyvä Migration?

Prerequisites

Before you touch a production environment, confirm three things: you have a staging copy of your live store, you have current Core Web Vitals and Search Console data as a before/after baseline, and you know exactly what structured data your live site currently outputs. That last one is easy to skip and is the one that causes the schema regression described above.

Step-by-step Protection Checklist

1. Audit your current structured data before migrating. Run your live product, category, and CMS pages through Google's Rich Results Test and note every schema type currently detected: Product, BreadcrumbList, Organization, Review, FAQPage, whatever is present. This is your baseline. If you skip this step, you won't know what you've lost until rankings or click-through rates already show it.

2. Decide where your schema will live post-migration. You have two realistic options. Either install a dedicated SEO extension that generates JSON-LD server-side and is confirmed compatible with Hyvä, such as MageDelight's Advanced SEO Suite, which includes rich snippets, canonical handling, and XML/HTML sitemaps in a single module, or work with your development team to hand-code JSON-LD templates for each page type. The extension route is faster and easier to maintain across catalog updates; the hand-coded route gives more control if you have unusual schema requirements.

3. Prefer JSON-LD over Microdata. If you are rebuilding schema from scratch during the migration, use JSON-LD rather than Microdata or RDFa. Google's own guidance notes JSON-LD is the format it recommends in most cases, since it sits in a separate script tag instead of being woven into your HTML, which makes it far easier to validate, update, and keep in sync with Hyvä's Alpine.js-driven templates without accidentally breaking markup during a future theme update.

4. Test on staging before go-live. Once your schema module or custom code is in place on staging, run every major page type back through the Rich Results Test and compare the detected types against your Step 1 baseline. Confirm Product, Organization, and BreadcrumbList schema are present at minimum, and that required properties like price, availability, and SKU are populating correctly from your catalog data.

5. Monitor Search Console for 4 to 6 weeks after go-live. Core Web Vitals field data in Search Console runs on a rolling 28-day window built from real user sessions, so lab scores on staging will look better than your live field data for the first month. Watch the Rich Results reports under Enhancements in Search Console specifically, not just the Core Web Vitals report, since that's where a schema regression shows up first as a drop in valid items.

6. Re-submit your sitemap. After go-live, resubmit your XML sitemap through Search Console so Google recrawls your pages sooner rather than waiting for its normal crawl cycle to pick up the new markup.

Common Mistakes After Migration

The most common failure isn't a broken migration; it's an incomplete one. A few patterns show up repeatedly:

• Assuming Hyvä's speed does the SEO work automatically, and never checking whether schema survived the switch.
• Installing a Hyvä-compatible extension without verifying it actually outputs schema on Hyvä specifically, since compatibility sometimes means it doesn't break the page rather than it generates the same markup it did on Luma.
• Judging results from a single Lighthouse run on staging instead of waiting for real Search Console field data, which can tell a very different story once actual mobile users on real networks are factored in.
• Treating structured data as a one-time task rather than something to re-check after every major catalog change or extension update, since a single broken product feed can silently invalidate schema across thousands of pages.

Hyvä vs Luma: Quick Comparison

FAQ

Here are quick answers to the questions merchants ask most often before migrating.

1. Does Switching to Hyvä Directly Improve My Google Rankings?

Not directly. Google has confirmed Core Web Vitals are one signal among many, and mainly function as a tiebreaker between pages of similar relevance and quality. Hyvä removes a real disadvantage if your store was previously failing Core Web Vitals, but it doesn't override content quality or relevance.

2. Will I Definitely Lose My Rich Results When I Migrate?

Only if your structured data was coming from Luma's default theme markup with no dedicated extension. If you already run a schema-generating SEO extension that's confirmed Hyvä-compatible, your rich results should carry over as long as you verify it post-migration.

3. Is Hyvä Actually Free Now?

The core Hyvä Theme became free and open source under OSL 3.0 and AFL 3.0 licenses in November 2025. Paid add-ons like Hyvä Checkout and Hyvä UI remain commercial products.

4. How Long Before I See the Ranking Impact of Migrating?

Core Web Vitals field data needs roughly a 28-day rolling window to update in Search Console, and Google's crawl and reindexing cycle means the fuller SEO impact typically takes several weeks to a few months to show clearly.

5. Do I Need a New SEO Extension After Switching to Hyvä?

If your current extension isn't confirmed Hyvä-compatible, yes. Even if it is compatible, verify it directly with the Rich Results Test rather than assuming compatibility means identical output to what you had on Luma.

Protecting the Migration, Not Just the Speed

Hyvä's performance case is real and well documented, both from Hyvä's own technical numbers and from independent HTTP Archive data. That's reason enough for most Magento merchants still on Luma to take the migration seriously. But the SEO story only holds up if you treat it as a two-part project: the frontend rebuild that Hyvä handles, and the structured data audit that nobody hands you by default.

If you're planning the switch, MageDelight's Hyvä Theme Development services build the schema audit and replacement into the migration process rather than leaving it as a gap to discover after launch, and every MageDelight extension, including Advanced SEO Suite, ships Hyvä-compatible at no additional cost. Get the speed gain and keep the rich results. There's no reason a Hyvä migration should cost you either one.