Your website looks polished. It works perfectly when you open it. The forms submit, the animations glide, and every button appears to be in the right place.

But Google still cannot find it.

Or perhaps Google has indexed only your homepage, ignored your service pages, chosen a strange page title, or displayed almost nothing when someone shares your link on LinkedIn.

The problem may be basic SEO. It may be weak content. It may be a new domain with no authority.

But when a website has been built with an AI website or app builder, there is another possibility: the content you see in your browser may not be the same content a search engine or social-preview crawler receives.

That does not mean every AI-built website is invisible to Google. Major platforms including Lovable, Bolt and Base44 have introduced substantial SEO improvements. However, rendering now varies according to:

• The platform you use
• When the project was created
• Whether you use a custom domain
• Whether prerendering has been enabled
• Whether the page is public
• How your routes and metadata have been configured
• Whether important content appears before JavaScript runs

The right question is no longer simply:

Is this platform good for SEO?

It is:

What does Google receive when it requests this particular page?

This guide explains why websites fail to appear in search, how Google processes JavaScript websites, what has changed across leading AI builders, and how to test whether your own website is genuinely ready to be indexed.

What you’ll learn

• Seven common reasons websites do not appear on Google
• How Google crawls, renders and indexes JavaScript websites
• The difference between client-side rendering, server-side rendering and prerendering
• How SEO currently works on Lovable, Bolt and Base44
• Why social link previews can fail even when Google can index the page
• How to see what Google actually receives
• Which SEO problems your platform can solve, and which ones still require content and authority

1. Your website has not been discovered or indexed yet

Publishing a website does not automatically place it in Google’s search results.

Google first needs to discover the URL. It may find your website through:

• A link from another website
• An XML sitemap
• An internal link from a page it already knows
• A manual indexing request in Google Search Console

Discovery is only the beginning. Google must then crawl the page, process it and decide whether it belongs in its index.

A submitted sitemap can help Google find your URLs, but it does not guarantee that every page will be indexed. New pages may appear within days, take several weeks, or remain excluded if Google considers them duplicated, inaccessible, low value or insufficiently connected to the rest of the web.

How to fix it

Set up Google Search Console and verify your domain.

Then:

1. Submit your XML sitemap.
2. Inspect your homepage and key service pages.
3. Check whether Google reports the page as indexed.
4. Request indexing for your most important pages.
5. Make sure every important page is linked from another crawlable page.

Do not submit hundreds of low-value URLs and expect the sitemap to act as an indexing command. A sitemap is a map, not a court summons.

2. Your pages are missing basic SEO signals

Google needs enough information to understand what a page is about, who it is for and how it differs from the other pages on your website.

Common problems include:

• Generic titles such as “Home” or “Untitled”
• The same title on every page
• Missing or unclear H1 headings
• Almost no text outside images or interactive components
• Several pages targeting the same topic
• Important information hidden behind tabs, forms or user interactions
• No descriptive internal links
• Missing image alt text
• Incorrect canonical tags
• Pages accidentally marked noindex

Title tags

Every important page should have a unique, descriptive and concise title.

Google does not impose a fixed 60-character title limit. Long titles may be shortened or rewritten in search results depending on their content and the available display width. Focus on clarity rather than squeezing every title through a character-counting keyhole.

A useful title usually includes:

• The main subject of the page
• The product, service or location where relevant
• The company name when it adds context

For example:

Weak:
Home | Aqua Nova

Better:
Plunge Pool Installation in Bordeaux | Aqua Nova

Meta descriptions

A meta description gives Google possible copy to use beneath the page title in search results.

It is not a direct requirement for ranking, and Google may generate a different snippet from the page itself. But a clear description can improve how the result is presented and make people more likely to click.

Headings and body content

A page should normally contain:

• One clear primary heading
• Supporting H2 and H3 headings where useful
• Enough visible text to explain the offer
• Language that matches how customers search
• Internal links to closely related pages

Semantic structure is useful, but a technically perfect heading hierarchy cannot rescue a page that says almost nothing.

3. Your content does not match what people search for

A company can describe its services accurately and still use completely different language from its potential customers.

You may call your service:

Bespoke aquatic environment design

Your customers may search for:

How much does a plunge pool cost?

Google needs enough overlap between the searcher’s problem and the language on your page to understand that the two belong together.

How to fix it

Research the questions and phrases customers use before contacting you.

Useful sources include:

• Previous sales calls
• Customer emails
• Search Console query data
• Google autocomplete
• Related searches
• Competitor pages
• Support tickets
• Industry forums
• Sales-team notes

