Remix SEO

TL;DR — Remix is a React framework that renders your pages on the server by default — so the content is already in the HTML before Google ever loads it. That goes a long way toward solving the biggest JavaScript SEO problem, though it doesn’t guarantee indexing or rankings by itself. You still have to set your titles, descriptions, and canonical tags yourself, using Remix’s per-route meta() function. SSR is the foundation, not the whole house. Note: Remix v2 merged into React Router (now v8) — Remix 3 (beta) is a separate, newer product; this page covers the Remix v2 / React Router route API most sites run today.

What Remix is

Remix routes can render on the server and provide document metadata through route APIs. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Remix: Route meta Server-rendered HTML improves initial content delivery but does not guarantee Search indexing. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: JavaScript SEO basics

Remix is a meta-framework built on React. Plain React builds your whole page in the browser with JavaScript — Google gets a nearly empty HTML file and has to run your code to see anything. Remix flips that: it runs your React components on the server and sends back finished HTML with the text, links, and meta tags already in it. Server rendering is the framework default — a project can also be configured to statically prerender routes or run in SPA mode, so confirm which mode a given site actually uses rather than assuming from the framework name alone.

For SEO, that’s a huge head start on the default SSR path. There’s no waiting for JavaScript, no “render queue,” and crawlers that don’t run JavaScript at all (many AI bots, social preview bots) still get your full content.

One naming note that trips people up, and it’s more layered than it used to be: in late 2024 the Remix team merged Remix v2’s application APIs into React Router v7 — same route exports (meta, loader, headers, links, ErrorBoundary), renamed package. React Router has since moved to v8 (June 2026), with v7 still receiving security updates. Separately, the Remix name now also refers to Remix 3, a newer beta full-stack framework the team describes as “a different direction” from React Router — a distinct product, not just a renamed one. Everything on this page documents the Remix v2 / React Router v7-v8 route API that most production Remix sites run today; it does not cover Remix 3.

How you add SEO tags in Remix

Remix gives each route (each page) special functions you export from the file:

• meta() — sets your <title>, meta description, Open Graph tags, and even structured data. This is the main SEO tool.
• loader() — fetches data on the server (like a blog post from your database) before the HTML is sent. Your meta() can use that data, so titles can be dynamic.
• links() — adds <link> tags like favicons and stylesheets.
• headers() — sets HTTP response headers (caching, robots rules).

Here’s the simplest version of a title and description:

export const meta = () => {
  return [
    { title: "About Us | My Site" },
    { name: "description", content: "Learn about our team and mission." },
  ];
};

That renders straight into the server HTML — exactly where Google wants it.

The one mistake to avoid

The most common Remix SEO bug: child pages quietly lose the meta tags set by parent layouts. Remix only keeps the deepest route’s meta() and throws away the rest unless you tell it not to. If your homepage layout sets a site-wide description and your About page exports its own meta() without merging, the description disappears on that page. The fix is in the Advanced tab.

The simple takeaway

• Remix is a safe SEO choice because it’s server-rendered by default.
• You still have to write your titles, descriptions, and canonicals with meta().
• Watch out for child pages dropping parent meta tags.

Want the real version — loader and real 404s, headers() for X-Robots-Tag, canonical tags two ways, and the React Router v7 migration? Switch to the Advanced tab. For the framework-agnostic background, see JavaScript SEO and the JavaScript frameworks hub.

TL;DR — Remix is SSR-by-default, so content ships in the initial HTML with no render-queue dependency — the architecture removes most JS-SEO risk when SSR is what’s actually deployed, though it doesn’t by itself guarantee indexing, ranking, or Core Web Vitals outcomes. The work is in the per-route exports: meta() (titles, descriptions, OG, JSON-LD, and dynamic canonicals via tagName: "link"), loader() (server data + real HTTP 404s/redirects), headers() (Cache-Control, X-Robots-Tag), and links() (static canonicals, preloads). The signature gotcha: nested routes drop parent meta unless you merge it via the matches argument. Naming, dated: Remix v2’s APIs merged into React Router v7 in 2024; React Router is now on v8 (v7 still security-supported); Remix 3 (beta) is a separate, newer full-stack framework, not simply React Router renamed. This page covers the Remix v2 / React Router v7-v8 route API.

