Миграция на headless без потери SEO: план по шагам

A headless migration kills SEO when you plan it like a redesign. The URL structure changes, canonicals drift, hreflang breaks, the sitemap arrives two weeks late — and a month after launch you stare at Search Console showing a 40% organic drop with no idea how to roll back.

Here is the plan we use to move stores from 1C‑Bitrix to Next.js. Every step has an exit criterion. If the criterion fails, we don't move on. Slower up front — no postmortem at the end.

1. URL structure: 1:1 or a strict 301 map

The first decision to lock in before development starts: what happens to URLs. Two legitimate options:

• 1:1. Old Bitrix URLs are preserved byte‑for‑byte on the new frontend. This is the default rule: the new Next.js router accepts /catalog/
  // exactly as Bitrix did, and returns the same page. SEO history, email links, user bookmarks, the Google index — all keep working without a single 301.
• New structure + 301 map. If URLs are changing on purpose (trailing slash, category slugs), every old URL must map to an explicit 301. The map is built before development, not after. It ships at the moment traffic is cut over, not later.

Exit criterion: either a written "everything 1:1, no exceptions" or a CSV of old_url → new_url pairs covering every indexable URL on Bitrix. Don't fish for redirects after launch — every miss costs organic traffic.

2. Canonical: explicit self‑reference, no cross‑locale mistakes

Every page on the new frontend gets an explicit pointing at itself (no UTM, no hash, in the exact form that goes into the sitemap). Without it, Google is free to pick whichever variant it wants — www, non‑www, trailing slash or not — and merge your pages however it likes.

The painful one is cross‑locale canonicals. On a Russian + English site, the RU page must canonicalise to itself (/ru/foo), not to the EN mirror. The EN page — to itself. Hreflang manages the relationship; canonical manages identity. Mixing them up drops one of the languages from the index entirely.

3. Hreflang: a complete loop of reciprocal references

If the site is multilingual, hreflang must be on every page in every locale. The minimum set on a RU page:

Mirror the block on the EN page with the inverse references. If one side has a link and the other doesn't, Google treats it as broken and ignores hreflang entirely. The most common bug: new pages get added, hreflang gets forgotten, and the search engine spends a week deciding which page to surface — usually the wrong one.

Exit criterion: a CI e2e test that walks the sitemap, fetches hreflang for each page, and verifies the reciprocal link exists. Without the test, a human will miss it somewhere.

4. Sitemap delta: what was added, what was dropped, on which day

The new sitemap.xml is generated by the frontend (in Next.js this is usually app/sitemap.xml/route.ts) and must contain only indexable URLs: no thank-you, no /api/*, no legal pages, no noindex pages. Lastmod is the real last‑edit date, not the build timestamp.

Before traffic cutover, prepare three files:

• Old sitemap — a snapshot of the world before migration.
• New sitemap — what Next.js will serve on day‑X.
• Delta report — URLs removed (must 301), URLs added (must be indexable), URLs unchanged.

The delta is the single artifact that proves the migration is correct from the search engine's perspective. Without it, you'll be guessing at indexation graphs in Search Console.

5. Google Search Console & Bing Webmaster: manual submission

After launch, the new sitemap is submitted manually to every panel. Don't wait for the engine to discover the changes — that takes weeks, and rankings slip during that time.

• Google Search Console: Sitemaps → Add new → /sitemap.xml. After an hour, verify the sitemap was read with zero errors.
• Bing Webmaster Tools: Sitemaps → Submit Sitemap. Use URL Inspection on the top‑20 traffic URLs for the first week.
• IndexNow (Bing, Yandex): if the frontend supports it (Frontbox does), ping the protocol immediately on changes. You get re‑indexation in hours instead of days.

6. Pre/Post measurement: capture metrics before and after

Two weeks before cutover, capture the baseline:

• Organic traffic per day — median over 14 days.
• Top‑50 queries and positions for each (Search Console).
• Top‑200 pages by impressions and clicks.
• Core Web Vitals: LCP, INP, CLS (CrUX or Lighthouse).
• Share of sitemap URLs indexed.

After cutover, measure the same metrics daily for the first two weeks, then weekly. If anything drops more than 10% beyond normal volatility — investigate immediately, don't wait for it to come back on its own.

On a headless migration with a proper 1:1 structure, Core Web Vitals improve from day one (positive ranking signal) and traffic should not drop at all. If it drops — something broke technically. Investigation checklist follows.

7. Fallback rollback: a plan B that actually works

The most underrated piece is the rollback plan. If the new version tanks rankings after release, you must be able to flip traffic back in minutes, not hours.

How we run it on Frontbox:

• The old Bitrix frontend stays deployed and operational for the first month after migration.
• Traffic switching is done via DNS or an edge router (Cloudflare Workers, nginx upstream). Not via a big deploy.
• Phased rollout: 5% → 25% → 100% with a 2–3 day pause at each step, so a problem becomes visible before 100% of users feel it.
• Auto‑rollback triggers: 5xx>1%, LCP>4s at p75, conversion drop on the canary cohort exceeding 15%.

When a trigger fires, traffic flows back to Bitrix automatically. What follows is an incident review — not a fire drill.

Day‑X readiness checklist

The checklist we use to greenlight traffic cutover:

• URL map (1:1 or 301) is signed off.
• Canonicals render correctly on every indexable URL — verified by e2e test.
• Hreflang between ru/en is complete and symmetric — verified by e2e test.
• Sitemap.xml is generated by the frontend with real lastmod.
• Delta report between old and new sitemap is on hand.
• Robots.txt: AI bots allowed, sensitive paths blocked.
• OG/Twitter tags are migrated and valid (1200×630, alt, description).
• Schema.org is migrated — Organization, BreadcrumbList on every page, plus Service/Product/Article where appropriate.
• Core Web Vitals on the new frontend are green at p75.
• Analytics (GA4, server‑side tracking) is configured and sending events.
• Rollback mechanism is rehearsed (rolled out 1% and rolled back).
• Baseline metrics are captured over 14 days.

Why a headless migration helps SEO when done right

A technically clean headless migration usually delivers organic growth 2–4 months after the dust settles, because:

• Core Web Vitals on Next.js are typically 3–5× better than a stock Bitrix frontend. That is a direct ranking factor since 2021.
• SSR/SSG delivers full HTML on the first request — Google and Bing don't depend on JavaScript rendering.
• Schema.org is easier to maintain in a frontend codebase than in Bitrix templates.
• The sitemap is always current — it's generated from real data, not maintained by hand.

But all of that only works if you've gone through the seven steps above. Without them, headless becomes an elegant way to lose traffic.

Next step

If you run a Bitrix store and you're thinking about headless — start with a Catalog Probe: in 3 days we stand up a headless storefront on your catalog, measure the numbers, deliver a report. Whether to move forward into a full Headless Pilot is your decision — based on numbers, not slideware.

SEO migration is included: 1:1 URLs, canonical / hreflang / sitemap — all carry over automatically, and the traffic loss tends toward zero.