A website relaunch is often an important step for companies in Hamburg: the brand should feel more current, content should convert better, the technical foundation should become easier to maintain and organic visibility should stay stable. This is also where the risk starts. When design, CMS or framework changes, URLs, internal links, loading behavior, metadata, tracking and technical signals often change at the same time.
A relaunch is therefore not just a design project. It is a technical SEO, performance and quality project. Google itself documents in its site move guidance how much depends on a clean redirect mapping. For local businesses that want to be found for searches around agencies, consulting or software development in Hamburg, real reach is on the line.
A relaunch is a technical project, not just a redesign
The most common mistake is treating a relaunch as a design project and adding SEO and technology only shortly before launch. As soon as design, CMS or framework changes, URLs, loading behavior, metadata and tracking change simultaneously. Each of these layers is a separate risk, and all of them hit live traffic on the same day.
The financial stakes are real: a professional mid-market relaunch in 2026 typically costs between 25,000 and 60,000 euros according to market data, with simpler projects starting at around 8,000 euros. Anyone investing at that level should plan for technical leadership from the start, not only once rankings drop after go-live. That is why we tie relaunches to modern web development and measurable quality rather than a surface-level redesign.
Inventory and redirects: every old URL needs a decision
The first step is a complete inventory; without it, teams do not know which pages carry traffic, backlinks and conversions. A good inventory merges all indexable URLs from crawls, XML sitemaps, analytics and Google Search Console, together with titles, H1s, canonicals, organic landing pages and status codes. Old blog posts, PDFs, campaign URLs and image URLs are easily overlooked, and that is exactly where signals get lost.
Then every old URL needs a deliberate decision. Permanent changes are implemented server-side with 301 or 308; both lose no PageRank according to Google. Redirect chains such as old -> intermediate -> new should be avoided (ideally no more than three hops), and redirects should stay in place for at least 180 days.
| Decision | When | Implementation |
|---|---|---|
| One-to-one redirect | Direct new equivalent exists | 301/308 server-side |
| Topical redirect | Content merged into a related page | 301/308 to target page |
| No redirect | URL stays unchanged | – |
| 410 or 404 | Content intentionally removed, no alternative | 410 (or 404) |
For a more operational checklist, see Website Relaunch Without Losing SEO.
Define the canonical host, metadata and internal links
A relaunch is the right moment to define the canonical domain clearly. The website should answer consistently whether https://example.com or https://www.example.com is preferred, whether HTTP redirects to HTTPS, how trailing slashes are handled and whether canonical tags point to the final indexable URL. Canonicals are not a replacement for redirects when old URLs are permanently replaced.
New templates often change SEO elements unnoticed. So before launch, verify for every important page: a unique title tag, a meta description that matches search intent, exactly one clear H1, valid structured data and internal links that point to final URLs. On multilingual websites, German and English paths, canonicals and hreflang references must agree. Local pages should include relevant Hamburg signals, without keyword stuffing.
Plan Core Web Vitals and performance realistically
Performance is not created on the last project day; it lives in architecture, image strategy, JavaScript budget, caching and rendering strategy. Even before the relaunch it should be clear which page types are business-critical, whether pages render server-side, statically or on the client, and which performance budgets apply to JavaScript, CSS and images.
Core Web Vitals are not just score targets, they point to real user problems: slow main content, layout shifts and sluggish interactions. Three metrics matter today, and since 12 March 2024 INP has replaced the older FID metric.
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP (loading) | ≤ 2.5s | 2.5–4.0s | > 4.0s |
| INP (responsiveness) | ≤ 200ms | 200–500ms | > 500ms |
| CLS (visual stability) | ≤ 0.1 | 0.1–0.25 | > 0.25 |
The thresholds come from web.dev and are evaluated at the 75th percentile. Lighthouse lab data should be combined with field data from real user sessions. How we improve performance systematically is covered in our article on Core Web Vitals optimization.
Accessibility is mandatory under the BFSG
Accessibility is no longer an optional audit item; for many websites it is legally required. Since 28 June 2025 the German Accessibility Strengthening Act (BFSG) has applied, with no transition period for covered digital products and services such as online shops and many B2C offerings. The reference standards are EN 301 549 and WCAG 2.1 Level AA; violations can be fined up to 100,000 euros. Micro-enterprises with fewer than 10 staff and at most 2 million euros annual revenue are exempt for services.
A relaunch is the ideal moment to build accessibility in structurally: semantic HTML with a logical heading hierarchy, sufficient color contrast, keyboard operability, visible focus states, understandable form labels and alternative text. Planning this early avoids expensive rework and, as a bonus, yields a more robust structure for SEO. Learn more under accessibility and in our BFSG and WCAG checklist.
Tracking, go-live and post-launch monitoring
A relaunch without working tracking makes both success and errors invisible. Before go-live it should be clear which events are measured (contact requests, bookings, form and button events), which consent rules apply and whether the Search Console property points to the canonical domain. Launch day itself is not about new decisions but about a structured run-through: DNS, SSL and HTTPS redirect correct, canonical host unambiguous, no accidental noindex tags, robots.txt not blocking production resources, sitemap containing only final URLs.
After go-live the most important phase begins. During the first two to four weeks, 404 errors, indexing reports, organic clicks, ranking changes and Core Web Vitals regressions should be monitored closely. Minor volatility is normal; structural errors such as lost URLs, wrong canonicals or blocked resources are not. This is exactly where technical leadership pays off, because quality is measurable, as we show in Quality is measurable.
Next steps
Three questions clarify a relaunch's risk profile faster than any design discussion:
- Inventory: Is there a complete URL mapping including redirect decisions?
- Performance & accessibility: Are there defined budgets and a BFSG check before go-live?
- Control: Who monitors indexing, rankings and Core Web Vitals in the first weeks?
If you are planning a relaunch and want to clarify technical risks early, take a look at our web development or contact us directly through the contact page.
