A guide to redesigning a corporate website
A website renewal affects more than its visual design. Existing pages, search visibility and links from other sites all need a place in the new structure. A careful inventory and URL plan make the transition easier to manage.
Decide what the project needs to solve
A dated appearance may be one reason to review a site, but it does not define the scope on its own. Look at the problems the organisation needs to solve: mobile usability, publishing workflow, accessibility, platform maintenance and how well the site reflects the services people need.
Some issues can be addressed with a focused update; others call for broader changes to content, technology or structure. Assess the impact of each issue before choosing the size of the project.
Step zero: the content inventory
Before design begins, make an inventory of the existing URLs. Where data is available, add visits, search clicks and relevant actions for each page. Record its purpose, owner and any requirement to retain it as well.
Review each page and decide whether to keep it, combine it with related content, rewrite it or remove it. Base that decision on its value to users and the organisation, not on page count alone.
The most expensive mistake: an incomplete redirect map
Map each changed URL to the most relevant page in the new site, then use a permanent redirect when the content has moved or has a clear replacement. Sending unrelated, removed pages to the homepage can confuse visitors and may be treated as a soft 404. Consolidated content can point to its genuine replacement.
If a page has no suitable replacement, return a proper 404 or 410 response. A helpful not-found page can also offer search and links to key sections.
The pre-launch technical checklist
Check that canonical tags point to the preferred URL for each page, update the sitemap and submit it in Search Console. On multilingual sites, verify that language alternatives point to the correct, corresponding pages.
Before launch, review any noindex or crawl restrictions used on the staging site and remove them where the public pages should be indexed. Then check the live pages in Search Console to confirm that they are accessible to crawlers.
Monitor the site after launch
After launch, review server errors, not-found reports and redirect paths, then keep checking crawl and indexing reports in Search Console. Set the monitoring period to suit the size and risk of the migration.
Compare post-launch traffic and indexing with the baseline you recorded beforehand. Search visibility can fluctuate during a move; there is no single recovery timetable. If problems appear, review redirects, content changes and crawler access together.
Plan a workable schedule
The schedule depends on the number of pages, custom features, content work and internal approvals. Name content owners and decision-makers at the start, and leave time for review and testing before launch.