SSR by default — why Remix starts ahead

Remix’s server rendering is a framework capability whose deployment behavior depends on the adapter and route code. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Remix: Route meta Validate the delivered HTML and resources rather than assuming a framework default ensures SEO outcomes. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: JavaScript SEO basics

Scope note: the walkthrough below documents the meta() / loader() / headers() / links() / ErrorBoundary route module API as it exists in Remix v2 and React Router v7-v8 framework mode — what the large majority of production Remix/React Router sites run. Remix 3 (beta) is a separate, ground-up rewrite with different APIs and isn’t covered here; check which one you’re actually on before copying anything below.

Bare React (CRA, Vite + React) ships an empty <div id="root"></div> and builds the page in the browser. Google can render that, but you’ve signed up for the render queue, statelessness, and DOM-parity problems covered in JavaScript SEO. Remix doesn’t have that default: it executes your nested route tree (Root → Layout → Route) on the server and, by default, sends content-complete HTML on every document request. Framework mode can also be configured to statically prerender routes at build time or run as a client-rendered SPA — so for any given deployment, confirm the actual rendering mode (via curl/View Source, below) rather than assuming SSR from the framework name.

Google’s own guidance lines up with this. From the JavaScript SEO basics doc: “Server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript.” That last clause is the whole argument for Remix — Bingbot renders JS slowly and incompletely, and many AI crawlers and social preview bots (Twitterbot, facebookexternalhit) don’t render at all. Remix’s SSR output serves all of them correctly without special handling.

After the initial load, Remix uses client-side routing for subsequent navigations (like every React framework). That’s fine: Google discovers links from the SSR’d HTML and crawls each URL as its own server request — each returning full HTML. It doesn’t rely on watching client-side route transitions. And because Remix’s <Link> renders a real <a href>, links are crawlable by construction — Google “can only discover your links if they are <a> HTML elements with an href attribute.”

The meta() export: titles, descriptions, OG, JSON-LD

Every route can export a meta function returning an array of descriptor objects. Because it can read loader data, metadata is dynamic and set in the initial HTML <head> — no JS-injection delay:

// app/routes/blog.$slug.tsx
import type { MetaFunction } from "@remix-run/node";

export const meta: MetaFunction<typeof loader> = ({ data }) => {
  if (!data) return [{ title: "Post Not Found" }];
  return [
    { title: `${data.post.title} | My Blog` },
    { name: "description", content: data.post.excerpt },
    { property: "og:title", content: data.post.title },
    { property: "og:image", content: data.post.ogImage },
    { property: "og:type", content: "article" },
    {
      "script:ld+json": {
        "@context": "https://schema.org",
        "@type": "Article",
        headline: data.post.title,
        datePublished: data.post.publishedAt,
        author: { "@type": "Person", name: data.post.author },
      },
    },
  ];
};

The { "script:ld+json": {...} } descriptor renders a proper <script type="application/ld+json"> tag in the SSR’d <head> — visible to Google’s parser without executing any JavaScript. Martin Splitt’s preference applies: “We support JSON-LD in dynamically rendered content, but it’s generally better to have it in the initial HTML.” In Remix, the initial HTML is the default place it lands.

Nested routes and meta inheritance — the common trap

This is the Remix SEO mistake. Remix takes the last matching route with a meta export and uses that — parent meta is dropped. A child that exports its own meta() without merging silently loses every tag the root set (site-wide description, root OG tags, etc.):

// ❌ Root's description is now gone on this route
export const meta: MetaFunction = () => {
  return [{ title: "About Us" }];
};

The fix is the matches argument — flatten and spread parent meta:

// ✅ Keep parent meta, append your own
export const meta: MetaFunction = ({ matches }) => {
  const parentMeta = matches.flatMap((match) => match.meta ?? []);
  return [...parentMeta, { title: "About Us" }];
};

// ✅ Keep parent meta but override only the title
export const meta: MetaFunction = ({ matches }) => {
  const parentMeta = matches
    .flatMap((match) => match.meta ?? [])
    .filter((meta) => !("title" in meta));
  return [...parentMeta, { title: "About Us" }];
};

If you set global tags, put truly universal ones (charset, viewport) directly in root.tsx’s JSX where merging never strips them, and reserve meta() for page-level signals you actually want to override per route.

