React and Vite SEO: each public route needs a direct-load test

The delivery method follows the content

Vite’s build starts from index.html by default. A client router can recognize paths without creating an HTML file for each. Multiple HTML entry points and prerendering through the SSR workflow offer other choices when routes and data are known.

For a finite library, generating route-specific HTML during the build makes the output easy to review. For frequently changing or request-dependent content, server rendering may fit better. An authenticated application can have a different contract from its public documentation. Pick the approach from the content’s requirements, then write down which routes it covers.

Google can render JavaScript, but some other bots cannot. Delivering meaningful initial HTML reduces dependence on a later rendering step; it is not a promise of inclusion in search. Google’s JavaScript SEO guidance.

dist/
  index.html
  writing/index.html
  research/example/index.html
  404.html
  assets/…

The route contract covers six observations

Start with one representative article, one listing, one redirect and one invented missing path. Inspect their built artifacts, then repeat the request against the preview host. Use the same cases on the production host after release. A check that passes locally has only passed locally.

The table below describes expected behavior for a public editorial site. Adapt it deliberately for other products. Keep the requested URL, observation time, deployment identifier and saved response beside each result so a later fix can be compared with the same case.

The first GET can expose a shared application shell

Save the exact destination’s GET body and initial status. Headers can miss an article replaced by a shared application shell. For redirects, capture the destination response too so the move remains visible.

The command below uses an illustrative preview address. Replace it with your own deployment and article path. It does not follow redirects automatically, so a moved route remains visible in the first response. Open the saved HTML as text and find a distinctive sentence from the middle of the article, its heading and one meaningful internal link.

Repeat with a deliberately nonexistent path. Google recommends meaningful status codes, including 404 for missing content. A catch-all rewrite that returns a successful application shell for every invented URL needs a different missing-page strategy. Status guidance.

curl --silent --show-error \
  --dump-header route.headers \
  --output route.html \
  'https://preview.example/p'

Hydration should preserve page identity

Read the document head in the saved response and again after React has hydrated. Google advises unique titles and descriptions and a consistent canonical rather than changing it through JavaScript. Metadata guidance.

I would derive the route path, title, canonical, and sitemap entry from the same registry, including aliases and their redirect destinations in that record so a rename changes the document identity once instead of leaving hand-maintained strings to drift across the build and client router. Keep the fully qualified URL in the release result.

A canonical is a preference signal. Google can choose another URL, and sitemap inclusion is weaker than a redirect or canonical annotation. Verify what you publish first; use Search Console later to inspect Google’s selection. Canonical guidance.

Start a conflicting-metadata investigation with the canonical repair hub and capture checklist; compare response headers as well as React’s rendered head.

Discovery needs anchors with destinations

Link to an article with an anchor that has an href. Google’s guidance distinguishes this from scripted elements without a usable destination. Write link text that helps a reader decide whether to open the page. Crawlable links.

Inspect a contextual link from an existing article as well as the library listing. Open both destinations directly in a fresh tab. A client-side transition can hide a host-routing defect because it never requests the destination document. Keep ordinary chapter fragments for navigation within a document; give separate public articles their own routes.

Sitemaps supplement those reading paths. Record only the intended canonical URLs, and remove a retired URL according to its actual disposition. A useful replacement can justify a redirect; an unrelated destination should not inherit every missing page.

The deployment host decides routing and asset delivery

Vite rewrites assets for its configured base, while preview serves the build locally. The deployment platform still determines production routing and response behavior.

Load a deep article URL directly on the preview deployment. Inspect the heading, fonts, images, code blocks, table and bibliography on a phone-sized viewport and a desktop. Follow an internal link, use browser back, then refresh the destination. Check failed asset requests and hydration errors as part of the same visit.

Compare the visible article with the saved response. If hydration replaces its title, loses prose or sends the visitor elsewhere, stop the release and trace that difference. The raw HTML and rendered DOM method gives that comparison a more precise evidence trail.

Delivery is the release test; discovery follows

After deployment, repeat the small route set against production and attach the observations to the deployed revision. A successful preview does not establish the production host’s redirects, cache state or content. Keep a failed check as a failed observation until a new response supports changing it.

Then read fetchability, indexing, impressions, and clicks as successive observations in Search Console. Keep the release time and dated baseline, allow for reporting lag, and consider other causes before interpreting one day’s movement as an effect.

I would release when production serves the intended document at the intended URL, with correct status, identity, content, and working links. That gives readers a page they can open directly and Search a coherent document to evaluate.