Someday, one of Germany's most prominent property tech companies made the decision last year to migrate to a new CMS. The migration had two main goals: increased page speed and a future-proof, state-of-the-art website with all necessary features. The migration was initiated to allow content editors to create pages more easily without the assistance of developers.
After looking at several CMS options, Contentful was chosen for its modern technology stack and superior user experience. As a headless CMS Contentful allows us to choose the rendering strategy that we prefer.
To reduce the chance of large-scale problems, we're currently performing the migration in multiple stages or waves. We had an issue with the cookie consent during the first wave. This led to a visibility drop of nearly 22% in just five days. This article will describe the issues we faced during this first wave of migration and how we solved them.
The first test wave is being set up
We chose 10 pages that had high traffic, but low conversion rates for the first wave of tests. We set up an infrastructure to monitor and report on these 10 pages.
Rank-tracking of the most relevant keywords
SEO dashboard (DataStudio, Moz Pro, SEMRush, Search Console, Google Analytics)
Regular crawls
We successfully migrated the first 10 SEO pages to our new CMS in December 2021 after a thorough planning phase and testing phase. While there were many challenges during the testing phase (higher loading times, larger HTML Document Object model, etc.), we successfully migrated the first 10 SEO pages to the new CMS in December 2021. Choose the best SEO Services Company for increasing your SEO performance. We decided to go live because we didn't see any major blockers and we wanted to migrate our first test wave before Christmas.
First performance review
We were so excited to have completed the first step in the migration, that we decided to take a look at how the pages performed the next day.
We were not pleased with what we saw next.
Overnight visibility of tracked keywords on migrated pages decreased from 62.35% down to 53.59% -- we lost 8.76% visibility in one day
We conducted another round of testing to address the steep decline in rankings. We also tested for indexing and coverage issues. If all meta tags were present, we also checked for structured data, internal links, page speed, mobile-friendliness, and meta tags.
Second performance review
Each article had cached data after the migration. The content was also fully indexed and being viewed by Google. We could also exclude many migration risk factors (changes in URLs, content, meta tag, layout, etc.). As there haven't been any modifications, we could exclude them as sources of error.
The visibility of our tracked keywords dropped to 40.60% in the following days. This is a drop of nearly 22% in just five days. This was evident in comparison to the track keywords' competition (here "estimated Traffic"), but visibility looked similar.
It was clear that it was a technical problem, as all other factors that could affect migration and Google updates were excluded. Low Core Web Vitals scores or a more complex, larger Document Object Model (DOM), could all be possible causes. JavaScript, a programming language like JavaScript, can interact with the DOM to modify page structure, style and content.
Follow the cookie crumbs
We needed to quickly identify problems and fix them as soon as possible. This would minimize traffic drops and other negative effects. Our tool showed us the increase in pages with high external links and pages with the largest content. This gave us the first clue as to what technical cause it might be. Pages should not exceed the maximum content limit. Otherwise, they may not be fully indexable. It is crucial that external links have trustworthiness and are relevant to users in order to avoid excessive external linking. It was quite suspicious that external links grew in this manner.
These metrics were unfavourably high in comparison to the number of pages we had migrated. Why?
After examining the links that had been added to the pages migrated, we discovered that Google was indexing and reading the cookie consent for all pages migrated. Our theory was confirmed by a site search. We checked for the cookie consent content.
This caused many problems:
Due to the cookie consent form being indexed, there was a lot of duplicate content on each page.
The content of migrated pages has increased dramatically in size. This can lead to pages that have a lot of content not being fully indexed.
The number of outgoing links from outside has increased dramatically.
Our snippets suddenly displayed dates in the SERPs. This could indicate a news article or blog, whereas most Homeday articles are always green content. The meta description was also cut due to the data being displayed.
Why was this happening? Cookiebot, our service provider, claims that search engine spiders access websites in a way that mimics full consent. They are able to access all content and copy contained in the cookie consent banners. However, the crawler does not index them. Nowadays eCommerce Seo is in demand you can help out by using ecommerce seo services for your eCommerce platform.
Why wasn't this true for the migrated pages as well? We crawled the pages and rendered them with different user agents but couldn't find any trace of the Cookiebot within the source code.
Search for a solution by using Google DOMs
The pages that are migrated contain dynamic data from Contentful and plugins. Sometimes, the plugins are from a partner and contain only JavaScript code. One of these plugins was called the cookie manager partner. It fetches the cookie consent HTML outside of our codebase. We didn't find any trace of the cookie consent HTML code within the HTML source files. However, we did notice a larger DOM and traced it back to Nuxt’s default, more complicated, larger DOM. We use Next, a JavaScript framework.
We used Google Search Console's URL inspection tool to verify that Google was actually reading the content from the cookie consent banner. The DOM of the page that was migrated was compared to the non-migrated page. We finally discovered the cookie consent content within the DOM of the migrated page.
Another thing that caught our attention was the JavaScript files we had on our old pages and the ones on our migrated pages. Two scripts are used to display the cookie consent banner on our website, one to grab consent (uc), and one that imports banner content (cd).
Our old pages had uc.js as the only script. This script is responsible for the consent banner. It is the only script that we require in order to manage user consent. It displays the cookie consent banner and indexes the content. The user can save their decision (if they agree to or disagree with the use of cookies).
Apart from uc.js for migrated pages, there was also a Cd.js file load. The cd.js is required if we are creating a page that displays more information about cookies and indexes the data. Both files were thought to be dependent on each other. This is incorrect. The uc.js file can be run by itself. The cookie banner's content was rendered and indexable by the cd.js files.
We thought that the second file was a pre-requirement to the first. It took us a while to locate it. The solution was to simply delete the loaded cd.js files.
After implementing the solution, a performance review
Our keyword visibility was 41.70% when we deleted the file. This was 21% less than it was before migration.
However, visibility rose to 50.77% the day after we deleted the file. The next day, it was back at 60.11%. Similar results were observed for the estimated traffic. It was a relief!
Conclusion
It is possible that many SEOs have had to deal with such small issues. Although it seems minor, this caused a substantial drop in traffic and visibility during the migration. This is why I recommend migrating in waves and allowing enough time to investigate technical issues before and after the migration. It is important to keep an eye on the performance of the site for several weeks after the migration. These are my top takeaways from the migration wave. We have just completed the second wave of migration at the beginning of May 2022. I can confirm that there have been no major issues. We will have two waves more and hopefully complete the migration by June 2022.
Comments
Post a Comment