The loader() function: real 404s, real redirects, dynamic meta

Loaders run server-side only — DB queries, API calls, and secrets never reach Googlebot. The SEO payoff is correct HTTP status codes:

// app/routes/products.$id.tsx
import { json, redirect } from "@remix-run/node";
import type { LoaderFunctionArgs } from "@remix-run/node";

export async function loader({ params }: LoaderFunctionArgs) {
  const product = await db.products.findById(params.id);
  if (!product) {
    throw new Response("Product not found", { status: 404 });
    // ✅ real HTTP 404 — not a soft 404
  }
  if (product.movedTo) {
    throw redirect(`/products/${product.movedTo}/`, 301); // ✅ real 301
  }
  return json(product);
}

This is the antidote to the soft-404 problem SPAs create — a 200 OK page that just says “not found.” As John Mueller put it: “If a page returns a 200 but there’s no content — that’s a soft 404. That’s problematic because we don’t know to treat it as a 404. From a crawling standpoint, we’ll just keep trying to crawl it.” Remix’s throw new Response(..., { status: 404 }) propagates a genuine 404, which lines up with Google’s instruction to “use a meaningful status code, like a 404 for a page that could not be found.”

Whatever a loader returns is exposed to the client even if the component doesn’t render it — treat loaders like public API endpoints and don’t return secrets.

This status propagation is what happens on a direct document request (the case a crawler makes). Client-side navigations after hydration are a separate code path that can behave differently, and some hosting adapters rewrite or intercept thrown responses — verify both the direct-request and post-hydration behavior on your actual deployment rather than assuming it from the loader code alone.

The headers() function: Cache-Control and X-Robots-Tag

Per-route HTTP headers — the lever for CDN caching (faster TTFB → better Core Web Vitals) and for robots directives that work even on crawlers that don’t read the HTML body:

import type { HeadersFunction } from "@remix-run/node";

// CDN-friendly caching
export const headers: HeadersFunction = () => ({
  "Cache-Control": "max-age=300, s-maxage=3600, stale-while-revalidate=86400",
});

// HTTP-level noindex — effective for Bingbot and non-rendering crawlers
export const headers: HeadersFunction = () => ({
  "X-Robots-Tag": "noindex, nofollow",
});

X-Robots-Tag: noindex at the header level reaches crawlers that never parse the body. By default only the deepest route’s headers() runs in a nested tree, so the simplest pattern is to define headers on leaf routes only and avoid merge complexity.

A meta-noindex caveat worth knowing regardless of framework, from Martin Splitt: “The noindex tag can cause Google to skip rendering entirely. So if you’re trying to noindex via JavaScript, you may be creating a situation where Google never even runs the JavaScript to see the noindex.” Remix sidesteps this because the directive lands in the SSR’d <head> (or an HTTP header), not in client-only JavaScript.

The links() export and canonical tags — two ways

links() injects <link> elements (favicons, stylesheet preloads, static canonicals). But it has no access to loader data — it’s static per route module:

export const links: LinksFunction = () => [
  { rel: "canonical", href: "https://example.com/canonical-url/" },
];

For dynamic canonicals — paginated, filtered, or parameterized URLs — use meta() with tagName: "link", which does see data, params, and location:

export const meta: MetaFunction<typeof loader> = ({ data }) => [
  {
    tagName: "link",
    rel: "canonical",
    href: `https://example.com/products/${data.product.slug}/`,
  },
];

The rule: static canonical → links(); dynamic canonical → meta() with tagName: "link". This matches Martin Splitt’s advice to set canonicals in HTML rather than JavaScript — “set your canonical in the HTML, not with JavaScript… it’s just more fragile.” Both Remix approaches render into the server HTML. (See the canonical tag deep dive.)

Error boundaries and 404/5xx pages

When a loader, action, or component throws, the route’s ErrorBoundary renders — in place, inside the surviving layout (nav, footer stay). Paired with a thrown 404 Response, you get a real 404 status and a usable page:

import { isRouteErrorResponse, useRouteError } from "@remix-run/react";

