Solving SEO with Headless Chrome for your client side framework

Working with client-based web technologies offers the promise of decoupling models and views. It’s a powerful model which yields a clean developer experience allowing the server to deal with data and interactions and the client UI to simply present and facilitate these interactions.

All’s well until the elephant walks in the room. SEO. Some search engines don’t render webpages and instead only use the raw server response to determine what a page ‘looks like’. By far the worst offenders are link previews, which never render a web page to generate a preview.

Before: Generic site-wide link previews

Solutions & trade-offs

Sharing protocols like Open Graph dictate you set metadata using HTML elements which intuitively belongs on the client. Yet, because many crawlers simply fetch a URL and don’t render web pages, our options are limited:

• Server side rendering — use a server side rendering technology to fully render all web pages.
• Inject metadata — use a templating engine to inject the necessary sharing tags and content into your server response.

Both these solutions have two major downsides:

• Tight coupling — your HTML rendering now exists on both on your server and client, diminishing the benefits of client web technologies.
• Performance cost — your web application could take a performance hit having to do more work to serve each web page.

Headless Chrome service

To solve these issues, I built a small Headless Chrome rendering service which is able to take any URL and return its fully rendered results.

This solution negates the downsides of using server side rendering or server-injecting metadata:

• Keep your code — you can happily dynamically set meta tags in your client code.
• Zero performance cost — by filtering your server responses by user agent and only rendering the results for bots, this service won’t affect any of your users.

Sharing: page specific cards displayed after Headless Chrome rendering

Voilà, SEO and sharing have been enabled just like that. Using a Headless Chrome rendering service is a simple, low-cost alternative that doesn’t require re-architecting your web application.

Tweet me @samdotli if this is of interest to you!

References:

• source of the container based Headless Chrome rendering service.
• webcomponents.org source which sends bot traffic through to the rendering service