Bubble SEO audit

What the audit checks on Bubble sites

Bubble meta tag configuration and dynamic binding

Bubble's page-level SEO fields (title, description) are configured in the editor and output in the initial HTML. The audit validates what is actually rendered: whether the title tag is populated and unique per page (not generic or using default Bubble page name formatting); whether meta description is present and page-specific (not identical across all instances of a dynamic page type); whether OG title, OG description, and OG image are configured via the SEO / Metatags plugin; and whether canonical tags are set. For dynamic pages (products, profiles, articles powered by a Repeating Group or page data source), dynamic field binding is required — the audit checks whether dynamic pages have unique, meaningful metadata or duplicate identically across all instances (a common Bubble SEO problem where the page title is set to static text rather than bound to a database field).

Bubble URL routing and slug configuration

Bubble's URL structure for dynamic pages is configurable: by default, pages are accessed via /[page-name]/[Bubble unique ID], but custom slug fields can be used to create clean, keyword-descriptive URLs (/product/[product-slug] instead of /product/1234567890). The audit checks: whether dynamic pages use clean slug fields (not numeric unique IDs in the URL path); whether the page title and slug are consistent (slug matches the page's target keyword); whether 404 handling is configured (unconfigured Bubble pages return 200 with a blank page for non-existent slugs — creating soft 404s); and whether the sitemap (if configured via plugin or custom HTML embed) covers all dynamic pages. Bubble's built-in sitemap functionality is limited — most SEO-focused Bubble implementations use a custom sitemap API endpoint or a third-party sitemap service. URL redirects for changed slugs require Bubble's redirect configuration or a CDN-layer redirect.

Structured data on Bubble (JSON-LD via HTML element or plugin)

JSON-LD structured data in Bubble is implemented via: (1) The SEO / Metatags plugin — provides structured data blocks for common schema types (Article, Product, LocalBusiness, FAQPage) with dynamic field binding to Bubble data sources. (2) Custom HTML element — an HTML widget containing a <script type="application/ld+json"> block with JSON-LD; dynamic values are inserted using Bubble's dynamic text syntax within the HTML element. Critical issue: both approaches render structured data client-side (as part of Bubble's JavaScript-rendered DOM) — the JSON-LD is NOT present in the initial HTML response (the raw HTML source). It appears only after Bubble's runtime executes. The Rich Results Test renders JavaScript and will show the structured data; the raw HTML source will not. This means the structured data is parsed by Google's WRS (JavaScript renderer) but not by bots that only parse initial HTML (Perplexity, ClaudeBot, social scrapers). For AI visibility in particular, client-side FAQPage JSON-LD is significantly less reliable than server-rendered.

Sitemap and robots.txt on Bubble

Bubble does not generate a sitemap.xml automatically. Options for Bubble sitemap: (1) Bubble API Connector — create a custom API endpoint that generates sitemap.xml content from Bubble database queries, exposed as a GET endpoint and pointed to from robots.txt. (2) Third-party sitemap service — a service that crawls the Bubble site and generates a sitemap dynamically. (3) Static sitemap for small sites — a manually maintained sitemap.xml uploaded as a static file (via Bubble's file storage or CDN). The robots.txt file in Bubble is configurable under Settings → SEO & Metatags → robots.txt. Default Bubble robots.txt disallows some paths but may not include the sitemap declaration or AI crawler access configuration. The audit checks: whether robots.txt allows GPTBot, ClaudeBot, and other AI crawlers; whether the sitemap is declared in robots.txt; and whether key dynamic pages are discoverable via sitemap or internal links.

Core Web Vitals for Bubble sites

Bubble's client-side rendering architecture creates structural Core Web Vitals challenges. CrUX field data from real users reflects the JavaScript-first rendering experience: LCP is typically high (4–8s+) because meaningful content doesn't appear until Bubble's runtime initialises and API calls resolve. The audit measures LCP, CLS, and INP from real CrUX field data at the p75 threshold — the values that determine Page Experience classification. Unlike Lighthouse lab estimates (which test in controlled conditions), CrUX reflects actual user experience on real devices and network conditions. For Bubble sites, the gap between Lighthouse lab scores and CrUX field data is often significant because Lighthouse tests on a fast connection; real users on mobile 4G or slower connections experience considerably higher LCP values. Key CWV improvement actions for Bubble: minimise API calls on page load, use lazy loading for below-fold content, host images on a CDN, and reduce page complexity (fewer elements, fewer workflows triggered on page load).

AI visibility and GEO score for Bubble sites

AI visibility on Bubble sites faces specific challenges from the CSR architecture: (1) AI crawler access — Bubble's robots.txt must explicitly allow GPTBot, ClaudeBot, PerplexityBot, Google-Extended, and CCBot. Verify there are no blanket Disallow rules blocking AI crawlers. (2) llms.txt — implement as a static file accessible at the root domain path (uploadable via Bubble's file storage with the path configured to /llms.txt) or via a custom API endpoint that returns the llms.txt content with the correct Content-Type. (3) FAQPage JSON-LD — because Bubble renders structured data client-side, FAQPage JSON-LD is not present in the initial HTML that most AI crawlers parse. This significantly reduces the GEO signal value — the FAQPage check specifically requires the schema in the server-rendered HTML. (4) Question-heading ratio — Bubble's text elements can use h2/h3 formatting; audit heading structure for question-format headings. (5) Content chunkability — Bubble's group-based layout can create long undivided content sections without heading breaks; content teams should be guided to use heading text elements between content sections.