export function ErrorBoundary() {
  const error = useRouteError();
  if (isRouteErrorResponse(error) && error.status === 404) {
    return <div><h1>404 — Page Not Found</h1></div>;
  }
  return <div>Something went wrong.</div>;
}

A root-level ErrorBoundary in app/root.tsx catches anything route boundaries don’t. The myth that “throwing a 404 breaks the layout” is false — the boundary renders within the route hierarchy.

Sitemaps and robots.txt as routes

Remix has no built-in sitemap generator; you build them as resource routes. The bracket notation escapes the dot so the URL is literally /sitemap.xml:

// app/routes/sitemap[.xml].tsx
export async function loader() {
  const posts = await db.posts.findMany({ where: { published: true } });
  const body = `<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
${posts.map((p) => `  <url><loc>https://example.com/blog/${p.slug}/</loc><lastmod>${p.updatedAt.toISOString()}</lastmod></url>`).join("\n")}
</urlset>`;
  return new Response(body, {
    headers: { "Content-Type": "application/xml", "Cache-Control": "public, max-age=3600" },
  });
}

robots.txt follows the same app/routes/robots[.txt].tsx pattern, returning text/plain.

Remix, React Router, and the 2026 product split — a dated timeline

This has gotten more layered since the original 2024 merge, so treat it as history plus current state rather than a single fact:

• Dec 2024 — Remix v2 merges into React Router v7. @remix-run/react and @remix-run/node consolidate into react-router; the @remix-run/* packages still work as a bridge. What’s SEO-relevant from this move:
  • routes.ts — a routing config file; routes can be defined programmatically for more flexible URL structures.
  • Static pre-rendering — individual routes can opt into build-time HTML generation (SSG-style), or SPA mode — configuration choices, not automatic.
  • End-to-end type safety — loader return types flow into meta(), reducing bugs in dynamic meta generation.
  • Vite — the default bundler since Remix v2; route-level code splitting keeps client bundles lean (good for TBT/LCP).
  • What didn’t change: the meta()/loader()/headers()/links()/ ErrorBoundary pattern and the <Meta /> / <Links /> / <Scripts /> components in root.tsx. Existing Remix v2 SEO code carries over with minimal changes.
• June 2026 — React Router v8 ships. React Router v7 remains security-supported; Remix v2 and React Router v6 are now end-of-life. The route module SEO API this page documents (meta, loader, headers, links, ErrorBoundary) is the same shape across v7 and v8 — check your installed version’s changelog for any descriptor-level changes before copying code verbatim.
• Also as of 2026 — Remix is no longer just “the old name for React Router.” The Remix team describes React Router as their React meta-framework, and Remix (now in a “Remix 3” beta) as a separate, newer full-stack framework — “one team, two projects.” If you’re auditing or building on @remix-run/* / react-router route exports, this article’s API guidance applies directly. If you’re on Remix 3, verify its documentation independently — the meta/loader/headers/links pattern described here is not confirmed to carry over unchanged.

Bottom line for most sites in production today: “Remix SEO” and “React Router SEO” are still the same route API and the same practical topic. Just don’t assume that also covers Remix 3.

You still don’t need dynamic rendering

Because Remix serves HTML on the server, you never need Rendertron or Prerender.io. Google deprecated dynamic rendering anyway: “Dynamic rendering was a workaround and not a long-term solution… it creates additional complexities and resource requirements.” SSR is the recommended path, and Remix gives it to you by default.

Auditing a Remix site

• Check the initial HTML with curl or View Source — not DevTools Elements (which shows the post-hydration DOM).
• Verify real HTTP status codes on missing pages (404, not 200) and redirects (301/302).
• Test with GSC URL Inspection — Remix’s served HTML should match the rendered view.
• Look for nested-meta merge bugs — confirm child pages still carry the site-wide description and OG tags.
• Validate JSON-LD with the Rich Results Test, and run a crawl (Ahrefs Site Audit, Screaming Frog) to catch blocked assets and depth issues.

None of the above is a guarantee of indexing, rankings, or Core Web Vitals — SSR, correct status codes, and clean metadata remove architecture-level risk; the rest still depends on content quality, the deployment adapter, and how the page performs against everything else in the SERP.

For the base library underneath Remix, see React SEO; for the framework-agnostic rendering rules, see JavaScript SEO and the JavaScript frameworks hub.

AI summary

A condensed take on the Advanced version:

• Remix is SSR-by-default — it renders the nested route tree on the server and, by default, ships content-complete HTML on every document request (framework mode can also be set to static prerender or SPA, so verify the actual deployed mode). No render queue, no empty root <div>, and non-rendering crawlers (Bingbot, AI bots, social bots) get full content — though none of this guarantees indexing or rankings by itself.
• meta() is the primary SEO tool — titles, descriptions, OG, JSON-LD ("script:ld+json"), and dynamic canonicals via tagName: "link". It can read loader data, so metadata is content-specific and in the initial HTML.
• The signature gotcha: nested routes use the deepest route’s meta and drop parent meta unless you merge it with the matches argument.
• loader() runs server-side; throw new Response("", { status: 404 }) gives a real 404 (no soft 404) and throw redirect() gives a real 301/302.
• headers() sets Cache-Control (TTFB/CWV) and X-Robots-Tag at the HTTP level — works even for crawlers that don’t read the body.
• links() vs meta() for canonicals: links() is static (no loader data); meta() with tagName: "link" is dynamic. Static → links(), dynamic → meta().
• ErrorBoundary renders inside the surviving layout and pairs with thrown 404s for correct status + usable page.
• Remix v2’s APIs merged into React Router v7 (Dec 2024) — same SEO APIs, renamed packages (react-router), new routes.ts, optional static pre-rendering, Vite bundling. React Router is now on v8 (June 2026; v7 still security-supported). Separately, Remix 3 (beta) is a newer, distinct full-stack framework — not just React Router under the old name. This article covers the Remix v2 / React Router v7-v8 route API. No dynamic rendering tools needed for that API either way.

Official documentation

Primary-source documentation from Remix / React Router and the search engines.

Remix / React Router

• Remix — meta function — per-route meta tags, descriptors, and matches merging.
• Remix — loader function — server-side data fetching and thrown responses.
• Remix — headers function — per-route HTTP response headers.
• Remix — links function — <link> elements (canonical, preload, favicon).
• Remix — ErrorBoundary — route and root error handling.
• React Router v7 announcement — the Remix v2 → React Router merge (Dec 2024).
• React Router v8 — the current release (June 2026) and the “one team, two projects” note on how Remix 3 now differs from React Router.
• React Router docs — where the Remix v2-lineage route API now lives, currently on v8.

Google

• Understand the JavaScript SEO basics — the three-phase crawl/render/index process, status codes, <a href> links, and SSR guidance.
• Dynamic rendering (deprecated) — why dynamic rendering is a workaround, not a solution.
• In-Depth Guide to How Google Search Works — where rendering sits in crawl → index → serve.

Quotes from the source

On-the-record statements from Google that bear directly on Remix’s SSR-first model. Each search-engine link is a deep link that jumps to the quoted passage.

Google — why SSR helps

• “Server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript.” Jump to quote
• “Google can only discover your links if they are <a> HTML elements with an href attribute.” Jump to quote

Google — status codes (the loader + ErrorBoundary pattern)

• “To tell Googlebot if a page can’t be crawled or indexed, use a meaningful status code, like a 404 for a page that could not be found or a 401 code for pages behind a login.” Jump to quote

Google — dynamic rendering is deprecated

• “Dynamic rendering was a workaround and not a long-term solution for problems with JavaScript-generated content in search engines.” Jump to quote

Remix SEO checklist

A quick pass for any Remix / React Router v7 project:

• Important pages are server-rendered (the default) — confirm content is in View Source / curl, not only the post-hydration DOM.
• Every indexable route sets a <title> and meta description via the meta() export.
• Child routes that export meta() merge parent meta via the matches argument (no dropped site-wide tags).
• Missing resources throw new Response(..., { status: 404 }) in the loader — verify a real 404, not a soft 404 (200 + “not found”).
• Moved URLs throw redirect(target, 301) from the loader — real 301/302.
• Canonical tags are set in HTML: links() for static, meta() with tagName: "link" for dynamic (paginated/filtered/param URLs).
• noindex is set in the SSR’d <head> or via headers() X-Robots-Tag — never client-side only.
• headers() sets sensible Cache-Control for CDN caching / TTFB on leaf routes.
• JSON-LD is added via { "script:ld+json": {...} } in meta() and validated in the Rich Results Test.
• sitemap.xml and robots.txt exist as resource routes (sitemap[.xml].tsx, robots[.txt].tsx) and are submitted in Search Console.
• Internal links use Remix <Link> (renders real <a href>).
• No @remix-run/* → react-router rename surprises if you’re migrating to v7.

The mental models

1. SSR is the floor, not the ceiling. Remix renders on the server by default, which removes the discovery/rendering risk class for free. It does not auto-handle titles, descriptions, canonicals, structured data, cache headers, or 404 status codes — each is an explicit meta(), headers(), links(), or loader decision. SSR is a prerequisite, not a complete SEO solution.

2. The right export for the right signal.

• HTML <head> tags (title, description, OG, JSON-LD, dynamic canonical) → meta()
• Static <link> elements (favicon, preload, static canonical) → links()
• HTTP status codes (404, 301, 302) and server data → loader()
• HTTP response headers (Cache-Control, X-Robots-Tag) → headers()
• Error/404 page bodies → ErrorBoundary

3. meta() beats links() when data matters. links() can’t see loader data; meta() can. So anything that depends on fetched content — a dynamic canonical, a data-driven title — belongs in meta().

4. The nesting default is “deepest wins, parents dropped.” The decision rule: any child that exports meta() must consciously choose to merge parent meta (matches) or it loses it. Put universal tags (charset/viewport) in root.tsx JSX where merging can’t strip them.

5. Real status codes are an SEO feature, not an accident. throw new Response(..., { status: 404 }) and throw redirect() are how Remix avoids the soft-404 / fake-redirect failures of CSR SPAs. Reach for thrown Responses instead of rendering an error message at a 200.

Remix SEO — cheat sheet

Per-route exports → what they control

Canonical tags — pick the right one

Status codes from a loader

throw new Response("Not found", { status: 404 });   // real 404
throw redirect("/new-url/", 301);                    // real 301

Fast facts

• Remix is SSR by default — content in the initial HTML, no render queue (confirm the deployed mode; static prerender/SPA are also configuration options).
• Nested meta: deepest route wins; merge parents via matches or lose them.
• X-Robots-Tag via headers() works for crawlers that don’t render.
• Remix v2’s APIs merged into React Router v7 (Dec 2024), same route API, package renamed to react-router. React Router is now on v8 (v7 still security-supported). Remix 3 (beta) is a separate, newer framework — not covered by this page.
• Resource routes: sitemap[.xml].tsx, robots[.txt].tsx (brackets escape the dot).
• No dynamic rendering tools (Rendertron/Prerender.io) needed — or recommended.

Verify what crawlers actually receive

Remix renders on the server, but always confirm the initial HTML rather than the post-hydration DOM in DevTools.

Check the raw server HTML (content + tags are present before JS runs)

# Title, meta description, canonical — should all be in the raw response
curl -s https://example.com/blog/my-post/ | grep -iE '<title>|name="description"|rel="canonical"'

# Confirm JSON-LD is in the SSR'd head
curl -s https://example.com/blog/my-post/ | grep -i 'application/ld+json'

Confirm real HTTP status codes (no soft 404s, real redirects)

# A missing page must return 404, not 200
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/blog/does-not-exist/

# A moved URL should return 301/302 with a Location header
curl -sI https://example.com/old-url/ | grep -iE 'HTTP/|location'

Check HTTP-level robots / cache headers from headers()

curl -sI https://example.com/private-route/ | grep -iE 'x-robots-tag|cache-control'

A minimal robots.txt resource route

// app/routes/robots[.txt].tsx
export async function loader() {
  return new Response(
    `User-agent: *\nAllow: /\nSitemap: https://example.com/sitemap.xml\n`,
    { headers: { "Content-Type": "text/plain" } }
  );
}

