For most web applications Search Engine Optimization (SEO) doesn’t really come into play, however my current company wanted to double down on our SEO while not sacrificing engineering efforts. Here’s what I learned from leading a team while we increased our SEO metrics exponentially in less than nine months.

The Problem:

ReactJS is a Single Page App (SPA) javascript based language written by Facebook. For those that don’t know SPA’s are lightning fast, extremely responsive and dynamically render on the fly without the need to refresh. This leads to issues that you have to solve as crawlers are just now able to execute javascript. We were rendering fine using Fetch by Google but as soon as we checked Bing and others we realized that they thought we were serving them a blank white page (or that’s what they thought). When we did the analysis we were almost a dozen pages back for some of our key search terms, yet on Google we were on page 3.

The Solutions:

React Helmet

React Helmet is a dynamic package that lets you update things that should (or would be) in your <head> tags for a normal html/css site. This package was created by the NFL (I actually just realized that when copying the link, who knew!). This will be the start of where you will want to congregate meta description, title and robot tags. An example would be:

Foo.js

import React from 'react'
import Helmet from 'react-helmet'

export default class Foo extends React.Component {
  render() {
    return(
      <React.Fragment>
        <Helmet>
          <meta charSet="utf-8" />
          <title> My Title </title>
          <meta name="description" content="Some description" />
        </Helmet>
        <SomeComponent/>
        <SomeOtherComponent/>
      </React.Fragment>
    )
  }
}

This will render out those elements in the head tag and make it crawl-able (more on this later) by Search Engine Robots. React Helmet is even intelligent enough to conditionally render based on your tree. An example of this:

example.js

<Parent>
    <Helmet>
        <title>My Title</title>
        <meta name="description" content="Helmet application" />
    </Helmet>

    <Child>
        <Helmet>
            <title>Nested Title</title>
            <meta name="description" content="Nested component" />
        </Helmet>
    </Child>
</Parent>

Would output this:

example.html

<head>
    <title>Nested Title</title>
    <meta name="description" content="Nested component">
</head>

Pretty cool, right?

Don’t hide events behind Javascript

This next big issue is that we’ve started created a cool site but that awesome content table you built doesn’t get called until some lifecycle method updates the state to conditionally render that table. Don’t do this. When we get to the concept of pre-render/server side render you’ll save yourself a ton of headache if you just render the table and skip conditional renders for important pieces of content

Implement Prerender.io

Prerender did a ton of work for us. We originally wrote our site in React on Rails then moved to React/S3 a few months back for only a few months (more on this in a second). During that time Prerender was great and we would still use them if we weren’t server side rendering now. They were easy to setup, easy to implement and you can see in their dashboard what’s getting crawled, cached, recached, etc.

Implement GatsbyJS

Our React/S3 site only lasted a few months. We had some bold goals and needed a stout CMS and even more control over our SEO initiatives. From recommendations from investors we looked at Gatsby and implemented it within a month. Gatsby is all about creating the concept of Static Progressive Web Apps. In their docs they explain this concept as:

“Gatsby.js is a static PWA (Progressive Web App) generator. You get code and data splitting out-of-the-box. Gatsby loads only the critical HTML, CSS, data, and JavaScript so your site loads as fast as possible. Once loaded, Gatsby prefetches resources for other pages so clicking around the site feels incredibly fast.”

There are some complications learning Gatsby but really it’s just a fancy wrapper around React with a few cool API hooks you can call during build time (or run time!).

Conclusion:

All in all we moved to the front page for most of our high key search terms within a few weeks after the move. Not only was it important to our trajectory but also was an awesome experience. If you’d be interested in a generic blog on SEO (non-specific to React) drop me a comment and I’ll gauge the interest on that!