How to audit your Bubble site

1. Enter any URL from your Bubble site — homepage, marketing page, product detail page, or landing page.
2. DeepSEOAnalysis checks both the initial HTML response and the rendered DOM to identify structured data present only in the client-side render vs the server-delivered HTML, Core Web Vitals from real CrUX field data, and robots.txt AI crawler access.
3. Review meta tag coverage, structured data detection (with server vs client-side rendering status), Core Web Vitals at p75, and GEO score.
4. Share the audit URL with your Bubble development team — no login required to view results.

Bubble SEO frequently asked questions

How does Bubble handle SEO metadata?

Bubble provides SEO meta tag configuration through two interfaces: (1) Page-level SEO tab in the Bubble editor — each page has "Page title" and "Description" fields configurable in the editor. Static text can be entered directly, or dynamic values (from database fields or URL parameters) can be used for data-driven pages. (2) Bubble SEO / Metatags plugin — a community plugin that extends the built-in SEO capabilities with OG tags, Twitter card tags, canonical tag control, and JSON-LD structured data blocks. For repeating group-driven pages (product detail pages, profile pages), dynamic meta tags require binding the title and description to the page\'s data source field — e.g., "Current page\'s product\'s title" as the page title for a product detail page. Without dynamic binding, all instances of a page type share identical meta tags, causing duplicate title and description across every product or profile page.

Does Bubble support server-side rendering for SEO?

Bubble is primarily a client-side rendered (CSR) platform — the initial HTML response is a minimal shell, and page content is rendered by JavaScript after load. This means that Googlebot must execute JavaScript to see the full page content. Google\'s crawlers do execute JavaScript (via WRS — Web Rendering Service), but there is typically a delay between crawl and rendering. Key SEO implications: (1) Meta tags that depend on JavaScript rendering (dynamically bound title and description) may not appear in the initial HTML — Googlebot sees the rendered version after JavaScript execution, but other bots (Perplexity, ClaudeBot, social scrapers) may only see the initial HTML shell. (2) Content in Repeating Groups, rendered client-side from API calls or Bubble data, is only visible to crawlers that render JavaScript. (3) JSON-LD structured data injected via Bubble\'s HTML element may be client-side rendered — test with Google\'s Rich Results Test (which renders JS) AND by inspecting the raw HTML response (View Source) to determine if it appears in the server-rendered HTML.

Can Bubble sites rank in Google?

Yes — Bubble sites can rank in Google, but they face structural constraints that make SEO more challenging than server-rendered or static site alternatives. The client-side rendering architecture means content visibility depends on JavaScript execution by crawlers. Google does render JavaScript, so content in Repeating Groups and dynamic pages can be indexed — but with potential rendering delays affecting freshness of indexed content. Practical constraints: (1) Bubble\'s hosting infrastructure (bubble.io subdomain or custom domain via Bubble Hosting) does not allow server-side rendering customisation — all pages are CSR by default. (2) URL structure for dynamic pages uses Bubble\'s URL scheme, which can be configured to use slug fields for clean URLs. (3) Structured data (JSON-LD) requires the SEO plugin or custom HTML elements — it is client-side rendered, which makes it unreliable for bots that don\'t execute JavaScript. For SEO-critical sites (content sites, e-commerce), the CSR limitation is significant. For SaaS products and tools where SEO is secondary to functionality, Bubble is viable.

What are Core Web Vitals challenges on Bubble sites?

Bubble sites commonly face Core Web Vitals challenges: (1) LCP — Bubble\'s JavaScript runtime must initialise before page content is rendered, causing high LCP values (frequently 4–8s on initial load without caching). LCP images cannot be preloaded conventionally because the above-fold content is determined by JavaScript rendering. (2) CLS — Bubble\'s responsive layout engine calculates positions client-side; elements shift as JavaScript resolves layout, creating cumulative layout shift. (3) INP — Bubble\'s workflow engine processes all user interactions through a JavaScript event loop; complex pages with many workflows can have slow interaction response times. (4) TTFB — Bubble\'s servers have reasonable TTFB for the initial HTML shell, but the effective TTFB for meaningful content is much higher because JavaScript must execute first. Mitigation: reduce page complexity, minimise the number of Bubble API calls on page load, use Bubble\'s "Page is loaded" optimisation settings, and host images on a CDN (Cloudflare Images, Imgix) rather than Bubble\'s default image hosting.