If your vibe-coded website is not showing up on Google, first check which problem you actually have. A page may fail when its URL is opened directly, be accessible but absent from Google's index, or be indexed without appearing for the search you tried. Those cases need different fixes. Start with the exact published URL, then inspect that URL in Google Search Console. Do not treat a successful browser preview, a sitemap submission, or a builder's “SEO complete” message as proof that Google indexed the page.
This guide walks through the checks in order: live URL, Search Console status, indexing directives, readable content, and post-fix verification. It uses a fictional multi-page website as an example; no platform-specific failure is assumed. If you need the broader path from launch to search traffic, begin with the vibe coding SEO guide. Here, the job is narrower: find out why one intended public page is missing and fix the confirmed cause.
First confirm the exact page exists on your live domain
Copy the complete public URL you want people to find. Open it in a fresh tab or private window, then refresh it. Do the same with the homepage and another inner page. A page can appear to work when you click through a JavaScript-powered website yet return 404 on a direct request. One SEO practitioner described that exact symptom on a Lovable-built client site; it is a useful test case, not evidence that all Lovable sites behave this way.
For an illustrative site, /salon-reminders/ should return the reminders page, while a made-up path such as /this-page-does-not-exist/ should return a real missing-page status. If every path silently serves the homepage, search engines may see duplicate or soft-404 behavior. If the important page returns 404, Google may not process its content as the page you intended. Google's HTTP status guidance explains why the response code matters.
Do not fix this by adding the broken URL to a sitemap or repeatedly pressing Request indexing. Fix the published route or hosting configuration first. You can give your coding assistant a precise acceptance test:
On the published domain, loading
/salon-reminders/directly returns the intended page and a successful HTTP response. Refreshing it still works. A nonexistent path returns a genuine 404. Show the results for all three requests after deployment.
The exact code change depends on the framework and host. Run a Screpy website audit to spot broken public URLs across the site, then retest the actual page yourself. A crawler result tells you what Screpy received, not what Google has already indexed.
Read the Search Console reason before changing code
Open the correct domain or URL-prefix property in Google Search Console and inspect the exact URL, including its scheme, hostname and trailing path. The URL Inspection tool shows Google's most recently indexed knowledge; Test live URL checks the current page separately. If you changed the website yesterday, those two views may disagree because Google has not revisited it yet.
The Page indexing report gives reasons that guide the next test. Read the label literally; do not turn it into a diagnosis of your builder:
| What Search Console says | What is established | What to check next |
|---|---|---|
| URL is on Google | This URL is indexed and eligible to appear | Look at its queries and impressions. Absence from one manual search is not an indexing failure. |
| Discovered – currently not indexed | Google found the URL but has not crawled it yet | Check that the public URL works, is linked from the site, and is in an accurate sitemap. Wait for evidence of a crawl before diagnosing rendered content. |
| Crawled – currently not indexed | Google fetched it but did not add it to the index | Inspect the last crawled page, selected canonical and page value. Google says resubmitting this URL for crawling is not necessary. |
| Page with redirect | This URL sends visitors elsewhere | Inspect the final destination and make internal links and sitemap entries point to the intended canonical URL. |
| Duplicate, Google chose different canonical | Google selected another URL for a duplicate group | Compare the two URLs, their content, declared canonical and internal links. Do not assume both should be indexed. |
| Excluded by ‘noindex’ or blocked by robots.txt | An indexing or crawling instruction limits access | Determine whether the rule is deliberate. Fix a mistake on public pages; leave private pages protected. |
| Soft 404 | Google interprets the response as effectively missing despite its HTTP response | Check whether the URL contains meaningful unique content or is an error page returning 200. |
These statuses are not a checklist of changes to make all at once. A new website might have several different reasons across its URLs. Work on one representative important page from each reason group, record the result, and then check whether a shared template caused the same symptom elsewhere. A Screpy Search Console connection can help compare Google's query and page performance with site-side crawl findings, but the indexing reason itself comes from Google's report.
Check directives, canonical URLs, and sitemap entries
If the page loads directly, inspect the signals that tell search engines which version should appear. Start with the public URL you want indexed, not a temporary builder preview or an old hostname. A site reachable at both a custom domain and a builder subdomain can create two URL versions of similar content. Choose the preferred public address, then make the page's canonical, internal links and sitemap consistent with that choice. Google's canonical guidance explains that a declared canonical is a signal, not an order Google must follow. Compare User-declared canonical and Google-selected canonical in URL Inspection when Google has indexed a version.
Next, check for an accidental noindex instruction in the HTML or response headers. If it is present on a public page meant for search, correct it on the live deployment and run a new live inspection. Do not remove noindex from login screens, private dashboards or thin temporary previews simply to increase the indexed-page count. Google's noindex documentation also explains an easy trap: if robots.txt prevents crawling, Google may not see the page's noindex instruction. Robots rules control crawling; they are not a reliable substitute for an indexing decision. Screpy's robots.txt guide covers that distinction in more detail.
Finally, open the sitemap shown in your robots.txt or Search Console. Does it list the preferred, public, indexable URLs? Does an inner page appear there only as a preview-domain URL? A sitemap helps Google discover URLs; it does not override a 404, a redirect, noindex, or weak page content. Screpy's sitemap guide explains how to keep that list consistent with canonical pages. Fix the contradictory signal you actually found rather than adding every possible SEO tag at once.
Verify what Google can render
If the URL is accessible but the page still looks wrong in Search Console, inspect the page Google fetched or the result of Test live URL. Look for its actual heading, main text, links and title. Compare that with what a normal visitor sees. An empty-looking initial HTML response is a reason to investigate, but not enough to conclude that Google cannot index a JavaScript website: Google renders JavaScript and uses the rendered HTML. A page can still fail if a resource is blocked, an API request fails, content requires a click or login, or the route returns an error before rendering.
Check the builder's current publishing method for this project. Do not follow an old forum reply that says every project from a platform is client-rendered. For example, Lovable's current documentation describes server-rendered new projects and pre-rendered crawler snapshots for older projects. That statement describes product behavior; it does not replace testing your own URL, domain and deployment.
If the main content really is missing, give the coding assistant a bounded task instead of “fix SEO”:
On the live
/salon-reminders/URL, ensure the public heading, explanation and ordinary links are present in the page Google can render. Keep the visitor and crawler content equivalent. Preserve the correct status code and canonical URL. After deployment, show the direct URL, fetched response and rendered-page result used to verify the change.
The technical implementation may be server rendering, static generation, pre-rendering or a fix to a broken client-side request. Choose it after finding the failure. Screpy's JavaScript SEO guide explains those options without assuming that every AI-built website needs a framework migration.
Retest the fix and watch the right metric
After a change goes live, repeat the test that originally failed. If /salon-reminders/ returned 404, open that exact URL directly and confirm the intended page now loads. If a page had an accidental noindex, inspect the live version and confirm the directive changed. If Google could not read the content, compare the live rendered page with the visitor's page again. A new code commit or an AI assistant's completion message is not the verification result.
Keep a short record so you do not confuse the site's current state with Google's older snapshot:
| Field | Example entry, illustrative |
|---|---|
| URL and expected page | /salon-reminders/ — salon reminder use case |
| Original failure | Direct visit returned 404 |
| Live result after fix | Correct page loads with intended title and links |
| URL Inspection indexed result | Still shows the earlier fetch date |
| Next check | Test live URL; review the indexed status after Google recrawls |
When the live page is ready, you can use Request indexing for an important URL, or submit an accurate sitemap for many URLs. Google's URL Inspection guidance says a request does not guarantee indexing. For Crawled – currently not indexed, Google's report says another crawl request is not necessary; review the indexed evidence and page value instead. A fresh Screpy crawl can verify site-side fixes across multiple pages, while Search Console reports Google's later decision.
If Google indexes the page but it still gets no relevant impressions, stop treating it as a technical indexing incident. The next investigation is the query, the page's usefulness, and competition for that query. That belongs to SEO growth work, not another round of sitemap submissions.