Often, an online project “grows” from a native CMS. Those who have already experienced an unsuccessful site migration well understand all the risks of an illiterate site transfer to a new CMS , so they warn in advance about the future work of an SEO specialist. But how to control all the nuances so that the site does not lose its position and traffic after the move?
I prepared a step-by-step checklist and a description of the actions of a search engine optimization specialist at all stages of transferring the site to a new CMS.
1. Preparation of technical tasks for implementation on the test site
An important feature of moving to another CMS is a technical audit, as well as all edits and SEO refinements need to be implemented anew on the new “engine”.
Often the site moves, because it was not possible to implement optimization improvements on the old one. It is better to familiarize yourself with the capabilities of the system in advance, to search for sites on this CMS, so as not to demand the impossible from the programmers.
Before starting work on a new site, or when there is already a “raw” test site, the SEO specialist should give the programmer a technical task:
1.1 To create a site structure with all types of pages. This is especially true if you were previously unable to create any types of pages on the old site. Don’t like the structure of the old site? It’s time to make all the necessary adjustments to it.
1.2 To generate URL structure for all types of pages. Of course, it would be nice to keep the URL unchanged, but this is almost impossible when changing the CMS. Therefore, you need to redefine the URL generation templates for all types of pages.
1.3 Meta information templates (Title, Keywords, Description, H1) for all types of pages. Here everything is individual. If you have manually optimized meta tags on some pages of your site, make a separate table with these meta tags for developers. If templates were used on the old site, they can be modified and implemented, or simply transferred.
1.4 Basic technical recommendations . About closing pages from indexing , configuring robots.txt, optimizing pagination pages, configuring server response codes, generating sitemap.xml and html-sitemap, configuring canonical, micromarkup, multilingualism, configuring automatic redirects (301), optimizing images.
1.5 Recommendations for the implementation of SEO-edits that were implemented earlier and need to be transferred, or that cannot be implemented on the old CMS. Couldn’t implement or optimize filter pages before? Add a separate detailed technical task for their implementation. There was no responsive version of the site? Add technical tasks for its implementation. Don’t forget to describe exactly what needs to be transferred.
2. Analysis of the test site and implementation control
After some time, the programmer announces the good news – the test site is available.
The main tasks at this stage:
2.1 Design Coordination. If you have designers working on the site, ask them to send you mockups. Prepare a list of clarifications, questions, comments. Write down all the questions you have, even small ones. Engage the customer in the discussion. Ask to edit the layouts or specify when the edits will be made. The clearer the layouts will be worked out, the less it will be necessary to edit on the test site. If there are no layouts, see everything directly on the test site and still prepare a list of clarifications, questions, and comments.
2.2 Control of implementation of technical tasks. You should not wait until the moment of release and hope that everything will be done exactly according to the TK. Ask the programmers to periodically show you the implemented points of the technical task.
2.3 Carrying out a usability mini-audit. Is it convenient for the user to perform the targeted actions? Is the information on the site conveniently located? Does sending all forms, shopping cart work? Here’s what to check first.
2.4 Conducting an audit of the test site. When the site is almost ready, conduct a small audit to see if there are any new critical errors.
- Does the basic functionality work?
- Is the information on the website correct?
- Are there any test pages or temporary texts left?
- Isn’t some quick view block generating redundant links?
- Are there new types of pages with dynamic URLs?
- Are there cyclical redirects?
3. Preparation of the technical task for transferring the site
As soon as the structure and new URLs are implemented, and all landing pages are available on the test site, start preparing the technical terms of reference for transferring the resource.
Important: this technical task will be supplemented until the site is moved and will contain items that will be implemented after the transition to the new CMS.
3.1 What should be done before moving to a new CMS?
3.1.1 Backup. Before the transfer, ask the programmers to make a backup of the old and new site. In case of unforeseen circumstances, it will be possible to quickly roll back the changes.
3.1.2 Table of old 301 redirects. If the site’s URLs have been changed in the past (and this, most likely, happened if the site was worked on), the old site already has its own table of redirects. It is necessary to ask the programmers to transfer it to the test site.
Why is this important? This table is often forgotten and a redirect is configured only from the existing pages of the old site.
Like this:
https://site.com/old-url → 301 → https://site.com/new-url
In this way, the old pages of the old site remain without redirects during the transfer, resulting in a 404 error:
https://site.com/old-old-url → 404
As a result, the site loses some referral traffic, especially if the old pages were promoted and linked to. In addition, there are almost always links to old pages in social networks.
In addition to downloading the table of redirects, at this stage you need to additionally insure yourself.
How to do it?
3.1.2.1 Download from Google Analytics the pages that bring the most traffic in a year or two. To do this, you need to go to the “Channels – Organic Search” report, select the desired dates and the main parameter – “Login page”. Next, choose to display 500-1000 lines on a page and click “Export”.
3.1.2.2 Download pages with external links from Ahrefs. To do this, you need to go to the service, enter the domain of the site and select “Export”.
In the table, we are only interested in the “Link URL” column, that is, those pages of our site to which external resources link.
3.1.2.3 Combine two tables and remove duplicate pages (you can use Notepad++ with the additional extension TextFX):
3.1.2.4 The list of all URLs should be summarized in a separate table and the response codes of the pages should be checked to understand which pages are currently available.
Punching can be done using Netpeak Сhecker.
If the redirect table of the old site is transferred correctly, all previously loaded pages on the test site will return a 301 response code:
https://test-site.com/old-old-url → 301→ https://test-site.com/old-url → 301 → https://test-site.com/new-url
To check the response code and the correctness of the redirects setting, it is enough to change the domain of the main site to a test one and check the URL in Screaming Frog with the Status Code and Redirects options enabled. It is also worth going through the redirect chain – the response code may be 301, but the redirect is set to the main page.
3.1.3 Table of new redirects. Setting up 301 redirects is necessary first of all so that the search bot immediately understands that changes have taken place on the site and the page is now available at a different address.
Register all redirects with the domain of the test site. Yes, you are setting up a redirect from non-existent test site pages to test site pages. But this way you can easily check the correctness of the redirect settings on the test site. During the transfer, the domain of the site will change, everything will fall into place and redirects will already be configured.
How to make a table of redirects?
- Download all target URLs from the old site using Screaming Frog.
- Match them with similar URLs on the new site.
- If there are no similar pages on the new site, you do not need to configure the redirect, you need to give a 404 response code.
- If you have a medium-sized online store or site, it is better to map pages for categories and subcategories manually, and then tabulate. You can simply download the product card pages and entrust the comparison to the programmer.
An example of a table of redirects:
When the site is large, manually comparing pages is long and time-consuming. In this case, all the work falls on the shoulders of the programmer — the SEO specialist only needs to download all the pages of the old site, and after setting up, check the response codes of the previously downloaded pages.
If on the old and new sites all URLs were formed using different rules (and not simply set manually without any logic and structuring), the programmer will set up a dynamic redirect without effort.
It’s another matter if the URLs were formed manually and anyway. It is unlikely that a programmer will be able to configure redirects without a corresponding table. Although the method of matching by article is sometimes used for product cards.
When creating a table of redirects, keep in mind service pages, blog pages, news pages, etc. Don’t forget about subdomains if you have them.
No matter how you configure 301 redirects, store all URLs from the old site in tables before migration. So you can always quickly check the answer codes. It will also be your backup (just in case).
3.1.4 Transferring content from the old site to the test site. If you do not transfer the content to the test site, it will simply be lost during the move. And this can significantly affect the ranking of the page.
Give clear recommendations about what content should be transferred to the test site:
- texts from pages of sections, categories;
- texts from pages of optimized filters (if any);
- content from product cards — description texts, reviews, videos, characteristics;
- all information from service pages, article pages, service pages or blog.
Again, if the site is small, you can analyze each text, make a table of transfer of texts on the site for the main sections and categories. Otherwise, you will have to rely on the client’s programmer or content manager, selectively checking the presence of texts.
3.1.5 Verification files. Ask your developers to leave the Google Webmaster Panel verification files in the root directory of the site so that accesses are not lost during migration.
3.1.6 Synchronization of information. The current product base is often uploaded to the test site and not updated. But before X-day, all information on the site must be synchronized. These are prices for goods (services) and statuses (in stock, out of stock).
3.1.7 Notification of other specialists. Be sure to write in the terms of reference that the programmer or client will notify specialists who work with contextual advertising or advertising in social networks that the URL will be changed and the migration to the new CMS will be carried out. Specialists should also clarify which codes they need to transfer.
3.1.8 Highlight in a separate clause in the terms of reference that the transfer must be carried out only after approval by the responsible SEO specialist.
3.2 What should be done after moving to a new CMS?
3.2.1 Settings of analytics systems . Be prepared that all analytics settings will crash after the transfer. Set up the analytics of the updated site at the last stage of the site’s readiness, when all forms, buttons, and the shopping cart are available for testing.
What should be included in the terms of reference for setting up analytics:
- recommendations on the implementation of tracking codes (Google Analytics or Google Tag Manager with already implemented codes of statistical systems);
- e-commerce settings (for e-commerce projects);
- setting up tracking of the necessary events.
3.2.2 Configuring robots.txt. Often, robots.txt settings are transferred from the test site — as a result, the main site is closed for indexing. Write the necessary robots.txt instructions so that they can be quickly implemented after the migration.
3.2.3 Generate Sitemap.xml. The sitemap.xml file is also often transferred from the test site along with the test site URL. At this step, you need to ask the programmer to update the file so that it contains the pages of the main site. You also need to configure auto-update of the file once a day.
3.2.4 Replacing internal links with current ones. All links (menu, links in texts, links in next, prev, canonical attributes) must be relevant, that is, they must not belong to the test site.
In addition, after setting up 301 redirects, hyperlinks in texts can give internal 301 redirects. After the transfer, you can download them and send them to the content manager for correction.
3.2.5 Checking indexing settings. Describe the main indexing settings that will need to be checked. This point will be a guideline for both you and the programmer.
Pay attention to the indexing settings of filters and their intersections, service pages.
Planning to move on Friday or at the weekend is a bad sign 😉
4. Inspection and control after the transfer of the site
4.1 After moving, first check robots.txt and redirect settings. See if the landing pages are closed with the meta tag <meta name=”robots” content=”noindex, follow” / >.
4.2 Check the meta information on each page for duplicates.
4.3 Check the operation of all forms, the basket.
4.4 Check that at least the statistics counters are transferred first. After moving, it is very important to collect accurate traffic statistics.
4.5 Do a mini-audit of the site again to understand whether new critical errors have appeared.
4.6 Update the sitemap.xml files in the webmaster panels so that search engines see the new URLs faster.
4.7 Track traffic and positions. For some time, traffic may drop by 10-20%, but if everything is done correctly, traffic will return within a month.
Conclusions
The work of an SEO specialist when moving to a new CMS consists of four important stages:
- preparation of the necessary technical tasks for the test site;
- test site analysis and implementation control;
- preparation for site transfer;
- inspection and control after moving.
However, each site has its own characteristics, so a standard checklist is often not enough. This is just a guide. During the preparation of the technical task, it is necessary to take into account the specifics of the project and be guided by common sense.
We hope you understand how much work you need to put in to prepare and successfully migrate your site to a new CMS. However, with this approach, the loss of traffic and the decline of positions will be minimal, besides, you will have everything under control.
I wish you a successful move!
If after reading the article you still have difficulties with transferring the site to a new CMS, contact our SEO specialists .
