Website relaunch: when it pays off and how existing URLs keep working

The software can no longer be updated. PHP branches get two years of full support, then two years of security fixes only. For 8.2, security support ends on 31 December 2026, and WordPress recommends PHP 8.3 or greater. A theme or CMS that breaks on a supported version, with nobody left to maintain it, is the clearest signal. Our PHP 8.2 guide shows how to test the switch first.

There is no mobile layout. Google indexes and ranks the mobile version of your content. A mobile version is not required but "very strongly recommended".

Nobody on your team can edit the content. If changing a photo needs a developer, the site goes stale.

Pages are slow, measured, not guessed. PageSpeed Insights shows field data from real visitors over the previous 28 days (about PSI). Good values at the 75th percentile: LCP within 2.5 seconds, INP of 200 milliseconds or less, CLS of 0.1 or less. The Lighthouse lab score cannot measure INP. Pages with little traffic fall back to data for the whole site, and a site with too little traffic shows no field data at all. Core Web Vitals "are used by our ranking systems", but chasing a perfect score "just for SEO reasons may not be the best use of your time" (page experience).

The structure no longer fits. New services, a second language, more locations, and a menu that still describes the company you were at launch.

Two checks for today: PageSpeed Insights on your home page and your three busiest landing pages, and your PHP version, in WordPress under Tools > Site Health > Info > Server or in your hosting panel.

If the software is current, the site works on a phone and the Core Web Vitals pass, rewrite the texts and replace the photos in the system you have. The addresses stay, and so does what Google knows about them.

Google's site move guide agrees: new domain, new CMS, new layout, "do them one at a time". Search Console help warns that if you combine a domain move with a new content and URL structure, "you will probably see some traffic loss".

Not sure which case you are in? For maintenance work we start with a free quick look at the code and tell you honestly whether to continue or to rebuild.

Google's site move guide builds the move on a map from old to new URLs. Collect the old ones from:

• your XML sitemap, where "your most important URLs" most likely are;
• the Search Console Performance report, tab Pages, with a date range longer than the default three months, exported (the export stops at 1,000 rows);
• the Page indexing report, whose example lists stop at 1,000 URLs;
• Links > External links > Top linked pages in the Links report, a sample of up to 1,000 rows;
• your analytics, in Matomo under Behaviour > Entry pages;
• your server logs;
• PDFs, images and downloads, which "might already be getting traffic from Google Search or links".

Put them in one spreadsheet: old URL, clicks, links, new URL, status. Sort by clicks: the top rows deserve the most care.

The best redirect is none: where a page keeps its content, keep its address. For the rest, follow the redirect rules in Google's site move guide and its redirect overview:

• Each old URL goes to its closest new equivalent.
• Use permanent server-side redirects, 301 or 308. With a temporary 302 or 307, Google keeps showing the old URL in results.
• Redirect straight to the final URL. Googlebot follows up to 10 hops, but where a chain can't be avoided, Google says "ideally no more than 3".
• Don't send many old URLs to the home page: that "might be treated as a soft 404 error". Pages you merged into one may all redirect to it.
• Dropped content returns 404 or 410, on a 404 page with your site's look and navigation. A "not found" page with status 200 is a soft 404, and Google excludes it from Search.

Three rows for a fictional site:

On the server, each old URL is one line. On Apache hosting the lines go into the .htaccess file in your web root. In WordPress, put them above # BEGIN WordPress, because WordPress overwrites any change between its markers. The nginx lines go into the site's server block, which needs access to the server configuration:

Redirect permanent "/webdesign.html" "https://www.example.com/services/websites"
Redirect permanent "/team/office.html" "https://www.example.com/about/team"
Redirect permanent "/team/sales.html" "https://www.example.com/about/team"
Redirect gone "/offer-2019.html"

