Bubble is a powerful no-code platform for building full-stack web apps without writing code. It handles databases, user auth, workflows, and dynamic data all in one place. That’s genuinely impressive. But the platform was built to run apps, not to rank in search, and for a long time its default rendering approach made SEO an uphill battle.
If you’re building a Bubble app and care about organic traffic or AI-driven discovery, this guide covers every setting Bubble exposes, the real limits you’ll hit, and how to decide whether Bubble is the right tool for your use case.
Why Bubble SEO requires more care than most platforms
Bubble apps are largely client-side rendered (CSR) by default. The server sends a thin HTML shell; all meaningful content is populated by JavaScript in the browser. Googlebot can handle JavaScript rendering, but it queues JS rendering separately from HTML parsing, so there can be a crawl delay. Other crawlers, including many AI crawlers used by Perplexity, ChatGPT, and similar systems, often do not execute JavaScript at all.
The result: for a standard Bubble page, a crawler that doesn’t run JS may see almost nothing. No content. No headings. No product descriptions. This is the core single-page application SEO problem applied to no-code. Bubble has added some tools to address this, but the constraints are real.
SEO and metatags settings
Bubble’s built-in SEO controls live in the page settings panel (click the page in the editor, then open the SEO/metatags tab). These work per page.
Page title. Set the <title> tag. Bubble supports dynamic data here, so you can pull in a database field. For app pages showing a single record (a product, a listing, a profile), this is important: something like [Product Name] - Your App Name is far better than a static generic title.
Meta description. Set the content of <meta name="description">. Same dynamic data support. Keep it 150-160 characters; describe the page’s specific content, include the target keyword naturally.
Open Graph image. Bubble lets you set a social sharing image per page. This is the image that appears when someone shares your URL on Twitter, LinkedIn, or Slack. It does not directly affect Google rankings, but it affects click-through from social traffic.
Canonical tag. Bubble automatically adds a canonical tag pointing to the current page URL. If you have the same content accessible via multiple URL patterns (which can happen with dynamic pages), verify that the canonical resolves to the right version.
Here’s what the rendered head looks like on a well-configured Bubble page:
<title>Acme Pro Plan - Bubble App</title>
<meta name="description" content="Everything in Starter plus unlimited projects, priority support, and custom domain. From $49/month." />
<meta property="og:title" content="Acme Pro Plan - Bubble App" />
<meta property="og:description" content="Everything in Starter plus unlimited projects, priority support, and custom domain." />
<meta property="og:image" content="https://yourbubbleapp.io/og-image.png" />
<link rel="canonical" href="https://yourbubbleapp.io/pricing" />The tags are standard. The problem isn’t the tags themselves; it’s whether the page content underneath them is visible to crawlers before JavaScript runs.
URL slugs and friendly URLs
By default, Bubble generates URLs for dynamic pages with an ID parameter, something like /product?id=1234567890. These are not friendly for SEO or users.
Bubble supports friendly URLs (also called SEO-friendly slugs) for dynamic pages. You enable this per page in the page settings. Once enabled, Bubble uses a field from your database record as the URL slug. For a product page, you’d use a “slug” or “URL title” field on your Product data type.
Tips for setting this up well:
- Add a dedicated
slugfield to your data type (text, unique). - Populate it with hyphenated, lowercase, human-readable values when records are created (workflows can auto-generate from the name field).
- The slug should describe the content:
blue-running-shoes-mens-10is better thanrunning-shoes-1. - Make sure slugs are truly unique per record; Bubble won’t enforce this automatically.
Without friendly URLs, your dynamic pages won’t rank well for anything meaningful. Turn this on before you go live.
Sitemap and robots settings
Sitemap. Bubble auto-generates a sitemap at /sitemap.xml. It includes static pages by default. For dynamic pages (pages driven by database records), Bubble has settings to include those records in the sitemap. You’ll need to check the “Include in sitemap” option in the page settings and configure which data type records to expose. For large datasets this matters: if your app has thousands of listings or product pages and they’re not in the sitemap, Google may not discover them promptly.
Robots.txt. Bubble exposes a basic robots.txt at /robots.txt. You can configure which pages are disallowed. App-internal pages (admin panels, user dashboards, settings screens) should be blocked. Public-facing content pages should be allowed.
| Setting | Where to configure | What it does |
|---|---|---|
| Page title | Page settings > SEO/metatags | Sets <title> tag |
| Meta description | Page settings > SEO/metatags | Sets <meta name="description"> |
| OG image | Page settings > SEO/metatags | Social sharing image |
| Friendly URLs | Page settings > SEO | Slug-based URLs for dynamic pages |
| Include in sitemap | Page settings > SEO | Adds dynamic records to sitemap.xml |
| Robots.txt | App settings > SEO | Block/allow crawler access per path |
| Page indexing | Page settings | Noindex toggle per page |
SSR and SEO rendering options
Bubble introduced an SEO/SSR capability for content pages. The implementation uses server-side rendering for specific page types, meaning the initial HTML response contains actual content rather than an empty shell. This matters most for public-facing content pages like blog posts, documentation, and marketing landing pages.
The catch is that Bubble’s SSR is not a full framework-level SSR like Next.js or Astro. It applies selectively and works best for relatively simple, content-driven pages. Complex pages with many dynamic workflows, real-time data, or deeply nested repeating groups may not benefit as much, and rendering times can still be longer than a purpose-built static site generator.
For Bubble apps that are primarily web applications (dashboards, marketplaces, SaaS tools), SSR for the public marketing pages is the right strategy. For Bubble apps being used as content sites or blogs, you’re working against the grain of what the platform does well.
Page speed and Core Web Vitals
Bubble apps can be heavy. The platform loads its own runtime JavaScript, plugin libraries, fonts, and any external resources your app uses. On a slow connection, this adds up. Google uses Core Web Vitals, specifically Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP), as ranking signals.
Common page speed issues in Bubble and how to address them:
Reduce plugins. Every plugin you install adds JavaScript to every page, even if it’s only used on one screen. Audit your plugins and remove anything unused.
Lazy-load images. Large images loaded above the fold directly hurt LCP. Bubble has lazy-loading options; use them for images below the fold.
Limit workflow complexity on page load. Workflows that fire on page load and hit the database add to the time before the page is usable. Where possible, defer non-critical data loads.
Use a custom domain with HTTPS. Bubble’s default .bubbleapps.io domain works, but deploying to a custom domain is better for branding, trust, and some performance optimisations.
Check your Lighthouse score. Run your key public pages through Google’s Lighthouse tool or PageSpeed Insights. Focus on the LCP and CLS scores first; those are the two most common issues on Bubble pages.
Realistically, a heavily featured Bubble app is unlikely to match the Lighthouse scores of a minimal static site. For pages where SEO performance is critical, this is a trade-off worth understanding upfront.
How Bubble affects AI search citation
AI search systems (ChatGPT web browsing, Perplexity, Google AI Overviews) crawl and index pages the same way search engines do, sometimes with less JavaScript execution capability. If your Bubble pages rely on client-side rendering for their main content, those crawlers may not see enough to include your content in an AI-generated answer.
The practical implications for AI SEO:
- Your page title and meta description are often used verbatim in AI-generated summaries. Write them as complete, specific sentences, not keyword lists.
- Structured data (schema.org markup) helps AI systems understand what a page is about. Bubble does not generate schema automatically, but you can add JSON-LD in the page header via a custom HTML element. A basic
WebPageorProductschema is worth adding to key pages. See schema markup for AI SEO for how to structure it. - Content that exists only after user interaction (behind a login, loaded after clicking a tab, populated after a form submission) will generally not be indexed by any crawler.
If being cited in AI answers matters for your growth strategy, the fundamental requirement is the same as for Google: meaningful content in the initial HTML response, proper metadata, and structured markup that signals what the page is about.
When Bubble is (and isn’t) the right call for SEO
Bubble is excellent for complex web apps: internal tools, marketplaces, SaaS products, community platforms. If your primary goal is building a functional app and SEO for a handful of public-facing marketing pages is a secondary concern, Bubble is a reasonable choice. You can handle the SEO basics, and the app functionality you get in return is hard to replicate on a static site.
Where Bubble struggles is content-heavy, SEO-critical sites: blogs, news sites, documentation, long-form guides, or any site where organic search is the primary acquisition channel. In those cases, a server-rendered framework like Next.js or a static site generator like Astro will deliver meaningfully better performance, crawlability, and control. Read more about the trade-offs in the platform SEO overview.
A practical middle ground: build your app in Bubble and host your content-heavy blog or documentation on a subdomain using a faster, crawler-friendly stack. Use internal links between them. Tools like Fokal can publish content directly into static or Next.js repos via a GitHub adapter, which keeps content production fast without forcing everything onto a single platform.
Bubble SEO checklist
- Set a unique, keyword-relevant page title for every public-facing page
- Write a 150-160 character meta description for every public page
- Enable friendly URLs for all dynamic pages; set up slug fields on data types
- Confirm robots.txt blocks app-internal pages (dashboard, settings, admin)
- Enable sitemap inclusion for dynamic pages with public content
- Submit sitemap to Google Search Console
- Enable SEO/SSR for content pages where available
- Add JSON-LD schema markup to key pages via custom HTML header element
- Run public pages through Lighthouse; address LCP and CLS issues
- Audit and remove unused plugins
- Verify the site loads on a custom domain with HTTPS
- Check that content is present in the raw HTML source (View Source, not DevTools), not just after JavaScript runs