Technical SEO Considerations For Your Gatsby Site Migration

Eleanor Bennett
5 min readJul 7, 2021

By Eleanor Bennett and Michael Richards

When it comes to migrating your website to a new hosting platform, marketing professionals are already aware that you’ll need to perform numerous checks. You need to ensure that your Robots.txt file isn’t blocking Google’s crawlers. Your Lighthouse audits and other SEO reporting tools must show sufficiently high results, and remember to submit an updated sitemap to the leading search engines. There are additional, lesser-known concerns that need to be considered when migrating to Gatsby in particular, as we discuss in this article.

Earlier last year, in September 2020, we migrated our self-hosted website Logit.io to Gatsby. After seeing many SEO wins in the following months, we wanted to share our insights to equip the reader with the necessary knowledge needed to avoid significant SEO losses, as others who migrated in this fashion have reported.

Beware Trailing / Redirects

When we first launched our new site, we noticed that all of our pages were affected by a severe redirect issue that Ahref’s had picked up in their complete site audit.

This redirect anomaly turned out to be a frequently asked question on such sites as StackOverflow and has caught off guard many new users moving to Gatsby. The Gatsby team chose to include a trailing forward-slash (/) at the end of every URL on the site to target the most web servers possible for compatibility reasons.

However, despite the ongoing debate of what URL style looks the most aesthetically pleasing, a lesser-known issue is its negative impact on SEO. Each time Gatsby encounters a URL without the trailing slash on any page, it redirects the user to the same page with the trailing slash included.

For users that didn’t pick up on this, this error signalled to Google that every page was a duplicate of itself and as a result, the SEO of many websites was severely negatively affected.

As well as potentially causing a Google penalty (or at a minimum, impressions free-falling), trailing slashes will also cause Open Graph images & Twitter cards to display inconsistently. Another problem we picked up on is that it caused invalid URL errors in our sitemap (which Google Search Console would highlight).

We fixed this redirect problem on the server-side by running all of our page requests through a Lambda function to prevent the redirects from showing to both the user & Google’s crawler. Depending on your chosen hosting strategy, this might be a simple fix. Many websites hosting providers, such as Netlify, include redirect and rewrite options built into their platform’s UI to solve this.

We had a slight concern that running requests through a Lambda function may slow site speed, but this ended up not being a concern after all, and we were able to escape this issue without suffering any adverse effects to our SEO.

Could Tabbed Content Be Your Migration’s Downfall?

Another vital aspect to keep in mind during your Gatsby migration is how Google views your content. Once you have migrated to a React-based site, such as Gatsby, you may find that pages using stateful components can negatively impact pages that serve the user visually or interactively.

For many of our documentation and integration pages, we had previously used CSS to show and hide content within tabs (e.g., Step 1, Step 2, Step 3). As a result of moving to Gatsby, we refactored this to use React’s `useState` feature to re-render components based on what tab the user selected.

Using the traditional CSS method meant that the content still existed inside the raw HTML document, allowing search engines to access and crawl it. In contrast to this, the React approach avoids fetching content it does not need. Therefore, content is not appended to the HTML document, resulting in faster download speeds at the cost of weakened SEO.

Google saw this change as an attempt to “hide” the content, which was reminiscent of much older Black Hat SEO technique known as cloaking that involved making keywords and copy invisible (e.g., white text on a white background) inside a page for the purposes of appearing in the SERPs for the invisible keywords.

Engaging in this type of activity either unknowingly or on purpose will get your site handed a manual action penalty or, at a minimum, significant traffic loss.

Our informative software documentation started seeing much less traffic and impressions due to this simple change of code.

By working closely with our frontend developers, we resolved this negative SEO impact by displaying all the content to the user once the page had loaded. We changed the tab’s behaviour to work as navigational buttons, allowing the user to skip to the sections of interest on the page.

Suppose your existing site “hides” excess content within tabs to collapse information (a common strategy for many product pages, especially on eCommerce sites that wish to separate terms and conditions away from shipping and other policies from a UX standpoint). In that case, these pages could be a ticking time bomb if you are considering switching to Gatsby.

Some SEO’s state that using a signifier of hidden content, such as including the text “read more”, will prevent you from being seen as hiding your text by Google.

In reality, this isn’t enough as this text can’t be used across all use cases. The change to display all content within the page should be made on a code level by working closely with your development team.

Here are some of the top technical SEO tips we kept in mind across our team when migrating our site which has since recently reached its highest ever monthly sessions within two months of migrating:

  • Fully audit your new site for technical errors using Ahrefs, SEMrush & Search Console, we used all three of these tools to pick up on virtually everything that needed to be fixed as soon as possible.
  • Using both Ahrefs and SEMrush was needed in that there were errors that were different between the two audits from these tools that needed to be cross-compared.
  • I would highly recommend not working in a siloed manner when it comes to testing your new website has successfully migrated.
  • By working alongside developers, dev-ops, UX and Product development I can easily say that our migration was the most seamless migration I have seen in ten years of working across a variety of different websites and sectors.
  • When large changes are deployed to the site you are working on, make sure these notes are recorded against the dates the changes were rolled out on your SEO tools as well as Google Analytics (SEMrush has a nice notes feature which is great at recording this).
  • It is important that large changes are recorded in the event rankings are directly hurt and the code needs to be rolled back for revision.

--

--