Domain migration engine that doesn't lose rankings
The client's SEO platform managed hundreds of domains, and every few weeks a batch of them needed to migrate — new domain, new hosting, same content, zero tolerance for ranking loss. Before us, migrations were tracked in a shared spreadsheet. Someone would set up 301 redirects manually, submit the change through the search engine's webmaster panel, then check back in a few days to see if it took. Half the time they'd forget to follow up. The other half, something would silently break — a redirect pointing to the wrong URL, a verification token that expired, a domain that fell out of the index with nobody noticing for two weeks.
migration engine
We built a migration engine inside the platform that treats each domain move as a state machine. A migration chain starts in a pending state, moves to execution once redirects are verified, then enters monitoring where the system watches indexing status and organic traffic for anomalies. Each transition is deliberate — the system won't advance a chain until every precondition checks out. Under the hood, it talks to the search engine's webmaster API to register host moves, pull indexing stats, and detect errors. Cron jobs run the sync cycle: fetch fresh data, compare it against the last snapshot, flag anything that drifted.
api and dependency chains
The tricky part was the webmaster API itself. Rate limits are tight and response times vary wildly — sometimes a call returns in 200ms, sometimes it hangs for 15 seconds before timing out. We had to build retry logic with exponential backoff and circuit-breaking so one slow domain doesn't stall the entire sync batch. On top of that, migration chains can form dependency graphs: domain A migrates to B, but B is already mid-migration to C. The engine resolves these chains before executing, preventing circular moves and ensuring the final destination is always reachable.
detecting silent failures
Detecting silent failures turned out to be the hardest problem. A 301 redirect can return the right status code today and quietly break tomorrow — the target page starts returning a soft 404, or the redirect chain grows an extra hop nobody added. We solve this with periodic snapshots: the system captures the full redirect path, final status code, and response headers for every migrated domain, then diffs against the previous snapshot. Any change triggers an alert — posted to the team's messenger and logged as a task in their project tracker automatically.
analytics and journals
The analytics layer gives the team two views: a journal showing every event in chronological order (migration started, redirect verified, error detected, migration confirmed) and an overview dashboard with aggregate stats — how many domains are in each state, average time to full migration, error rate by type. This turned migration reviews from a manual audit into a five-minute scan.
results
The system now handles 40-60 concurrent migration chains without manual intervention. Average time from initiation to confirmed migration dropped from two weeks of sporadic checking to four days of automated monitoring. The honest lesson here: the migration logic itself was straightforward — state machines are well-understood. What we underestimated was how much effort would go into compensating for an external API that behaves differently under load than it does in documentation. Building the system to distrust its own data sources — snapshotting, diffing, alerting on any drift — is what made it reliable.
Stack
Backend: Next.js 14 (Route Handlers), Prisma, PostgreSQL
Integrations: Yandex Webmaster API, YouGile API, Telegram Bot API
Scheduling: Cron-driven sync and snapshot jobs
Monitoring: Redirect snapshots, domain error tracking, Telegram alerts