Server Side Rendering and its Relationship with SEO in Airtable

Airtable is a JavaScript heavy application, and like many single page apps it originally rendered most of its marketing and template pages in the browser. The Airtable engineering team documented how that architecture affected organic search and why they adopted server side rendering for pages that needed to rank. This page keeps that source and adds practitioner commentary on how rendering strategy shapes crawlability, indexing, and measurable organic visibility.

Why rendering strategy matters for SEO

A search engine works in two phases. First it crawls the raw HTML returned by your server. Then, if the page depends on JavaScript, it queues the URL for a second rendering phase where a headless browser executes scripts and captures the final DOM. The gap between those two phases is where client side rendering costs you. If the crawler fetches your URL and finds an empty container, it has nothing to index until the render queue catches up, and that queue is neither instant nor guaranteed.

Server side rendering closes the gap. The server runs the framework, produces complete HTML with headings, copy, links, and structured data already present, and returns that in the first response. The crawler reads meaningful content on the initial fetch. JavaScript still loads afterward to make the page interactive, a step called hydration, but indexing no longer depends on it.

How Airtable framed the SSR and SEO problem

The core observation in the Airtable write up is one every JavaScript SEO practitioner meets: a product built for rich interactivity defaults to shipping logic to the browser, and that default quietly undermines discoverability. Template galleries, landing pages, and help content are exactly the surfaces that need to rank, yet they were the surfaces most exposed to render dependent indexing. Moving them to SSR aligned the rendering path with how search engines actually consume pages.

The practical lesson generalizes beyond Airtable. You do not need to server render an entire application. You need to server render the routes that must be found in search, and you can leave authenticated, interactive dashboards as client rendered because they are not meant to be indexed anyway.

Client side versus server side rendering: what a crawler receives

The table below compares the common rendering modes by what the server actually sends in the first response, which is the single factor that determines crawlability.

SSR implementation patterns that protect crawlability

In a Next.js codebase the rendering mode is chosen per route. A page that must rank can export a server data function so the HTML is built before it reaches the browser:

// pages/templates/[slug].js
export async function getServerSideProps(context) {
  const data = await fetchTemplate(context.params.slug);
  return { props: { data } }; // HTML is rendered on the server
}

// For pages that rarely change, prebuild them instead:
export async function getStaticProps() {
  const templates = await fetchAllTemplates();
  return { props: { templates }, revalidate: 3600 };
}

Whichever function you pick, confirm the output rather than trusting it. Run a production build and read the emitted HTML. With Next.js the command next build reports which routes are static, server rendered, or dynamic, and that report is your first crawlability audit.

Three rules keep SSR pages healthy. Put the primary heading and body copy in the server HTML, never inject them with client only effects. Emit canonical tags, meta descriptions, and JSON-LD on the server so they exist before hydration. Keep internal links as real anchor elements with an href, because a link that only fires a click handler is invisible to a crawler.

How to test what Googlebot actually sees

Do not guess whether content is in the first response. Fetch the raw HTML the way a crawler does and look for your real content:

# Fetch the server HTML and search for the main heading
curl -s https://example.com/templates/project-tracker | grep -i "

Then confirm inside Google Search Console. Open the URL Inspection tool, run a live test, and read the rendered HTML and screenshot under the crawled page view. If the heading and body appear in the raw curl output, SSR is doing its job. If they only appear after rendering, you are still exposed to the render queue. The Rich Results Test shows the same rendered source for a quick second opinion, and disabling JavaScript in Chrome DevTools is a fast local sanity check.

What has changed since this case study

Google renders JavaScript far more reliably now than in the early single page app era, and the rendering delay is usually short. That progress does not retire SSR. Rendering remains a queued, resource bounded process, third party scripts still break it, and every extra render step is a chance for content to be missed. Two shifts reinforce the case for server rendering. First, Google retired its dynamic rendering recommendation and now advises real SSR or static generation instead of serving a separate prerendered version to bots. Second, Core Web Vitals reward the fast first paint that server rendered and static pages deliver, so the SEO and performance incentives now point the same direction.

For related failure modes, see our Hulu JavaScript SEO case study and the wider JavaScript SEO case study library for more worked examples of rendering issues and fixes.

Frequently asked questions

Source: https://medium.com/airtable-eng/server-side-rendering-and-its-relationship-with-seo-d9fff26bdde9