Then create a clear page for each meaningful search intent.

A service page should not merely announce that the service exists. It should answer the questions that determine whether someone will buy it:

• What is included?
• Who is it for?
• How much does it cost?
• How long does it take?
• What affects the price?
• What happens next?
• Why should the customer trust you?

4. Your website has little authority

Links from other websites help search engines discover pages and understand whether a source is established and trusted.

A new domain with no mentions, links, reviews or brand history may struggle against businesses that have been publishing useful material for years.

That does not mean every page requires hundreds of backlinks. Highly specific, local or low-competition pages can rank with very few external links.

But in a competitive market, good content alone may not be enough.

How to build authority

Start with legitimate, relevant sources:

• Google Business Profile
• Reputable industry directories
• Professional associations
• Suppliers and commercial partners
• Local business organisations
• Customer case studies
• Original research
• Useful calculators and tools
• Expert commentary
• Podcasts and industry publications

Avoid buying large packages of low-quality links. Fifty links from abandoned websites are not a substitute for one real mention from a source your customers already trust.

5. Your website is slow or unstable

Speed is part of the user experience and can contribute to search performance, but there is no universal rule that a page becomes unrankable after exactly three seconds.

Google’s current page-experience guidance includes Core Web Vitals such as:

• Largest Contentful Paint: how quickly the main content becomes visible
• Interaction to Next Paint: how responsive the page feels after an interaction
• Cumulative Layout Shift: how much the layout unexpectedly moves

A technically fast site can still rank poorly if its content is weak. A slower page can still rank if it is substantially more relevant and useful than the alternatives.

However, poor performance can reduce conversions, frustrate mobile users and make complex JavaScript applications harder for crawlers to process reliably.

Common causes

• Oversized images
• Autoplaying video
• Excessive third-party scripts
• Large JavaScript bundles
• Unnecessary animations
• Slow API requests
• Render-blocking resources
• Too many analytics and marketing tools
• AI-generated code that has not been reviewed or optimised

Run important pages through PageSpeed Insights, but do not chase a perfect score while ignoring the actual customer experience.

6. Google’s mobile crawler sees a weaker version of your website

Google primarily uses a smartphone crawler to understand and index websites.

That means your mobile experience is not a decorative miniature of the desktop site. It is the version Google primarily evaluates.

Problems arise when the mobile version:

• Removes important copy
• Hides links that exist on desktop
• Loads different or incomplete content
• Uses buttons that cannot be tapped
• Pushes the main content far below intrusive elements
• Breaks the layout
• Prevents menus from being crawled
• Requires interactions before important content appears

Test the site on a real phone, not only inside a resized browser window.

Check that the mobile version contains the same meaningful information, links and structured content as the desktop version.

7. Google must render your JavaScript before it can see the content

This is the technical issue most likely to affect websites built as JavaScript applications.

Many AI builders create React or similar applications. In a purely client-side-rendered application, the server may initially return little more than:

• A basic HTML document
• An empty root element
• Links to JavaScript files
• A generic page title

The browser downloads the JavaScript, runs the application and then constructs the visible page.

A human visitor may see the finished website almost immediately.

A crawler that does not run JavaScript may see very little.

Can Google index JavaScript websites?

Yes.

Google processes JavaScript websites in three broad stages:

1. Crawling
2. Rendering
3. Indexing

Google first fetches the initial HTML response. Pages eligible for processing are then queued for rendering. Google uses an evergreen Chromium renderer to execute JavaScript and processes the rendered HTML for indexing.

This means it is inaccurate to say that Google can never see client-side-rendered content.

But relying entirely on browser-side JavaScript introduces more moving parts:

• Rendering may happen after the initial crawl.
• JavaScript resources can fail or be blocked.
• API content may not load correctly.
• Authentication or cookies may prevent access.
• Internal links may not be discoverable in the initial HTML.
• Some crawlers do not execute JavaScript at all.
• Social-preview bots may only inspect metadata in the first response.

The issue is therefore not:

Google cannot index JavaScript.

It is:

Does your website make important content immediately and reliably available, or does every crawler need to assemble the page successfully first?

CSR, SSR and prerendering: what is the difference?

Client-side rendering

With client-side rendering, the browser receives a relatively thin HTML shell and builds most of the page after downloading and executing JavaScript.

Advantages

• Rich application-like interactions
• Smooth transitions between views
• Suitable for dashboards and logged-in tools
• Less server-side rendering work after the application loads

