April 29, 2019 at 09:5410 non-standard ways to hurt SEO when changing CMS (+1 bonus)
In this article, I’ll talk about the problems that arise when a site changes the engine, but there is no SEO expert control. The material will be useful to those who independently promote their site, and for colleagues may be an extra reason to refresh knowledge in their heads (or may add something new in the comments).
Problems with the search traffic when changing the CMS is a very typical situation: even without particularly blunders, the search engine needs some time to accept all the changes and evaluate them. But there are also omissions that are easy to make and very difficult to identify later.
Just in case, I’ll separately note that the first thing you need to take care of is a test server that is closed from indexing. On it you will deploy the site and rebuild it until the release. Work "gain" is strictly not recommended.
The content of the pages - a thing for the search engine is very important. When transferring content, formatting elements are very often lost or otherwise prescribed: headings, bulleted lists, special characters, etc. Be sure to double-check that the headings have not become just “bold”, and plain text has not got the H2 tag where it is not needed.
The latter is especially unpleasant, because visually this may not be displayed due to the styles, but the code will have a heading in a completely unexpected place.
Check and the correct nesting of the headers. It happens that when changing the design of pages, the logic of the arrangement of text blocks changes. On the old site, the block could logically relate to an older header, and in the new design itself is quite consistent with this level.
With pictures, you also need increased attention. It is important to keep signatures to them, to make sure that all the links on which they are loaded are working. Carefully walk through the secondary sections and pages.
And in general, since they began to carry out an “inspection”, then it's time to update the materials. Somewhere, for sure, low, by today's standards, resolution, somewhere irrelevant photo. It is worth adding exif data optimized for your semantics and protecting images with watermarks.
There were duplicates on the site? Most likely, you cleaned them, and the answer is no. But it’s better to double-check again: not the fact that you did a good job last time, not the fact that since then there haven’t been any new ones, and that the new CMS hasn’t done them again. And she could have, especially if you made a “smart” catalog with a bunch of filters and a detailed rubricator.
Use automated methods because it is simpler, and more often, more reliable than manual verification. Especially if it is an online store in which several thousand positions.
Most likely, your structure has changed, and you set up the 301st redirects. This is correct and logical. Just before registering redirects, check the addresses of new pages in LETTERNESS.
This problem is most acute for online stores: the same Russian names for categories and product groups are differently transliterated by different CMS. When setting up redirects, you see two addresses: site.ru/catalog/venge and site.ru/catalogue/mezhkomnatnie_dvery/venge . And everything seems to be simple: nesting has changed. But in fact, the spelling has also changed.
Yes, it looks like a rather ridiculous mistake, but, believe me, this happens all the time. And since we remember that URLs should be “human-readable”, various “mezhregionalnoe-operatsionnoe-upravleniye” and the like vyviglazny automatic something appear in which it is very easy to skip “-nnoye” instead of “-nnoe”.
Incorrectly configure redirects - waste your time.
And on the site, most likely, there were already redirects before the move. And they forget about them even more often, because these pages are simply not visible in the structure. As a result, 301 redirects are set up only from those pages that are relevant and active at the time of the move, but they forget about the fact that there are others with their weight, links and traffic.
After transferring the redirects, we check them, make sure that each page returns the code 301, and only then we calm down.
If the site has already been promoted, then surely the necessary title, description, keywords were written on it. With the last two, everything is pretty clear, but with the first there are nuances.
As a rule, title is written according to a certain given logic depending on the nesting of the page and its type. For large projects, they are often assembled automatically.
After moving, you should check that the logic of forming the title is still consistent with the logic of the new site structure on pages of all levels. Very often it gets confused, especially if before that the output of the headers was implemented by self-written algorithms. Somewhere there may be manually defined formulations that are also easy to miss and better rechecked.
In sections of articles, news, blogs often hide links that link to more inaccessible materials. When you move these links will be many. Since these are not the most popular sections of the site, they are usually overlooked, and then they don’t understand where so many broken links come from.
It is necessary to check the functionality of links by automated services, for the same reason that I voiced earlier: it is faster and more reliable. At the same time you will find outgoing links to missing pages on other sites, if any.
It is also worth mentioning that in such sections you can often find other problems, for example, the same duplicates. We had cases when whole parallel tree-like catalogs were discovered that were securely hidden on the previous site.
In general, with regard to broken links, moving should be perceived as a good reason to carefully inspect everything, to carry out a “general cleaning”. Usually such small blots accumulate for years and are not corrected, because everyone is busy with more important things. Especially if SEO is not an individual, but a full-time marketer or programmer who does not constantly monitor the state of the site.
A file is often formed in CMS, and this is the first reason to check it for syntax. And if you write it manually, then this is the second reason.
You have changed CMS, and therefore the logic of the internal organization of the site. It is necessary to re-close the service sections from indexing, to verify that what should be open was not accidentally closed.
It is clear that the attribute needs to be transferred. But do not forget to thoroughly verify that it is spelled correctly and is still consistent with your structure, ways of displaying content, etc.
It happens that the wording is simply transferred from the old site to the new one, without delving into what it meant exactly and what called for a search robot. And get the loss of the index of entire sections of the site.
Not that this is a very common problem, but it does occur. When transferring to a new CMS, micro-marking can be lost, but for the large volume of tasks that inevitably arises during the course of work, it is very easy to forget about it: it does not affect the display and functionality of the site in the browser. And you will notice this much later, when links to your pages begin, for example, post on social networks. It’s better to double-check and test everything yourself in advance.
Of course, if the site is transferred under the control of an SEO specialist, then this will not happen. But we also know such cases when, when migrating, micro-markup is perceived as redundant code and is purposely deleted.
Analytics systems, metrics, call tracking services require confirmation of ownership of the site. One way to confirm is to place a special file in the root partition. The method is popular because it does not require editing the page code. So, the conditional marketer or the director himself can connect the service without involving a specialist. But there is a nuance.
When moving, counter codes are rarely forgotten to be transferred to the new version (although it also happens), but confirmation files are lost much more often.
Of course, this will not directly affect the positions, but it will be superfluous work to restore statistics, and you obviously do not need it. And data loss is always bad.
Here, far from everything that will affect the position and display of the site in the search: I described only those points that in our practice are more often forgotten by customers, and we find during the audit.
It’s best to carry out the migration under the supervision of an SEO specialist. This immediately removes most of the questions, because the seoshnik always knows where to look and what to check (this directly affects his salary). He will tell you at the design stage all the pitfalls.
But it often happens that there is no SEO specialist during the migration. Then we take information from open sources (for example, this one), and then from the built-in services of search engines (Yandex.Webmaster, Google Search Console). Most likely, you will receive this data after the site is finished. But it’s better to find out late that you are not indexing one of the directory branches than never to know. Get information from as many sources as possible.
Working with metrics and services is generally a good skill. The sooner you accustom yourself to it, the faster you will realize that everything is interconnected in advancement. Do not forget that moving to a new CMS is not a goal, but a stage. And he must raise the site to a new level of relationship with search engines and with living people.
Problems with the search traffic when changing the CMS is a very typical situation: even without particularly blunders, the search engine needs some time to accept all the changes and evaluate them. But there are also omissions that are easy to make and very difficult to identify later.
Just in case, I’ll separately note that the first thing you need to take care of is a test server that is closed from indexing. On it you will deploy the site and rebuild it until the release. Work "gain" is strictly not recommended.
1. Headers and formatting
The content of the pages - a thing for the search engine is very important. When transferring content, formatting elements are very often lost or otherwise prescribed: headings, bulleted lists, special characters, etc. Be sure to double-check that the headings have not become just “bold”, and plain text has not got the H2 tag where it is not needed.
The latter is especially unpleasant, because visually this may not be displayed due to the styles, but the code will have a heading in a completely unexpected place.
Check and the correct nesting of the headers. It happens that when changing the design of pages, the logic of the arrangement of text blocks changes. On the old site, the block could logically relate to an older header, and in the new design itself is quite consistent with this level.
2. Captions and image links
With pictures, you also need increased attention. It is important to keep signatures to them, to make sure that all the links on which they are loaded are working. Carefully walk through the secondary sections and pages.
And in general, since they began to carry out an “inspection”, then it's time to update the materials. Somewhere, for sure, low, by today's standards, resolution, somewhere irrelevant photo. It is worth adding exif data optimized for your semantics and protecting images with watermarks.
3. Page duplicates
There were duplicates on the site? Most likely, you cleaned them, and the answer is no. But it’s better to double-check again: not the fact that you did a good job last time, not the fact that since then there haven’t been any new ones, and that the new CMS hasn’t done them again. And she could have, especially if you made a “smart” catalog with a bunch of filters and a detailed rubricator.
Use automated methods because it is simpler, and more often, more reliable than manual verification. Especially if it is an online store in which several thousand positions.
4. Transliteration and writing
Most likely, your structure has changed, and you set up the 301st redirects. This is correct and logical. Just before registering redirects, check the addresses of new pages in LETTERNESS.
This problem is most acute for online stores: the same Russian names for categories and product groups are differently transliterated by different CMS. When setting up redirects, you see two addresses: site.ru/catalog/venge and site.ru/catalogue/mezhkomnatnie_dvery/venge . And everything seems to be simple: nesting has changed. But in fact, the spelling has also changed.
Yes, it looks like a rather ridiculous mistake, but, believe me, this happens all the time. And since we remember that URLs should be “human-readable”, various “mezhregionalnoe-operatsionnoe-upravleniye” and the like vyviglazny automatic something appear in which it is very easy to skip “-nnoye” instead of “-nnoe”.
Incorrectly configure redirects - waste your time.
5. Old redirects
And on the site, most likely, there were already redirects before the move. And they forget about them even more often, because these pages are simply not visible in the structure. As a result, 301 redirects are set up only from those pages that are relevant and active at the time of the move, but they forget about the fact that there are others with their weight, links and traffic.
After transferring the redirects, we check them, make sure that each page returns the code 301, and only then we calm down.
6. Logic title
If the site has already been promoted, then surely the necessary title, description, keywords were written on it. With the last two, everything is pretty clear, but with the first there are nuances.
As a rule, title is written according to a certain given logic depending on the nesting of the page and its type. For large projects, they are often assembled automatically.
After moving, you should check that the logic of forming the title is still consistent with the logic of the new site structure on pages of all levels. Very often it gets confused, especially if before that the output of the headers was implemented by self-written algorithms. Somewhere there may be manually defined formulations that are also easy to miss and better rechecked.
7. References from secondary sections
In sections of articles, news, blogs often hide links that link to more inaccessible materials. When you move these links will be many. Since these are not the most popular sections of the site, they are usually overlooked, and then they don’t understand where so many broken links come from.
It is necessary to check the functionality of links by automated services, for the same reason that I voiced earlier: it is faster and more reliable. At the same time you will find outgoing links to missing pages on other sites, if any.
It is also worth mentioning that in such sections you can often find other problems, for example, the same duplicates. We had cases when whole parallel tree-like catalogs were discovered that were securely hidden on the previous site.
In general, with regard to broken links, moving should be perceived as a good reason to carefully inspect everything, to carry out a “general cleaning”. Usually such small blots accumulate for years and are not corrected, because everyone is busy with more important things. Especially if SEO is not an individual, but a full-time marketer or programmer who does not constantly monitor the state of the site.
8. Robots.txt
A file is often formed in CMS, and this is the first reason to check it for syntax. And if you write it manually, then this is the second reason.
You have changed CMS, and therefore the logic of the internal organization of the site. It is necessary to re-close the service sections from indexing, to verify that what should be open was not accidentally closed.
9. rel = "canonical"
It is clear that the attribute needs to be transferred. But do not forget to thoroughly verify that it is spelled correctly and is still consistent with your structure, ways of displaying content, etc.
It happens that the wording is simply transferred from the old site to the new one, without delving into what it meant exactly and what called for a search robot. And get the loss of the index of entire sections of the site.
10. Micro-marking
Not that this is a very common problem, but it does occur. When transferring to a new CMS, micro-marking can be lost, but for the large volume of tasks that inevitably arises during the course of work, it is very easy to forget about it: it does not affect the display and functionality of the site in the browser. And you will notice this much later, when links to your pages begin, for example, post on social networks. It’s better to double-check and test everything yourself in advance.
Of course, if the site is transferred under the control of an SEO specialist, then this will not happen. But we also know such cases when, when migrating, micro-markup is perceived as redundant code and is purposely deleted.
Bonus! Rights Confirmation Files
Analytics systems, metrics, call tracking services require confirmation of ownership of the site. One way to confirm is to place a special file in the root partition. The method is popular because it does not require editing the page code. So, the conditional marketer or the director himself can connect the service without involving a specialist. But there is a nuance.
When moving, counter codes are rarely forgotten to be transferred to the new version (although it also happens), but confirmation files are lost much more often.
Of course, this will not directly affect the positions, but it will be superfluous work to restore statistics, and you obviously do not need it. And data loss is always bad.
General recommendation
Here, far from everything that will affect the position and display of the site in the search: I described only those points that in our practice are more often forgotten by customers, and we find during the audit.
It’s best to carry out the migration under the supervision of an SEO specialist. This immediately removes most of the questions, because the seoshnik always knows where to look and what to check (this directly affects his salary). He will tell you at the design stage all the pitfalls.
But it often happens that there is no SEO specialist during the migration. Then we take information from open sources (for example, this one), and then from the built-in services of search engines (Yandex.Webmaster, Google Search Console). Most likely, you will receive this data after the site is finished. But it’s better to find out late that you are not indexing one of the directory branches than never to know. Get information from as many sources as possible.
Working with metrics and services is generally a good skill. The sooner you accustom yourself to it, the faster you will realize that everything is interconnected in advancement. Do not forget that moving to a new CMS is not a goal, but a stage. And he must raise the site to a new level of relationship with search engines and with living people.