Tools for auditing a Remix site

• curl / View Source — the ground truth for what’s in the initial SSR’d HTML (titles, description, canonical, JSON-LD) before hydration. Don’t trust DevTools Elements alone — it shows the post-JS DOM.
• Google Search Console — URL Inspection — see how Googlebot crawled and rendered a single Remix URL; for SSR pages the served and rendered HTML should match.
• Rich Results Test — validate the JSON-LD you emit via "script:ld+json".
• Ahrefs Site Audit — crawl the whole site for missing/duplicate meta (the nested-meta merge bug surfaces here), broken canonicals, redirect chains, and depth.
• Screaming Frog SEO Spider — a developer-friendly crawl to confirm titles, canonicals, and status codes across routes.
• vite-bundle-visualizer — inspect client bundles (Remix uses Vite) to keep JS lean for Core Web Vitals.
• Bing Webmaster Tools — URL Inspection — verify Bingbot sees the SSR’d content.

Test yourself: Remix SEO

Five quick questions on how Remix handles SEO. Pick an answer for each, then check.

Resources worth your time

My writing

• JavaScript SEO: A Definitive Guide — rendering, DOM parity, the most-restrictive-directive rule, and choosing a rendering mode — the framework-agnostic background for everything Remix does by default.
• The Beginner’s Guide to Technical SEO — where rendering and frameworks fit in the bigger picture.

