Before a React/Vite route goes public

Choose how each public document is produced

Vite’s default build starts from the project’s index.html. A client router can recognize more paths without producing a separate HTML document for each one. Vite also supports multiple HTML entry points; its SSR guide describes prerendering when routes and data are known ahead of time. Those are different delivery choices. Vite build guide · Vite SSR guide.

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/…

Give the route a release contract

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.

Inspect the response before opening the browser

Request the exact destination with GET and retain the body. A headers-only check cannot show whether the response contains the article or a shared application shell. First record the initial status and any redirect. If it redirects, inspect the destination separately and retain both observations.

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'

Keep one page identity through hydration

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. A separate collection of hand-maintained strings can drift even when each component looks reasonable. Include the fully qualified canonical in the release record, along with any intentional aliases and their redirect destinations.

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.

Make discovery work without a click handler

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.

Check assets and browser behavior on the real host

Vite rewrites asset references for the configured base path. Its preview command serves the built output locally and is not a production server. The deployment platform still owns routing and response behavior. Build paths · Static deployment.

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.

Close the release, then measure discovery

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 monitor the intended URL in Search Console. Separate fetchability, indexing, impressions and clicks: each answers a later question. A ranking change after a release can have several causes. Keep the release time and a dated baseline, allow for reporting lag, and avoid treating one day’s movement as an experiment.

The useful completion claim is modest and testable: this deployment serves the intended public document at this URL, with the expected status, identity and links. Search visibility starts from that delivery contract. It still has to be earned and observed.

The raw HTML and rendered DOM method develops the evidence trail behind this release procedure.