location = /webdesign.html   { return 301 https://www.example.com/services/websites; }
location = /team/office.html { return 301 https://www.example.com/about/team; }
location = /team/sales.html  { return 301 https://www.example.com/about/team; }
location = /offer-2019.html  { return 410; }

Redirect gone and return 410 answer with the server's plain built-in error page. To show your own page, add ErrorDocument 410 /404.html (Apache) or error_page 410 /404.html; (nginx), pointing at a static page in your site's look.

1. The redirects go live with the new site. For small and medium sites, Google recommends moving all URLs at once.

2. Remove the noindex rules and robots.txt blocks from development as the redirects go live. In WordPress, untick the box at Settings > Reading > Search engine visibility. Google lists leftovers among the mistakes that "can prevent your new site from being indexed completely".

3. Internal links, menus and buttons point at the new URLs directly, because redirects "are slow for users".

4. Every page gets a self-referencing canonical with an absolute URL.

5. Bilingual sites update hreflang: each version lists itself and all others with fully qualified URLs, and Google ignores tags on pages that don't point at each other. Our head for the websites service page:

   htmlCopy

   <link rel="canonical" href="https://www.blax.at/digital/websites">
   <link rel="alternate" hreflang="en" href="https://www.blax.at/digital/websites">
   <link rel="alternate" hreflang="de" href="https://www.blax.at/de/digital/websites">
   <link rel="alternate" hreflang="x-default" href="https://www.blax.at/digital/websites">

6. Test every row. curl -sI <old URL> checks one URL. For the whole list, put one full old URL per line into old-urls.txt, for example https://www.example.com/webdesign.html, and run:

   bashCopy

   while IFS= read -r old || [ -n "$old" ]; do
     old=${old%$'\r'}   # drop the Windows line ending of a spreadsheet export
     printf '%s  ' "$old"
     curl -s -o /dev/null -L -w '%{http_code} %{num_redirects} %{url_effective}\n' "$old"
   done < old-urls.txt

   Pages that kept their address should show 200 0, moved pages 200 1 at the right target, removed ones 404 0 or 410 0. Two or more hops mean a chain, and a 404 after a redirect means a wrong row. For single URLs, the URL Inspection tool in Search Console shows what Google sees.

7. Submit the new XML sitemap in Search Console, and the old one for a while: its indexed count falls toward zero as the new one's rises. Google calls the redirect warnings on the old sitemap "normal". Then remove the old one.

The Change of Address tool is only for a move to another domain or subdomain, not for http to https, www or path changes.

Google says to "expect temporary fluctuation in site ranking during the move". Watch:

• the Page indexing report for jumps in "Not found (404)" and "Soft 404". Google "frequently" sees redirects to URLs that don't exist. After a fix, Validate fix "typically takes up to about two weeks";
• the Sitemaps report for errors;
• the Performance report, where clicks on the old URLs should fall while the new ones rise.

Update your profile links and ad campaigns, and ask the sites that send you the most visitors to link to the new URL.

Keep the redirects "as long as possible, generally at least 1 year". For users, Google suggests keeping them indefinitely. After a domain move, keep the old domain registered for at least a year, so nobody else buys it for malicious purposes. And on link credit: "301 and other permanent redirects don't cause a loss in PageRank."

Our Nuxt app used to serve the English pages twice, at / and under /en, and also answered /contact/ and /CONTACT, each as a page of its own. Our old hreflang even sent crawlers to /de/en/..., which returned 404.

Now a server middleware sends each variant one 301 to its canonical address: the /en prefix and the trailing slash go, capitals become lower case, all in one pass, and /de/en/... becomes /de/.... Old URLs of the earlier WordPress and static sites, like /home and /contact-us, have their own 301s, German mirrors included. The loop from step 3 on 4 November 2026:

https://www.blax.at/CONTACT  200 1 https://www.blax.at/contact
https://www.blax.at/en/contact/  200 1 https://www.blax.at/contact
https://www.blax.at/home  200 1 https://www.blax.at/
https://www.blax.at/comments/feed  404 0 https://www.blax.at/comments/feed
http://blax.at/Contact/  200 3 https://www.blax.at/contact

The last URL is wrong in protocol, host and path, so it takes three hops, within Google's "ideally no more than 3". Variants that differ only in the path take one hop.

Search Console still lists leftovers of the WordPress site that ran on blax.at before as 404, for example /comments/feed and wp-emoji-release.min.js. They have no successor, so 404 is the right answer. Had they been content pages, we would have lost their rankings: Google removes indexed URLs that return 4xx from the index.

We build company websites in WordPress or Nuxt: quick to load, easy for your team to edit and structured for search engines. Nobody can honestly promise that every ranking stays where it is after a relaunch, and we don't. Send us the address of your current site and what bothers you about it through the contact form.

If new content may be enough, start with the free website check. We look at what anyone on the internet can see, outdated software included, and within 3 working days you get the 5 findings that matter most, in writing. Or call us on +43 7235 233 85, Monday to Friday 8:00 to 15:00, weekends 9:00 to 12:00.