The performance win of a Hyvä migration is the easy story. The SEO risk is the quieter one. Stores that migrate to Hyvä without a deliberate SEO plan routinely see organic traffic dips of 10 to 30 percent in the first 60 days post-launch. The dip is recoverable, and the long-term outcome is usually positive because Core Web Vitals improvements help rankings, but the dip is also entirely avoidable with the right preparation.
The mistake is treating the migration as a frontend project. The frontend is the most visible change, but the SEO surface is broader. It includes structured data, canonical URLs, redirect maps, internal linking patterns, sitemap generation, and the way the new theme renders markup that Google’s crawlers parse. Every one of those surfaces can be the source of an unintended ranking move.
Bemeir has run dozens of Luma to Hyvä migrations and the SEO discipline is the same on each one. The framework below is the one we use to keep organic search stable through the cutover and to set the store up for stronger rankings six months out.
The risk surfaces, ranked by impact
There are eight SEO surfaces that change during a Hyvä migration. Ranked by typical impact on rankings, they are: structured data, canonical URLs, server response codes, internal linking, page titles and meta descriptions, image alt text, page load performance, and sitemap accuracy. The first four account for roughly 80 percent of migration-induced ranking issues we have diagnosed. Performance is in the second tier because the changes are usually positive, but the structured data and URL changes can mask the gains.
The order matters because it tells you where to put the most diligence time. Most teams audit page titles and image alt text exhaustively and gloss over structured data. That is exactly backward. The remediation framework below works in the order above.
Structured data is the highest-risk surface
Luma stores often have years of accumulated structured data customizations. Custom product schema, organization schema, breadcrumb schema, sitelinks search box, FAQ schema on category pages. Some of it is well-formed. Some of it is broken in ways that Google has stopped caring about. A Hyvä migration that does not deliberately reproduce the same structured data risks losing rich snippets the store has been earning for years.
The first move is to inventory the structured data the Luma store actually emits. Use Google’s Rich Results Test against the top 20 pages by traffic and capture every schema type rendered. Save the JSON-LD output as a baseline. Compare what the Hyvä storefront emits against that baseline. The deltas are the work.
Most Hyvä themes ship reasonable defaults for product, breadcrumb, and organization schema. The custom additions, like the FAQ schema on category pages or the sitelinks search box implementation, almost always need to be ported deliberately. Bemeir has built helper modules for Adobe Commerce stores on Hyvä that consolidate the schema generation in one place, which makes the migration audit dramatically easier on subsequent changes.
The Google structured data testing tool and the Schema.org reference are the two surfaces you will live in during this audit. Set up monitoring after launch that alerts when any of the top product or category pages fails Rich Results Test, because schema regressions are common and silent.
Canonical URLs and pagination
Adobe Commerce has long-standing quirks in how it generates canonical URLs across category pagination, filtered navigation, and store views. Luma and Hyvä render these differently in ways that can produce duplicate-content signals if not handled.
The audit needs to cover four cases. First, the canonical URL on paginated category pages. Page 2 of a category should canonical to itself, not to page 1, and not to the category root. Second, the canonical URL on filtered category pages, where layered navigation filters generate URLs that should canonical back to the unfiltered category to avoid indexing every filter combination. Third, the canonical URL on store-view-specific pages, where each store view has its own canonical and hreflang signals. Fourth, the canonical URL on configurable product pages, where Luma’s URL generation for color or size variants can produce inconsistent canonical chains.
The fix is usually a Magento configuration audit combined with a Hyvä template audit. The Magento side controls what the application emits. The Hyvä side controls what gets rendered to the page. Both must agree. The Adobe Commerce SEO documentation is the reference for what the application should be doing.
Redirect map for the cutover
A Luma to Hyvä migration almost never changes URLs. The migration is theme-level, not catalog-level. But the practical truth is that URLs do change for a handful of reasons. The admin-managed URL key on some products may have been updated. The category structure may have been simplified during the migration. Static pages may have been consolidated. The blog or content layer may have moved.
Build a redirect map covering every URL that changed and every URL the team is uncertain about. Implement the redirects at the Magento URL rewrite layer for the cases that are catalog-driven and at the Varnish or Nginx layer for the cases that are not. Test every redirect in staging with a tool that follows the redirect chain to make sure there are no redirect loops or double redirects. The Google Search Central guide to redirects is the canonical reference.
The table below is the format we use for redirect maps. It is mechanical on purpose.
| Old URL | New URL | Type | Reason |
|---|---|---|---|
| /old-category | /new-category | 301 | Category renamed |
| /product-with-typo | /product-correct | 301 | URL key corrected |
| /blog/old-slug | /blog/new-slug | 301 | Slug standardization |
| /landing-page-defunct | / | 301 | Page retired |
Implement the redirects ahead of the cutover so they are tested in staging. Implement them at the layer that survives Magento upgrades, which usually means Nginx or Varnish rather than Magento’s URL rewrite table.
Internal linking integrity
Internal links are the most overlooked SEO surface in a migration. Luma stores accumulate internal links across category descriptions, CMS blocks, footer menus, header menus, and the hard-coded links in custom modules. The Hyvä migration touches all of these because the theme rebuilds the markup.
The audit needs to crawl the existing site and the new site, compare the internal link inventory, and identify links that have changed or disappeared. Common issues are footer or sidebar links that were hard-coded in Luma’s phtml templates and were not ported, category description links that lost their formatting in the data migration, and CMS block links that were attached to blocks that were renamed.
Screaming Frog or Sitebulb will produce these reports in an afternoon. The remediation is then a question of either porting the missing links into the Hyvä templates or updating the CMS content to restore them. Bemeir typically runs this exercise in the two weeks before launch and treats the link gap as a launch-blocking issue. Crawled internal links that disappear hurt the way ranking signals flow through the site even if no individual URL has changed.
Performance is an SEO surface
Hyvä’s performance gains are positive for rankings. Specifically, Core Web Vitals improvements translate into ranking improvements on mobile, where the signal carries the most weight. The store should be measuring LCP, INP, and CLS at the 75th percentile in Search Console’s Core Web Vitals report and watching the post-migration trend.
The trend is usually positive within 30 days. Search Console requires 28 days of field data to update its assessment, which is why the win does not appear immediately. The patience is rewarded. Stores that fail Core Web Vitals on Luma and pass on Hyvä typically see organic traffic improve by 5 to 12 percent in months three and four after migration, beyond the recovery from any short-term migration dip.
The Google Search Central guide to page experience covers the signals. The discipline is to keep the Core Web Vitals scores green after migration, because regressions are easy on a theme that is being actively developed.
Monitoring after launch
Three monitoring loops should be in place from launch day. The first is daily indexed-pages count in Search Console. If indexed pages drop by more than 5 percent in any week, investigate. The second is weekly organic landing page traffic by URL, compared to the prior 28-day baseline. The third is daily Core Web Vitals at the 75th percentile across mobile and desktop.
Combine these with a manual spot-check of the 20 highest-traffic pages weekly for the first eight weeks. View each page in a fresh incognito browser. Confirm structured data renders correctly. Confirm canonical URL is correct. Confirm internal links work. The manual check catches the long-tail issues that automation misses.
If you are running parallel storefronts on Shopify Plus, Shopware, or BigCommerce, the same monitoring discipline applies. The platform-specific schema and canonical patterns differ, but the monitoring questions are the same: indexed pages, organic traffic, rich snippets, Core Web Vitals, internal linking integrity. Build the dashboard once and reuse it.
What success looks like
A clean Hyvä SEO migration produces a recognizable trajectory. Indexed pages count is stable from launch day onward, with no more than a 2 to 3 percent dip in the first two weeks. Organic traffic dips by 5 to 10 percent for the first two to four weeks and recovers to baseline by week six. Core Web Vitals scores show improvement within 30 days and pass the green threshold by day 60. Rich snippets persist through the migration without visible loss.
A messy migration looks like this: indexed pages drops by 15 percent, organic traffic drops by 25 percent, and recovery takes three to four months. The difference between the two trajectories is almost entirely preparation. Stores that spend three weeks on SEO migration prep have the clean trajectory. Stores that treat SEO as a launch-day concern have the messy one.
Bemeir’s Hyvä migration practice treats the SEO preparation as a named workstream with its own lead, its own checklist, and its own go/no-go gate before launch. It is the cheapest insurance you can buy on a project that is otherwise an unambiguous win. The performance gains are real. The SEO risk is manageable. Both deserve the discipline.
