Before publishing a Vite website, check the production files, the response for each important URL and the page that JavaScript renders. A successful build confirms that Vite produced output; it does not confirm that your content, metadata or hosting rules are ready for search.
These 11 Vite SEO checks connect those layers so you can find the cause of a release problem. They apply to public websites built with Vite, including projects with a framework or server that owns rendering. Private application screens need a different access policy.
The examples follow current Vite documentation, checked against Vite 8.3.7 in November 2026. They are illustrative release checks, not results from a deployed test site. Check your installed version and your framework’s build instructions before adapting them.
1. Verify the production build and environment
Start with the command your deployment actually runs. A plain Vite project commonly uses:
npm run build
npm run preview
Inspect the existing scripts first. A framework may run additional rendering or content-generation steps. Vite’s static deployment guide uses dist as the default output directory and explains that preview serves the built output locally. It is not a production server.
Open the generated files rather than relying on the development server. Confirm the expected HTML, scripts and public files belong to the release you intend to upload.
Also record the build mode. According to Vite’s environment documentation, vite build --mode staging selects staging mode while still defaulting to a production build in the NODE_ENV sense. A production-optimized bundle can therefore contain a staging API address, title or indexing policy. Changing an environment variable after a static build does not rewrite values already bundled into it.
Create a small route sample before continuing:
| Sample | What it exposes |
|---|---|
| Homepage | Shared HTML and deployment origin |
| Two distinct public content pages | Repeated metadata or missing content |
| A nested route | Router and hosting behavior |
| A deliberately nonexistent URL | Error handling |
| A private route, if present | Access and indexing boundaries |
Use this same sample throughout the checks, adding another example for each materially different page template.
2. Check what each public route delivers as HTML
Fetch a representative page directly, without first navigating through the app:
curl --silent --show-error --dump-header route.headers --output route.html https://example.com/app/guides/install/
On Windows PowerShell, use curl.exe if curl resolves to an alias. Read the response status and headers, then open route.html. Look for the page’s actual subject, main text and links, not just an empty mount element.
The right diagnosis depends on who produces the page:
| Rendering approach | Evidence to inspect |
|---|---|
| Client-side rendering | Initial shell plus the completed rendered page |
| Build-time rendering | Generated HTML for every intended public route |
| Server-side rendering | HTML returned by a fresh production request |
An HTML shell is not proof that Google cannot index the page. It means JavaScript must supply the content, so you also need to verify that the relevant rendered output is complete. Content that only appears after a click or a signed-in session deserves particular attention.
Vite’s SSR guide describes an explicit rendering integration; running the ordinary client build does not add that integration automatically. Use the framework’s pipeline when it owns rendering.
Our JavaScript crawlability guide explains the broader rendering checks. A read-only inspection of rendered HTML in Search Console can provide additional evidence; a local source fetch alone cannot establish what Google processed.
3. Match Vite’s base path to the deployed asset URLs
A site that works at the domain root can break when published under a path such as /app/. Check the configured Vite base against the actual hosting location.
For a plain project mounted under https://example.com/app/, the existing configuration might include:
import { defineConfig } from 'vite';
export default defineConfig({
base: '/app/'
});
Merge this setting into your configuration; preserve existing framework plugins and other options. Do not replace a working framework configuration with this minimal example.
Trace a script or image from the generated HTML to its public address. Confirm that the response is the expected file with an appropriate content type. A JavaScript URL returning the app’s HTML is a routing failure, even if it returns 200.
Keep three responsibilities separate: Vite’s asset base, the router’s route base and the host’s mount location. They must agree, but configuring one does not necessarily configure the others. Canonical URLs and social image addresses also need their intended public origin.
Vite documents import.meta.env.BASE_URL for runtime code that constructs asset paths. Check such code separately: an arbitrary hardcoded /assets/ string is not a reliable way to support a nested deployment.
4. Open deep links and missing routes directly
Client-side navigation can hide a broken deployment. The app already has its router and scripts loaded, while a visitor arriving from search begins with a fresh request.
Use the earlier curl capture for a nested route, an old URL that should redirect and a made-up URL. Check the final body as well as the status.
| Illustrative request | Intended behavior |
|---|---|
/app/guides/install/ |
Successful response for the installation page |
| An intentionally retired page | Redirect to its genuine replacement, when one exists |
/app/this-page-does-not-exist/ |
A genuine missing-page response |
| A missing JavaScript file | An error response, not the app shell |
A blanket SPA rewrite may make valid deep links work while also returning 200 for every nonexistent page and asset. Review fallback precedence in your host or server configuration. Preserve real static files and route known missing content appropriately.
Google’s JavaScript SEO guidance explains meaningful status codes and soft 404 handling. If a client-only host cannot return route-specific error statuses, document that limitation and implement the applicable error-page strategy. A visual “not found” message inside a successful generic page is not equivalent to a server 404.
Do not copy another host’s rewrite rule without checking how your platform serves files, prerendered pages and application routes.
5. Review route-specific titles, descriptions and canonicals
Compare two different public pages on a fresh load and after navigating between them. The title, description, main heading and canonical should describe the intended page, not retain the previous route’s identity.
Vite supports environment placeholders in HTML. For example, a homepage template could contain:
<title>%VITE_SITE_NAME% — Product Documentation</title>
If that variable is missing, Vite leaves the placeholder unchanged. Inspect the built HTML for unresolved %VITE_...% values, localhost addresses and preview domains. A shared HTML template also cannot, by itself, generate a different title for every client-side route; route-specific head management or rendering must supply those values.
Use Google’s title guidance to align the title with the visible subject, and its description guidance for a useful page summary. Neither field forces Google to display your wording.
Check canonical tags especially carefully. The homepage canonical should not remain attached to every distinct content page. Genuine duplicate variants may instead point to their preferred equivalent. Follow canonicalization guidance, using the preferred absolute URL and consistent redirect, internal-link and sitemap signals. Avoid conflicting canonicals between the initial HTML and JavaScript-rendered page.
If social sharing matters, inspect the route’s source-level preview tags and actual image destination too. A browser tab title updated by JavaScript does not prove that a separate preview fetch receives route-specific metadata.
6. Separate production indexing from preview and private access
Inspect both the HTML robots tag and the response’s X-Robots-Tag header. A public page can contain an ordinary-looking body while the host still sends:
X-Robots-Tag: noindex
Keep legitimate preview restrictions on previews. Remove an accidental production restriction at its actual source, whether that is a template, rendering integration or hosting rule. Rebuilding the client cannot remove a header supplied independently by the host.
Do not ship a global noindex in the initial HTML and expect JavaScript to reliably reverse it for public routes. Use a deliberate route policy and inspect the final response.
Check the production origin’s /robots.txt as well. If the app lives at /app/, placing a file inside that application’s output does not by itself establish the host-root robots policy. Confirm where the host actually serves it and whether necessary page, script and stylesheet requests are allowed.
Google’s noindex documentation explains that Google must be able to crawl a page to read its noindex rule. A robots.txt block is not a dependable way to remove a known URL from search. Neither directive protects confidential content: private information needs appropriate authentication and authorization.
7. Connect public routes through links and the sitemap
Starting from the homepage or a relevant category page, follow the paths to the pages you want people to find. Important content should not depend on a search form, a button-only click handler or someone already knowing its URL.
Use real link destinations:
<a href="/app/guides/install/">Install the application</a>
Your router can intercept navigation, but the rendered element should still provide a usable href. Google’s link guidance also recommends descriptive anchor text that explains the destination.
Compare those linked public pages with your publishing inventory and sitemap. Include concrete published URLs, not router patterns such as /guides/:slug, and investigate important pages missing from either discovery path.
Vite does not infer all of your application’s public routes from its asset bundle. Our Vite sitemap guide explains the implementation choices and an independent URL-list comparison. Use that deeper workflow instead of installing another generator without establishing who owns the inventory.
Finally, fetch the deployed sitemap address. A successful response containing the SPA’s HTML is not valid sitemap evidence. A correct XML list supports discovery; it does not compensate for broken content, blocked access or incorrect canonical URLs.
8. Verify images in the built pages
Check meaningful images on more than one route, including a nested page. Confirm that the final source URL returns the intended image and that its alternative text describes its role in that page.
Vite’s asset guide distinguishes imported assets, which receive resolved production URLs and can have hashed filenames, from files copied from the public directory. Neither mechanism writes an appropriate image description for you or automatically creates every responsive image size your design needs.
For an illustrative diagram stored as a stable public file, the resulting HTML might be:
<img
src="/app/images/installation-flow.webp"
alt="Installation flow from account setup to first project"
width="960"
height="540"
>
Use the actual image dimensions and deployment path. The description must match the real image; use an empty alternative for a purely decorative image rather than stuffing keywords into it.
Follow Google’s image guidance for discoverable image elements, relevant surrounding content and descriptive alternatives. An essential product diagram presented only as a CSS background has different discovery behavior from a normal image element.
Then inspect the mobile image choice: serving a large desktop original everywhere wastes transfer even when its URL is correct. Keep that delivery issue separate from whether the image meaning and alternative text are accurate.
9. Validate structured data against visible content
If a page includes structured data, inspect the version delivered for that route. A reused component can leave the homepage URL, another article’s author or an unrelated product attached to otherwise distinct pages.
Start with the actual page type and Google’s structured data documentation. Choose an applicable supported feature, then follow that feature’s required properties and content rules. There is no special Vite schema type that makes the bundle search-ready.
For example, an article page should not retain a previous article’s headline or publication date. A product page should not advertise a price or availability state that contradicts its visible content. These are consistency checks, not invitations to manufacture missing business information.
Validate the emitted JSON and, where relevant, the Google-supported feature. Separate three outcomes: valid JSON syntax, compliance with the feature’s requirements and actual appearance in search. Passing an earlier stage does not guarantee the later one.
If your pages do not need structured data, record that decision. Adding markup purely to fill a checklist is less useful than ensuring the page’s real content, links and identity are correct.
10. Measure the built page and its mobile journey
Measure the actual release URL, not just the local development page. Keep the device profile, URL and test conditions consistent when comparing results.
PageSpeed Insights distinguishes controlled lab diagnostics from real-user field data. A newly published page may not have enough field samples; origin-level data, if shown instead, is not a measurement of that specific new page.
Use the result to form a focused investigation:
- If the main content arrives late, inspect its response, image and rendering dependencies.
- If controls feel slow, inspect the interaction and JavaScript work rather than assuming a load score explains it.
- If the layout moves, inspect space reserved for media, fonts and inserted content.
Google’s Core Web Vitals overview separates loading, responsiveness and visual stability through LCP, INP and CLS. A high lab score is not evidence that all three are good for real visitors.
Also complete the mobile task the page exists to support: read the content, follow a link, open navigation or use the relevant form. A lower transfer size is not a successful improvement if the public journey breaks.
Screpy’s PageSpeed monitoring can support repeat observations of selected pages. Compare like-for-like results and keep the available measurement’s scope visible.
11. Recheck the deployed release and cached assets
Repeat the route sample after uploading the release. Check the served HTML and the assets it references, including a lazy-loaded route. Correct files in dist do not prove that the host published or cached those same files.
Vite’s production build guidance describes a release failure in which an older page tries to load a chunk deleted by a newer deployment. Its vite:preloadError event exposes dynamic-import failures; it is a diagnostic clue, not a substitute for a coherent release policy.
Review HTML caching separately from fingerprinted asset caching. Vite recommends Cache-Control: no-cache for HTML in that scenario. As the Cache-Control reference explains, no-cache requires revalidation before reuse; it does not mean “never store.” Your production host or server must apply the policy.
Save a release ledger rather than an unqualified “SEO passed.” This illustrative CSV can be copied and expanded for each sampled URL:
release,url,check,expected,observed,evidence,owner
candidate,https://example.com/app/guides/install/,content,installation text,pending,route.html,frontend
candidate,https://example.com/app/guides/install/,canonical,preferred absolute URL,pending,head capture,frontend
candidate,https://example.com/app/missing-page/,status,missing-page response,pending,missing.headers,hosting
candidate,https://example.com/app/guides/install/,assets,current referenced files load,pending,asset response,hosting
Replace “pending” with what you actually observed, including failures and limitations. Keep the build identifier, observation time and supporting captures together.
A website audit can help organize URL-level findings, but confirm consequential results against the affected response or rendered page. Release readiness means the intended public pages work and their signals agree. It does not establish that Google has indexed them or that they will rank.