My speaking

• How Search Works (SlideShare) — my walkthrough of crawling, rendering, indexing, and ranking. (My standing disclaimer applies: “This is my understanding of systems… not going to be 100% complete or accurate.”)

From around the industry

• Remix docs — meta function — primary source for per-route metadata and matches merging.
• Remix docs — loader and headers — server data, thrown responses, and HTTP headers.
• React Router v7 announcement / React Router v8 / React Router docs — the Remix v2 merge, the current v8 release, and where the route API now lives (Remix 3 is a separate, newer product).
• Understand the JavaScript SEO basics (Google) — the rules Remix’s output is judged by: status codes, <a href> links, SSR guidance.
• Dynamic rendering (deprecated) (Google) — why Remix sites never need Rendertron/Prerender.io.
• web.dev — Rendering on the Web — the Chrome team’s CSR/SSR/SSG/hydration explainer; the conceptual backbone for Remix’s server-first model.
• r/TechSEO — the community for framework rendering/indexing debugging.

Remix SEO

Remix SEO is the set of framework-native practices for making Remix v2 / React Router (v7-v8) sites crawlable and indexable. These frameworks are server-rendered by default, so content ships in the HTML — and per-route meta(), loader(), headers(), and links() exports control every HTML and HTTP signal that matters. Remix 3 (beta) is now a separate, newer full-stack framework, not simply a renamed React Router.

