Refresh the website, preserve the journey
A WordPress relaunch should clarify your offer and support business growth. It can also change URLs, content and technical settings. For smaller companies, the priority is preserving useful customer journeys and detecting problems early. Treat preparation, launch and monitoring as one connected project.
Content and connections at a glance
Map before redesigning
Record important existing URLs and their appropriate destinations before finalising the new navigation.
Test instead of assuming
Check public pages, redirects and enquiry journeys against specific examples with named owners.
Monitor without promises
A disciplined process reduces avoidable mistakes. It cannot guarantee unchanged rankings or search traffic.
Before launch: define the scope and owners
A relaunch starts with decisions, rather than installing a different theme.
Define what will change: the design, content structure, or domain and hosting too? Retain useful URLs. Separate major changes where practical, so that later problems are easier to investigate. Appoint someone to approve the launch.
Save baseline search traffic, important landing pages and genuine enquiries. Include downloads, campaign destinations and frequently referenced content in the inventory. A low-traffic page may still produce valuable enquiries. Reflect those business priorities in the acceptance plan.
Editorial owner
Checks accuracy and decides which content can be consolidated.
Technical owner
Manages deployment, backups and a tested restoration route.
Project lead
Coordinates approval, availability and the checks after launch.
Give every important old URL a decision
A mapping table connects existing content to the proposed structure.
For each old address, record its destination, reason for changing it and expected response. Several articles can point to a consolidated guide that genuinely replaces their purpose. A discontinued service should not automatically redirect to an unrelated homepage.
For permanently moved content, Google recommends permanent server-side redirects, such as 301 or 308. Test the complete route to the final page. Without a relevant replacement, an appropriate 404 or 410 response can be preferable to a misleading redirect.
A small mapping example
/old-service/ leads to the relevant new service page. Navigation and links inside articles are updated to point directly to that destination.
Protect staging, then check production separately
The development environment and the public website need different settings.
Protect development with appropriate access controls. A noindex tag is not a security barrier. Google needs to fetch a page to see noindex; a robots.txt block may prevent this. Google's documentation explains the distinction.
Check WordPress addresses, media paths and stored links. Use a suitable migration method rather than uncontrolled database replacements. The WordPress migration handbook covers common scenarios. Verify production rules independently; the staging configuration may be unsuitable for public access.
- No accidental noindex instructions on important production pages.
- robots.txt permits the necessary public crawling.
- Canonicals identify the intended production URLs.
- Internal links do not point to staging.
Website checks across devices
At launch: accept real customer journeys
A working homepage alone does not prove that the relaunch succeeded.
Agree a deployment window when the relevant people are available. Back up files and the database, with a known restoration procedure. Decide how new orders and enquiries will be preserved. Restoring an older database must not silently overwrite those transactions.
Open public URLs without an administrator view. Check representative services, articles, categories and language versions on mobile and desktop. With Divi, examine global templates, menus and dynamic modules: the builder preview may differ from the page delivered to visitors.
- The old URL, redirect and final content match.
- The enquiry form reaches the correct inbox.
- Tracking records an intentionally submitted test enquiry.
- Menus, images and essential buttons work.
After launch: separate technical checks from results
Technical approval marks the start of monitoring, rather than its end.
Review the sitemap, internal links and indexability of important destinations. Search Console's URL Inspection tool distinguishes stored indexing information from a live test. A successful live test does not confirm indexing or predict which canonical URL Google will choose.
Compare suitable periods and separate branded searches from other queries. Falling analytics numbers may reflect changed measurement. Review search data, genuine enquiries and technical findings together before deciding on a cause. Record deployments and later fixes for context.
Immediately after approval
Check error responses, enquiry journeys and measurement events.
During the following days
Revisit important pages and investigate unexpected error reports.
Over the longer term
Assess search traffic, indexing and business outcomes together.
Agree a restoration plan and follow-up ownership
Decide in advance when a small correction will not be enough.
A complete outage, missing orders or broken essential functions may require restoring the previous site. Document triggers, decision-makers and recovery steps. Short-term ranking movements alone do not justify immediately switching back; investigate technical causes and measurement errors first.
Keep the mapping table and acceptance records. Working redirects need long-term ownership. Google's site-move guidance discusses temporary search fluctuations. A relaunch finishes with clear responsibility for monitoring and corrections, rather than the first screenshot of the redesigned homepage.
A practical acceptance standard
Essential journeys work, known issues have named owners, and the next joint review is already scheduled.
Plan the relaunch around clear acceptance checks
Need help with your WordPress relaunch? Discuss the starting point, responsibilities and verification tasks before committing to a launch date.
Frequently asked questions
Should every URL change during a WordPress relaunch?
No. Keep useful addresses unless there is a clear reason to change them. When content moves or is genuinely consolidated, record the appropriate replacement and test the redirect to its final destination.
Is noindex enough to protect a staging website?
No. It is an indexing instruction, not access control. Protect the development environment appropriately. Before launch, remove unintended indexing restrictions from production pages that should appear in search.
How long should redirects remain in place?
Google generally recommends at least a year, preferably longer. Existing links may still use old addresses, so keep destinations working and relevant.
When should I use Change of Address in Search Console?
Use it for eligible domain or subdomain moves, not a redesign or path changes within one domain. Check Google's requirements before submitting.
Can a relaunch guarantee no ranking losses?
No. Search systems may need to process changes again, and positions can fluctuate even after careful preparation. A reliable process reduces avoidable errors and provides clear checks, but cannot guarantee a particular outcome.