SEO risks

• Important content may be absent from the initial response.
• Some bots may not render the page.
• Rendering failures can leave content unindexed.
• Incorrect routing can create soft 404s.
• Metadata may be generic across several routes.

Server-side rendering

With server-side rendering, the server generates meaningful HTML for the requested URL before sending it to the visitor or crawler.

Advantages

• Important content appears in the initial response.
• Crawlers can process the page without first executing the complete application.
• Route-specific metadata can be delivered immediately.
• Social previews are easier to control.
• Initial content can appear more quickly.

SSR does not automatically create good SEO. A server-rendered page can still have thin copy, poor titles, duplicate content or no backlinks.

It simply gives search engines a more dependable version of the page to work with.

Static generation

Static generation creates HTML files in advance, usually when the website is built or published.

This can provide excellent speed and crawlability for pages that do not need to change every second.

The main risk is freshness. If the build process is not triggered when information changes, the static page can become stale.

Prerendering

Prerendering creates an HTML version of a JavaScript page in advance.

Some platforms serve that rendered version to crawlers while humans continue to use the client-side application.

This can make an older single-page application crawlable without rebuilding it as a completely server-rendered application.

However, the prerendered version must remain consistent with what users see.

Hybrid rendering

Modern frameworks frequently mix approaches.

A website might use:

• Server rendering for the homepage
• Static generation for articles
• Client rendering for a calculator
• Private client-side routes for a customer dashboard

This is why platform-wide labels are increasingly unreliable.

The correct unit of inspection is the individual deployed route.

Does Lovable support SEO now?

Yes. The answer changed substantially in May 2026.

New Lovable projects created from 13 May 2026 use TanStack Start with server-side rendering by default, except for certain Enterprise arrangements.

Older Lovable projects built with React and Vite continue to function as single-page applications for human visitors, but Lovable now prerenders public deployed URLs for search engines, social-preview bots and AI crawlers.

According to Lovable’s current documentation:

• New projects can return fully rendered HTML on the first request.
• Older hosted projects receive automatic crawler-focused prerendering.
• External prerendering services are not required for Lovable-hosted deployments.
• Existing React and Vite projects cannot currently be converted directly to the newer TanStack Start stack.
• Metadata, content quality, semantic HTML, internal links, performance, structured data and backlinks still need attention.

What this means for older Lovable SEO tests

A Lovable site tested before these changes may genuinely have returned little more than a brand name and application shell.

That historical result remains useful as a record of the tested deployment.

It should not be presented as evidence that all current Lovable websites return empty HTML.

When reviewing a Lovable site now, record:

• The date the project was created
• Whether Lovable hosts the deployment
• Whether the URL is public
• Whether the project uses the newer or older stack
• What the specific route returns to normal and crawler requests
• Whether its route-specific metadata is correct

Lovable has solved much of the platform-level rendering problem. It has not solved keyword research, positioning, page strategy or authority for the person building the site.

Is Bolt SEO-friendly?

Bolt now provides a feature called SEO Boost.

SEO Boost generates an HTML version of each project page in advance so search engines can receive the completed page without first assembling it from browser-side JavaScript.

However, two conditions are important:

• SEO Boost is disabled by default.
• It is only available for projects with a connected custom domain.

Therefore, it is inaccurate to say that Bolt can never provide crawlable HTML.

It is equally risky to assume that every Bolt deployment is automatically prerendered.

What Bolt users should check

• Is the website connected to a custom domain?
• Has SEO Boost actually been enabled?
• Are all important routes included?
• Does each page return unique metadata?
• Are canonical URLs correct?
• Is the prerendered content current after updates?
• Do errors return appropriate HTTP status codes?
• Are internal links present as crawlable links?

A feature hidden behind a disabled toggle is not an SEO foundation until someone turns it on.

Is Base44 SEO-friendly?

Base44 has also added a much broader SEO and generative-search system.

For applications published on custom domains, Base44 currently documents support for:

• Per-page titles and descriptions
• Semantic headings and HTML
• Canonical tags
• XML sitemaps
• robots.txt
• clean routes
• crawlable internal links
• Open Graph and social-sharing metadata
• llms.txt
• SEO and GEO scanning
• Google Search Console connections
• Per-page indexing controls
• Structured-data injection
• Automatically generated breadcrumbs

These are significant improvements.

But Base44’s documentation also says its apps are client-side rendered by default. It notes that many AI crawlers do not execute the application JavaScript or see the complete content directly.