Related: JavaScript SEO

Remix SEO

Remix SEO refers to the practices and framework-native APIs used to make sites built with Remix v2 — whose application APIs merged into React Router v7 in late 2024 — crawlable, indexable, and rankable. This lineage is server-rendered by default: it ships content-complete HTML on document requests, so there’s no rendering-queue delay, no empty <div id="root">, and none of the soft-404 and metadata-injection problems that plague client-side React apps. Framework mode can also be configured for static prerendering or SPA output, so confirm the deployed mode rather than assuming SSR from the name alone.

The work happens through per-route exports. The meta() function sets titles, descriptions, Open Graph tags, canonicals, and JSON-LD into the server HTML — and it can read loader data, so metadata is dynamic and content-specific. The loader() function fetches data server-side and can throw new Response("", { status: 404 }) to send a real HTTP 404 instead of a soft one. The headers() function sets HTTP-level signals like X-Robots-Tag and Cache-Control. The links() export injects <link> elements (favicons, preloads, static canonicals).

The biggest gotcha is nested-route meta inheritance: this route API uses the deepest route’s meta export and drops parent metadata unless you explicitly merge it via the matches argument. A child route that exports meta() without merging silently loses every tag the root set.

As of late 2024, Remix v2’s application APIs merged into React Router v7 — the package is now react-router and routes can be configured via routes.ts. The SEO APIs (meta, loader, headers, links, ErrorBoundary) carried over unchanged, so “Remix v2 SEO” and “React Router v7 SEO” describe the same route API. React Router has since shipped v8 (June 2026; v7 remains security-supported). Separately, as of 2026 the Remix name also refers to Remix 3, a newer beta full-stack framework the team describes as a distinct direction from React Router — not simply Remix under React Router’s name. Don’t assume Remix 3 uses this same route API.

Related: JavaScript SEO

Changelog