On this page
You click a pricing card in your Vite app and the correct page opens. That proves the interaction works in your browser. It does not tell you whether the page contains a usable link to the pricing route.
This distinction matters when your navigation is assembled from cards, buttons and click handlers. A visitor can trigger JavaScript to change the screen even when there is no destination a crawler can extract from the markup.
Vite supports different application architectures, including SSR. The build tool does not determine how your navigation components represent links. Inspect the deployed app rather than diagnosing it from the presence of Vite in the project. Vite's SSR guide
Check the element behind the interaction
Choose one important navigation card and inspect its output in the browser's Elements panel. A component name such as ServiceCard tells you little about the HTML it produces.
This illustrative button performs an action:
<button onClick={() => navigate('/services/maintenance')}>
Website maintenance
</button>For navigation, use a link with a destination. Your router may provide a link component; inspect its resulting HTML rather than assuming that its name guarantees the output.
The relevant shape is:
<a href="/services/maintenance">Website maintenance</a>Google recommends anchors with href values that resolve to actual URLs. JavaScript-generated anchors can also be crawlable when they produce that markup. The problem is not client-side navigation itself; it is navigation without an extractable destination. Google's crawlable-link guidance
Keep buttons for actions such as opening a dialog or applying a filter. Use links when the user is going to another page.
Test the destination independently
Copy the destination and open it in a new session. Then refresh it.
Both checks matter. An app can handle navigation after the homepage has loaded while the host fails to serve a deeper route directly. The repair belongs in routing or hosting, not in the wording of the link.
Also verify the page identity. A successful response containing the homepage is not a working maintenance page. Look for its own heading, relevant body text and intended next action. If different routes return the wrong content, use the existing wrong-page content guide.
Record the source and destination together. “Navigation fails” is vague; “the homepage card opens this route in-app, but a direct request returns a hosting error” gives a developer a reproducible problem.
Compare the link in raw and rendered HTML
Use the raw vs rendered HTML tool on the page containing the link. Search for the destination URL in both versions.
There are several useful outcomes:
| Observation | Next investigation |
|---|---|
| The link exists in both versions | Check its destination and whether the text explains that destination |
| The link appears only after rendering | Establish which crawler and delivery path need access to it |
| The link appears only after an interaction | Check whether the initial navigation exposes a usable destination |
| The link exists, but the destination fails directly | Investigate route handling on the production host |
Google can process JavaScript, but other fetchers and rendering paths can behave differently. Treat an ordinary HTTP request, a rendered browser check and a search-engine inspection as separate observations. Google's JavaScript SEO documentation explains its processing stages.
A user-agent string in a test does not authenticate it as a genuine search-engine crawler. If a host treats verified crawlers differently, investigate using the engine's own inspection and relevant server evidence.
Review the routes that support your buying journey
Start with the links connecting your homepage, service or product pages, comparisons, pricing and useful guides. Those are often the paths a visitor follows before deciding whether the offer fits.
Read the link text without the surrounding design. “See how website maintenance works” carries more context than a card with an unlabeled arrow. It also makes the destination easier for a person to choose.
You do not need every page linked from every other page. Select the next resource that helps with the current question. A comparison can lead to a migration guide; a technical article can lead to a diagnostic tool.
Keep discovery work connected to content work
Suppose a detailed integration guide exists but the product page never links to it. Writing a second integration guide would leave the original navigation problem untouched. Add the useful path, verify the destination and then review whether the explanation itself needs improvement.
PB's AI answer tracking can help surface questions and sources worth investigating, while its page checks address a different question: what the destination delivers. Use the evidence to choose the work, rather than assuming an AI omission is caused by one missing link. Explore AI Visibility
After repairing a shared navigation component, inspect several places that use it. A header menu, a pricing card and an article recommendation may have different implementations despite looking similar.
For rendering choices beyond links, return to the Vite SEO and prerendering guide. This link audit is complete when important destinations are represented clearly, load independently and contain the intended page content.