Relaunch without flying blind
SEO support for your website relaunch
A relaunch changes URLs, technology and sometimes the domain. We make sure every old URL has a checked destination and that Google can pick up the new site without detours, based on 138 requirements from Google’s documentation and Search Central Live 2026.
- An inventory of every old URL before anything changes
- A redirect map, one row per URL, approved by you
- Checks on staging and on launch day
- An observation window timed to Google’s processing
- Also when another agency builds the site
When a relaunch costs visibility, and how to prevent it
It is rarely the design. Visibility is lost when URLs change without Google learning where the content went, or when the new technology shows Google less than visitors see. Typical causes:
- Our view
- Old URLs end on an error page or all land on the home page.
- Redirects run through intermediate hops, or are temporary (302 instead of 301 or 308).
- Staging’s noindex or “Disallow: /” goes live.
- Content, links or meta tags appear only once JavaScript runs.
- Language versions lose their hreflang links.
- The server returns errors in the first days after go-live.
Google’s site move guide advises against redirecting many old URLs to one irrelevant destination such as the home page: it confuses users and may be treated as a soft 404. Content that does not move should return 404 or 410.
- In Google's documentationHow to move a site (opens in a new tab)
With a temporary redirect such as a 302, Google keeps showing the old URL in results.
- In Google's documentationRedirects and Google Search (opens in a new tab)
How we support your relaunch
Five steps from inventory to review. Who takes on which step is agreed at scoping.
Inventory
We list every old URL from the CMS export, a crawl, sitemaps, Search Console and server logs, and record titles, canonicals and status codes as the baseline.
Redirect plan
One row per old URL: a destination with the same search intent, as a 301 or 308 in one hop, or a deliberate 404 or 410. You approve the table before it is built.
Staging check
We check the new site against the developer kit’s 56 must and avoid items, from redirects and canonicals to the rendered HTML of every template. Staging stays behind a password.
Go-live
A script tests every old URL against the table. We check robots.txt, the sitemap and robots meta tags on the live domain, and one URL per template in Search Console’s URL Inspection.
Observation window
We follow the Page indexing report, crawl stats and the old URLs until Google is likely to have processed the changes, and only then judge the result.
A community speaker at Search Central Live 2026 recommended the same core: freeze the inventory before launch, approve the redirect map, then test the live site against it. A 200 on every new URL only shows that the URLs work, not that the content people came for is still there.
How fast Google processes changes
Little happens in Search right after go-live, and that is normal: Google only processes a change once it has recrawled the page.
- Said at Search Central LiveD3-C665
about 24 hours
Google picks up a changed robots.txt
- In Google's documentationUpdate your robots.txt file (opens in a new tab)
- Said at Search Central LiveD3-C613
hours, at worst weeks
Content added by JavaScript reaches indexing (documentation: a page may wait in the render queue for a few seconds or longer)
- In Google's documentationUnderstand the JavaScript SEO basics (opens in a new tab)
- Said at Search Central LiveD3-C627
1–2 days, sometimes weeks to months
New titles and snippets show (documentation on title links: a few days to a few weeks)
- In Google's documentationInfluencing your title links in search results (opens in a new tab)
- Said at Search Central LiveD3-C657
hours to 2 weeks
Changed structured data is picked up
- Said at Search Central LiveD3-C646
1–3 weeks
A changed canonical shows (documentation: even after content issues are fixed, Google may keep pages clustered as duplicates for up to two weeks)
- In Google's documentationFix canonicalization issues (opens in a new tab)
- Said at Search Central LiveD3-C640
1–3 weeks
A page that returns 404 or noindex drops out of the index
- Said at Search Central LiveD3-C639
about 4 hours; raising it again 1–3 weeks
When server errors pile up, Google slows crawling; raising it again takes longer (documentation: Google slows down on 500, 503 or 429 and speeds up again once the errors drop)
- In Google's documentationReduce the Google crawl rate (opens in a new tab)
- Said at Search Central LiveD3-C618D3-C619
a few weeks
Moving a small to medium-sized site: most pages have moved
- In Google's documentationHow to move a site (opens in a new tab)
1–3 months
A whole site move, on average
- Said at Search Central LiveD3-C643
generally at least 1 year
Keep the redirects after a move
- In Google's documentationHow to move a site (opens in a new tab)
Two real relaunches
We show what was built, without ranking or traffic figures.
CDM Computerservice, Regensburg
Client website · live
CDM Computerservice
Old WordPress site replaced, all 13 pages carried over, every old page URL redirected with a single 301 to its new page.
ViewLeftovers of the old system return 410. All 13 pages are prerendered, each with its own title, description and canonical, plus a sitemap, robots.txt and structured data. After launch we checked the site against all 138 requirements and shipped the first fixes, such as one-hop redirects.
Our own relaunch: ibramdawwa.de
Since 8 October 2026 our new site runs on ibramdawwa.de instead of www.ibramdawwa.de, with new paths, so to Google it is a move. Old URLs with a same-intent page redirect there in one hop, for example /privacy-policy to /datenschutz.
One day after launch we checked the live site against all 138 requirements. The audit found gaps too, first of all a Search Console property that was not yet verified. Since 10 October 2026 the domain has been verified in Search Console and Bing Webmaster Tools and the sitemap submitted; we are working through the other findings by priority. If the app goes down, the server is set up to answer 503 for pages and keep robots.txt available; we have not yet tried this in a maintenance drill.
When another agency builds the site
You do not have to have the new site built by us. If another agency or your own team builds it, we take on the search side. What we check and sign off on launch day:
- Redirect map: every old URL has an approved destination or a deliberate 404 or 410.
- Redirects: 301 or 308, one hop, no home page as a catch-all.
- Canonicals, hreflang, internal links and the sitemap point at the same final URLs.
- No block left over from staging in robots.txt or robots meta tags.
- Content, links and meta tags are in the rendered HTML of every template.
- Search Console verified, sitemap submitted, change of address filed for a domain change.
Each finding comes as a ticket with “Why”, “How” and “Test”. Your team fixes it, we re-check and record every item as passed, partly passed or open.
Special cases: JavaScript frameworks, several languages, domain changes
JavaScript frameworks
Moving to React, Next.js, Vue or Angular often silently changes what is in the served HTML. Google queues every page with a 200 status for rendering, unless a robots meta tag or header rules out indexing, and its documentation sets no upper limit on the wait.
- In Google's documentationUnderstand the JavaScript SEO basics (opens in a new tab)
At Search Central Live it was said that content added by JavaScript usually reaches indexing within a few hours, and at worst within weeks.
- Said at Search Central LiveD3-C627
So the main content, links and meta tags belong in the served HTML; we compare it with the rendered HTML for every template.
- Our view
Several languages
Google recommends a separate URL for every language version. Googlebot mostly crawls from US IP addresses without an Accept-Language header, so content that adapts to the visitor’s country or language may not be crawled in every version.
- In Google's documentationHow Google crawls locale-adaptive pages (opens in a new tab)
hreflang has to work both ways: if page A names page B as a language version, B must link back to A, or Google ignores the annotations.
- In Google's documentationTell Google about localized versions of your page (opens in a new tab)
Domain changes
Google’s site move guide names three steps besides the redirects: file a change of address in Search Console, submit the new sitemap and update internal links. Keep the redirects for as long as possible, generally at least a year.
- In Google's documentationHow to move a site (opens in a new tab)
Old URLs can still appear for a while, for example when someone searches for the old domain; Google’s redirect guide calls this normal. So judge the move in the new property’s Search Console reports, not with a site: query.
- In Google's documentationRedirects and Google Search (opens in a new tab)
- Said at Search Central LiveD2-C354
- Our view
Template: the redirect map
Get the redirect map as a template: one row per old URL, with destination, status code, intent, source, reason, check date and check result. Three example rows show the rules, including why the home page is no substitute.
Comma-separated CSV in UTF-8, for Google Sheets, Excel or your ticket system.
Download the template (CSV)Questions before you start
When should we bring you in?
Before any URL changes, ideally once the new site structure is settled. Before launch, redirects can be planned calmly; after launch they get fixed under pressure.
What does the support cost?
It depends on the scope, not on a package: how many URLs the old site has, whether the domain, platform or languages change, whether logs and Search Console access exist, and who builds the redirects. After a short scoping call you get a written quote, with no obligation.
Can you guarantee we will not lose rankings?
No, and nobody can honestly promise that. What we can promise: every old URL gets a checked destination in the map, we run the checklist before go-live, and afterwards you see what Google actually processes.
What access do you need?
Read access to Search Console, the old site’s server logs if possible, access to staging and a URL export from the CMS. You can revoke every access at any time.
How long does the support run?
From the inventory to the end of the observation window, whose length depends on the kind of change. The timeline is agreed at scoping.
Planning a relaunch?
Tell us your current URL, the planned date and who is building the new site. You get a scoped quote, no price list.