This creates an important distinction:

Strong SEO files and metadata do not automatically prove that the full body content is present in the initial HTML.

A page may have:

• A correct title
• A sitemap entry
• A canonical tag
• A social image
• A robots.txt rule

…and still require JavaScript before its detailed pricing, FAQs, testimonials or service copy becomes visible.

What Base44 users should verify

Check whether important body content is available in:

• The initial HTML response
• Google’s rendered HTML
• Social previews
• Important subpages
• Routes visited directly rather than through in-app navigation

Base44’s SEO tooling is now much stronger than a simple app shell with no metadata. But full-page crawlability should still be tested on the deployed application rather than inferred from the existence of an SEO dashboard.

What about Wix?

Wix uses server-side rendering for standard editor components, which means ordinary page content can be returned as HTML for crawlers.

However, custom code, asynchronous data and client-only components can still create indexing problems.

A Wix page may therefore become difficult to index when:

• Essential content is inserted only after client-side code runs
• Data requests fail during rendering
• Custom links are not implemented as crawlable anchors
• Important content differs between initial and rendered states
• Pages are blocked or marked noindex

For most standard Wix websites, the first things to examine remain:

• Indexing status
• Thin or duplicated content
• Page titles
• Internal linking
• Search intent
• Backlinks
• Local search signals

What about Squarespace?

Squarespace websites normally provide crawlable public-page content and do not generally behave like an empty single-page application shell.

If a Squarespace website is not appearing in search, investigate:

• Whether the site is publicly accessible
• Whether pages are hidden from search
• Duplicate page titles
• Weak or generic service copy
• Thin location pages
• Incorrect domain settings
• Poor internal linking
• A new domain with few external references
• Several pages competing for the same query

The platform can provide a technical base. It cannot decide which pages the business should create or why Google should prefer them.

What about Shopify?

Traditional Shopify theme storefronts use Liquid to generate HTML for products, collections and other storefront pages.

These pages are usually crawlable without depending entirely on client-side rendering.

Common Shopify SEO problems include:

• Duplicate or near-duplicate product descriptions
• Product variants creating overlapping URLs
• Weak collection-page content
• Theme and application bloat
• Out-of-stock pages handled poorly
• Faceted navigation producing excessive URLs
• Incorrect canonicals
• Missing internal links to important products
• Large image files
• Structured data conflicts between themes and applications

However, Shopify can also be used as the commerce backend for a headless storefront.

In that case, Shopify itself does not determine how the public website is rendered. SEO depends on the frontend framework, routing, hosting and rendering configuration selected by the development team.

Why social previews can still be blank

When you paste a website link into LinkedIn, Slack, Facebook or WhatsApp, the platform fetches information to create a preview card.

It usually looks for Open Graph metadata such as:

• og:title
• og:description
• og:image
• og:url

Many social-preview systems do not run a full browser application before creating the preview.

This means a website can work perfectly for human visitors but produce:

• A blank preview
• The wrong page title
• The platform’s default branding
• No image
• The same preview for every route

However, a blank preview does not automatically prove that the entire website is client-side rendered.

It may simply mean that:

• Open Graph tags are missing
• The image URL is inaccessible
• The image is the wrong size
• Metadata is added only after JavaScript executes
• The preview platform has cached an old version
• Every route uses the homepage metadata

Likewise, a good social preview does not prove that Google can index the page’s complete body content. Metadata and body rendering are related but separate tests.

How to check whether Google can read your website

No single test gives the full answer.

Use several layers.

Test 1: View the page source

Right-click the page and select View Page Source.

Do not use Inspect Element for this test. Inspect Element usually shows the page after JavaScript has modified it.

Search the source for:

• The H1
• A sentence from the main page copy
• Product or service names
• Pricing
• FAQ answers
• Internal links
• The title and meta description
• Canonical tags
• Open Graph tags
• Structured data

If the main content appears, it is present in the initial HTML.

If it does not, Google may need to execute JavaScript before it can see it.

View Source is useful, but it does not show the final rendered HTML that Google may later process.

Test 2: Use Google’s Rich Results Test

Google’s Rich Results Test can show the rendered HTML and identify eligible structured data.

Look beyond whether the page qualifies for a rich result.

Inspect the rendered output and check whether Google can see:

• The main heading
• Body copy
• Prices
• FAQs
• Links
• Product information
• Structured data

Test 3: Use URL Inspection in Search Console

For a verified website, Google Search Console’s URL Inspection tool provides a more useful view of indexing.

Check:

• Whether the URL is indexed
• The selected canonical
• Whether crawling is allowed
• The last crawl date
• Whether the page can be rendered
• The rendered screenshot
• Loaded resources
• Any indexing exclusions

Run a live test after major changes.

Test 4: Fetch the raw HTML

A developer can request the page using tools such as curl and inspect the server response directly.

For example:

curl -L https://example.com/pricing

Then search the returned HTML for visible page copy.

This gives you the initial response, not Google’s later rendered version.

Test 5: Test individual routes

Do not test only the homepage.

Check:

• /services
• /pricing
• /about
• /contact
• Important location pages
• Product pages
• Blog posts
• Calculator landing pages

Single-page applications sometimes render the homepage correctly while nested routes return identical metadata, application shells or soft 404 pages.

Test 6: Check HTTP status codes

A missing route should return an appropriate 404 status.

Some JavaScript applications return 200 OK for every URL and display an error message only after the application loads.

This can create soft 404s and waste crawl resources.

Test 7: Check the sitemap and robots file

Visit:

https://example.com/sitemap.xml
https://example.com/robots.txt

Make sure:

• Important public pages appear in the sitemap
• Private pages do not
• The sitemap contains the preferred canonical URLs
• robots.txt does not block essential pages or JavaScript files
• Staging and preview URLs are not being indexed instead of the real domain

Test 8: Check social previews

Share or debug the URL on several platforms.

Verify that each important route has its own:

• Title
• Description
• Image
• Canonical URL

Remember that preview caches may take time to refresh.

Updated comparison of rendering approaches

Updated comparison of AI builders

Does upgrading to a paid plan fix SEO?

Sometimes it unlocks the feature required to fix part of the problem. Sometimes it does not.

A paid plan may provide:

• A custom domain
• Removal of platform branding
• Editable metadata
• Sitemap generation
• Prerendering
• Additional hosting controls
• Redirect management
• Analytics integrations

But payment alone does not guarantee that these features are enabled or correctly configured.

The useful question is not:

Am I paying enough?

It is:

Which SEO capabilities are active on this exact deployment?

How to fix your website’s Google visibility

The correct fix depends on the failure.

If Google has not discovered the website

• Verify the domain in Search Console.
• Submit the sitemap.
• Add internal links to every important page.
• Earn a few legitimate external mentions.
• Request indexing for priority URLs.

If Google has discovered but not indexed the page

Check for:

• noindex
• Blocked crawling
• Duplicate content
• Incorrect canonicals
• Soft 404s
• Thin pages
• Login requirements
• Rendering errors
• Weak internal linking

If the page is indexed but does not rank

Work on:

• Search intent
• Page depth and usefulness
• Clearer titles and headings
• Topical relevance
• Local signals
• Internal links
• Backlinks and authority
• Demonstrable expertise and trust

Indexing makes a page eligible. It does not make it competitive.

If the initial HTML is empty

Depending on the platform, you may be able to:

• Enable platform prerendering
• Add a custom domain
• Turn on an SEO rendering feature
• Move public marketing pages to an SSR or statically generated framework
• Keep the interactive application client rendered while creating crawlable landing pages
• Add route-specific server-rendered metadata
• Use a supported prerendering service
• Rebuild only the public acquisition pages rather than the complete product

If social previews are blank

Check:

• Open Graph tags
• Twitter card tags
• Image dimensions
• Absolute image URLs
• Route-specific metadata
• Image accessibility
• Cache refresh tools
• Whether metadata exists before JavaScript runs

The question every website builder should answer

AI website builders are changing quickly.

A platform that returned an empty application shell in one month may add prerendering or SSR the next. A builder with an impressive SEO dashboard may still leave critical body content dependent on JavaScript. A technically crawlable website may still have no realistic chance of ranking because its content is vague and nobody links to it.

Do not choose a platform based on a single badge that says “SEO-friendly.”

Ask:

• Does every public page have its own URL?
• What HTML does that URL return?
• Can Google render the complete content?
• Are internal links crawlable?
• Are the canonical tags correct?
• Does the route return the correct status code?
• Can I control indexing?
• Is the sitemap accurate?
• Do social previews work?
• Can I edit titles, descriptions and structured data?
• Will these features still work on my selected hosting and domain setup?

Most importantly:

Can I verify all of this on the live website?

Because SEO is not a setting buried in a builder dashboard.

It is the combined result of what the server returns, what crawlers can process, what the page says, how the website is connected and whether the outside world has any reason to trust it.