Frequently asked questions

Before the new URL structure is finalized, which is usually six to ten weeks before launch. That is the last point at which structural recommendations are cheap to act on. Later still helps, but the work shifts from shaping the migration to protecting it.

For a well-executed migration, two to six weeks of volatility and a return to range within one to three months. Domain changes and consolidations sit at the longer end. Site size and crawl frequency matter more than most other factors.

Short-term movement is normal even when everything is done correctly, because Google recrawls and reprocesses at its own pace. Permanent loss is not normal and almost always traces to unmapped URLs, redirect chains, accidental noindex directives or content that disappeared in the move.

A row-per-URL document stating where each old URL goes, what status code is used and why. It matters because it is the only artifact that makes redirect coverage checkable. Without one, nobody can answer whether a specific URL was handled — including whoever wrote the rules.

No. Google treats a redirect to an irrelevant page as a soft 404, so the old URL loses its rankings and the homepage gains nothing. Redirect to the closest genuinely relevant page, or return 410 Gone deliberately where nothing relevant exists.

One. Googlebot follows up to ten hops before giving up, so a chain will usually resolve, but every hop costs crawl budget and adds latency for real users. Two is tolerable as a temporary state; anything longer should be collapsed before launch.

It depends on whether you need implementation capacity. An agency staffs parallel workstreams and covers absence. A consultant gives direct access to the person doing the work. Migration work is judgment-heavy rather than volume-heavy, which suits consultant-shaped engagements more often than people expect.

No. Deliverables are specifications, maps and QA passes that your engineering team implements. Replacing a team that already knows the codebase mid-migration adds risk and a handover cost precisely when neither is affordable.

Ask two questions: who produces the redirect map, and what does the parity check compare field by field. Clear answers with named owners mean you are covered. "We will review the site after launch" describes monitoring, not migration coverage.

Diagnosis before planning. Separate redirect failures from indexation problems from genuine content loss — those three look almost identical in a traffic graph and need completely different fixes. Most post-migration losses are more recoverable than they first appear.

Valuable, not required. Logs are the only source showing what crawlers actually do rather than what you infer. Without them the work proceeds from crawl data and Search Console, and the limits of that are stated rather than papered over.

No, and no honest provider can — search results are not under anyone's control. What is controllable is whether every URL that earns traffic resolves correctly, whether the new site is crawlable and indexable, and whether problems surface before launch rather than after.

No. Website migration means the site moves and search traffic is at risk. SEO tool migration means moving rank tracking and reporting between platforms, where the risk is data portability. Different problems with an unfortunately similar name.

The scope narrows to what is still actionable: redirect coverage for traffic-carrying URLs, a staging parity check and launch-day verification. Structural recommendations are not actionable at that point and pretending otherwise wastes your money. Say the date up front.