Redesigning a site has a lot of challenges for keeping the hardly-earned organic traffic. A faulty redesign or migration will no doubt result in a loss of traffic and rankings. The right steps to take are: Audit the old website in regards to content, structure, and performance. It would be best if you found out what works well, which pages to keep, how much material is required, and in what topics, how to structure the content. Then it passes to doing the redirects (no more than a chain of 2), inserting the tracking pixels, setting goals in analytics, taking extra care not to create duplicate content issues, etc.
There should be no interruption in website operation for both visitors and search engines. Ideally, you work on the redesign/migration project offline and, only when ready, you switch to the new setup in less than an hour. The migration should happen during the less-busy visiting hours of the day. It is best to put a notification for visitors that you’re changing the looks of the site and share the news with your subscribers.
The biggest problems I’ve seen with website migrations are 301 redirects, content missing, and tracking pixels lost. 301 redirects are paramount to keeping some of the old rankings (you should expect that not all of the link juice will pass onto the new site) and the same with its traffic (due to their past positions about to be changed when Google reads the new pages).
Additionally, you could improve the site performance if you apply a responsive template to help people who browse from mobile devices and facilitate the rankings in Google’s established mobile index. Speed is also a ranking factor so a responsive modern design with not many SEO blockers will help a lot.
Things will get smooth with organic traffic if you have a detailed plan to follow, like a checklist. Your in-house team can prepare the list or ask an SEO professional to compile it for your developers.
The list I share below should include your additional requirements, and you may skip some steps if not applicable to your website. Some elements may not fit in your design or remotely break something, but that’s for the developer to decide.
Make Plans and Take Backups
The very first step is to take one or more backups as you work with different versions in case you need to retrieve old elements or restore to a previous version that worked OK.
Assuming you have researched the current status of your competition, you need to run an audit on the old website to find what content performed well SEO-wise and build a sitemap or keyword/topic map in Excel or in any Visual mapping software that maps the content/keywords to landing pages.
HTTPS is the new standard: Websites with insecure protocols don’t get good rankings; the domain address shows warnings before visiting, it isn’t good for UX and SEO rankings not to have enabled HTTPS.
It is imperative to create and work all changes in a testing environment either online or offline before your site goes live. This way, you have full control of all things that could go wrong with the new template and the database before publishing it to the world. It doesn’t look good for a brand when broken templates, database errors, and missing pages show up when working live on the main server. Keep in mind that a demo environment is not the same as a live server. Some errors may come up after deploying the new setup i.e., different PHP versions, file ownership, and caching systems, but you will have fixed most of the mistakes by now on the demo server.
SEO tip: Don’t leave the demo server open to search crawlers. You will end up with multiple page versions of the site: old, demo, final, all of them showing up in Google. I have seen embarrassing stuff left public by web engineers while working on new website versions of Fortune 500 companies. Google will keep all these trash results for years if web developers don’t do their job right.
FIX CORE WEB VITALS
Core Web Vitals measure user experience on 6 areas
if you fix all of them you get a perfect score (90+),
visitors will convert more and your rankings will improve.
Mapping and Migrating Content
Some content and structural elements from the old site that have proven efficient should be kept in the new design. SEO-wise mature content is valuable to keep the traffic flowing. Maintaining the old URL structure and the content on the same landing pages is critical to SEO performance, like the wine that gets better as time passes. The only thing to change is to update the content by adding new ideas and correcting outdated facts. Other than that, we don’t remove the old content as many developers do, and then the analytics tank.
It’s an art to know how to structure the content even with new websites, keep the best-performing pages, and merge old content with new ones. How to map and migrate the valuable old structural elements into the new template while keeping page locations (the URLs) intact, so that search engines only notice the design changes but do not see the site losing any content (and traffic) from pages that used to rank and convert.
You can’t avoid doing some redirects if you move old content to new pages. Many redirects signal a full migration and loss in rankings and traffic. A few necessary redirects will result in a few weeks of traffic reduction.
Most developers fail when executing this step: They move or erase content without any serious consideration and don’t do any redirects. There are also cases when programmers do three or more redirects (redirect chains) or 302 (temporary) redirects, which are very bad for SEO.
What Tools to Use
Google Search Console can help with website redesigns/migrations as it offers useful insights on page performance, inbound links, indexation, and rich structured data and it’s good to have a snapshot of the previous status. There are also external tools, i.e. Xenu, Screaming Frog that you can use to scan your website structure before and after the changes and see what worked well, what’s missing (404 errors), duplicate content issues, broken links, etc.
Doing the Migration
After taking the backup, having decided on the new structure of pages/URLs, and preparing the content, you are ready to upload it to your server via FTP. Ensure that the server root or sub-folder where the site will land is clean, not contain old files or hidden files (.htaccess).
Extra care should be given if you are switching hosts. PHP and MySQL versions should match the old and new servers for best compatibility—the same stands for scripts (WordPress, Joomla, eCommerce, etc.). Otherwise, databases and templates might break. In simple setups, there is a high probability that newer PHP, MySQL, and script versions will be backward compatible, meaning the site will work when moving to a more modern setup version from earlier versions. But why leave things to luck when you can design everything from the start?
Minimize the migration time for optimal UX: Websites that show a maintenance page for days or weeks, i.e., Coming soon, Work in progress, We’ll be right back, Scheduled maintenance, etc. are embarrassing for the brand.
Note that some servers take a bit of time to propagate changes. The optimal lapse between cleaning the file structure and deploying the changes should be a few minutes at the most and done in the least visited time of day, in the least visited day of the week (users’ timezone alert here).
I don’t know if I have to remind developers here that we never switch to a new host without first having some experience. We only switch hosts when we are satisfied with the server performance for respective website loads and hosting support.
What to Check after the Migration
It’s a good practice to allow both servers to live together for a few weeks before deleting the files from the old server to ensure the propagation has no issues. Setting up the website support emails is not an immediate SEO concern, but it’s good to have customer feedback. What’s more important is to have all the newsletters working OK to keep the inflow of traffic.
It is now time to check that your tracking pixels work OK on all pages, goals and conversions tracked, you don’t have 404 pages, no high bounce rates, no security flaws or scripting vulnerabilities.
Embarrassing reminder: Don’t leave the demo server open to the public and the search engines, and take it down after the testing period.
When Do Websites Need a Redesign?
Websites might need a redesign when they become less operational in one or more aspects. They might have usability problems, they don’t convert, the brand message is not conveyed with the current design, they don’t load fast, or need to follow modern trends (the requirement for mobile responsive sites is a good example).
From an SEO POV, we need to revamp a site if we need to change the entire content theme to compete in a different niche. We don’t have to change the template necessarily). Or inversely, we switch the template because we need a more efficient one for better SEO performance. Sometimes we do both tasks if it makes sense (for example optimize the speed). It is imperative to redo or audit the content when a website overhaul is scheduled.
How Much Does It Cost to Redo the SEO?
Typically, SEO costs are included in the redesign costs, and the final costs depend on how many pages we audit, revamp the content, and migrate. You may consider starting from $500 for 5-10 pages for a simple website to a few thousands of dollars for eCommerce sites or those with hundreds of pages. As with all professions, when you try to save money by hiring cheap SEO migrations, you end up with issues that will cost you a lot of money to solve and maybe even see an irreversible loss of organic traffic and a significant gap in your revenue.
How Long Does It Take to Redo a Site?
The total time to revamp the SEO depends on how many pages we deal with. It takes from a week for small websites to a few weeks or two months for massive websites. The working steps are niche research, old site technical audit, keyword mapping, landing page optimization, redirects, monitoring performance, and fixing issues.