Bubble SEO Migration Checklist for Public Pages

A Bubble SEO migration needs three concrete outputs: an inventory of public URLs, a tested decision for each URL, and a baseline for checking what changes after launch. Keeping the same address is useful, but the replacement must also serve the right content and remain accessible to search engines.

This checklist is for founders and technical leads rebuilding a public-facing Bubble app. An entirely private dashboard has a smaller search footprint, although its marketing pages and public help content may still need these checks. No migration plan can guarantee unchanged rankings.

Decide which public URLs actually need to change

Start by separating two situations.

If the domain, protocol and page addresses stay the same, the infrastructure is changing underneath existing URLs. A page does not need a migration redirect simply because Bubble no longer serves it. Google provides a separate hosting-change checklist for this situation.

If a domain, subdomain, path or meaningful query parameter changes, record the old address and its intended destination. That is a URL change even when the new page looks identical.

Ask whether a proposed URL change is necessary for launch. Renaming every category, rewriting the content and changing the domain at the same time makes a traffic problem harder to diagnose. Preserve useful addresses where practical and schedule optional improvements separately.

This SEO plan should sit alongside the application’s operational cutover plan. Search visibility is one launch concern; account access, data writes and payments still need their own acceptance tests.

Inventory Bubble pages as visitors encounter them

The page list in the Bubble editor is only the starting point. One dynamic page can represent many public records, each with a different URL.

Combine a crawl of the public site with its sitemap, Search Console page data, analytics landing pages and the underlying published records. Include important image and download URLs, existing redirects and historical addresses still receiving visits.

A sitemap alone may miss pages you need to preserve. Bubble’s sitemap reference describes privacy-based filtering and a limit of 50,000 URLs per Bubble page. Reconcile the sitemap with the public record inventory instead of treating it as a complete export.

For each dynamic template, inspect URLs while signed out. Record the Bubble data type, source record ID, current slug and actual public address. Keep the source-to-target record mapping with the migration data so an old URL can be resolved to the correct replacement record. This is a useful addition to the data-migration acceptance checklist.

Bubble’s page-slug documentation describes a fallback hierarchy: slug, backup field, then unique ID. A backup-field URL can include the record’s unique ID. Privacy rules can also affect what anonymous visitors see in the URL. Record the observed routes rather than assuming every record uses a clean slug.

Do not regenerate every slug from its current display name. A listing may have been renamed without changing its established address. Two records may also need different URLs despite sharing a name.

Capture page-level titles and descriptions, social-preview settings, canonical behavior, robots rules and existing redirect rules. Bubble’s web-app settings expose several of these controls, including page-specific metadata and server-side redirects. Their behavior needs an explicit replacement in the new application.

Give every old URL a deliberate outcome

Use one migration sheet with a row for each known URL, or a documented rule plus tested exceptions for a large predictable set. Include:

• Old public URL and its source record ID
• Whether the record is published, private or intentionally retired
• Target URL and expected HTTP response
• Preferred canonical URL
• Content or file checks required at the destination
• Test result, evidence and an owner for unresolved problems

A useful decision has one of three outcomes: keep the address and serve the equivalent page; permanently redirect to its relevant replacement; or return an appropriate missing-page response when the content is genuinely gone and has no replacement.

An illustrative mapping record

Consider a fictional directory listing, DEMO-42. Its existing public address is /listing/harbor-studio, but the rebuilt directory uses /studios/harbor-studio.

The record would specify a permanent redirect from the old address directly to the new one. The destination must show DEMO-42’s public details, return 200, use the new address as its canonical and appear in the intended directory navigation. The migration owner also checks any known older aliases.

If the listing is private, copying its fields into a public page to preserve an old address is a failed migration. The visibility decision must be respected at the destination and in its sitemap.

The useful evidence is a request to the old URL, the observed redirect, and a content check against the right record. A successful database import does not establish that chain.

Put redirects where old requests will arrive

For a permanent page move, use a server-side 301 or 308 when possible. Google treats these as permanent redirects; a JavaScript navigation after the page loads is a less dependable substitute. See Google’s redirect guidance.

After the domain points to the replacement, requests may no longer reach Bubble. Redirect rules left only in Bubble cannot handle traffic served entirely by the new infrastructure. Recreate the required rules in the application, hosting layer or proxy that will receive those requests.

Test the response before relying on what the browser eventually displays. Check for loops, unnecessary chains and a destination that is itself broken. Include existing aliases, capitalization, trailing slashes and query parameters that identify different content. Do not discard parameters blindly.

Avoid sending unrelated retired pages to the homepage. Use a genuinely relevant replacement or return 404 or 410 when appropriate. Google’s site-move guidance warns that irrelevant redirects may be treated as soft 404s and recommends keeping redirects for at least a year. Useful old links can justify keeping them longer.

Test the page that search engines can receive

Compare a representative page from every public template, including a sparse record, a long record and a missing record. Look beyond visual similarity.

Open each page directly in a fresh signed-out session, not only through client-side navigation. Check that the listing name, description and other important public information are present in the rendered page without a login or an extra user action. Verify crawlable links to related pages and pagination. A page that loads an empty shell successfully can still fail the content check.

Google’s JavaScript SEO documentation explains the separate crawling and rendering stages. Inspect the rendered result and resource loading; do not assume choosing a particular framework makes the page indexable.

For each template, compare the title, description, main heading, important images and any existing structured data. Structured data should still describe the visible page accurately. Keep valuable content intact unless a change is deliberate and recorded.

A missing record should produce a meaningful error response rather than a 200 page saying that nothing was found. Google can treat a successful response containing an error page as a soft 404; its HTTP status-code guidance explains why the status and content both matter.

Align canonical URLs, sitemaps and access rules

A canonical identifies the preferred URL for duplicate or closely similar content. It does not send visitors to a different address. On replacement pages, use the intended production URL and ensure internal links point to that version. Check for staging hostnames accidentally copied into metadata. Google’s canonical guidance recommends keeping these signals consistent.

Build the replacement sitemap from the intended public, indexable records and their canonical URLs. Exclude private records, redirected aliases and deleted pages. Check the generated output after the final content import. Submitting a sitemap helps discovery but does not guarantee indexing, as Google’s sitemap documentation makes clear.

Use authenticated or otherwise access-restricted staging. If you deliberately expose non-sensitive test pages publicly and use noindex, Google must be allowed to crawl them to see that instruction. Blocking the URL in robots.txt can prevent this; see Google’s noindex guidance. At launch, remove temporary crawl and indexing blocks from the pages that should appear in search, while preserving restrictions on private areas.

Treat privacy as an access-control requirement. A robots.txt rule or noindex directive cannot protect customer information from someone who requests the URL. Google explicitly explains the limits of robots.txt. Test private and unpublished records as signed-out visitors, including direct file and API requests.

Save a baseline and agree launch checks

Before release, save Search Console performance for a clearly stated date range. Record the property, search type and any country or device filters. Compare page groups such as listings, categories and articles rather than relying only on the homepage or whole-site average.

Search Console’s Performance report provides clicks, impressions, CTR, average position and query/page breakdowns. Analytics landing-page sessions and conversions provide a different view of visits and business outcomes. They do not establish which search queries have demand.

Use a period long enough to reflect the site’s normal activity and note seasonality. Record the deployment time and any tracking changes so an instrumentation failure is not mistaken for lost search traffic.

Before approving launch, require evidence that:

• Automated checks confirm the planned statuses and destinations across the full mapped URL set where feasible; content checks prioritize business-critical pages and pages with search traffic.
• Representative pages from every public template pass rendering and metadata checks.
• Private and unpublished records remain inaccessible to unauthorized visitors.
• Production canonicals, internal links and sitemap entries agree.
• Pages intended for search have no accidental staging blocks, noindex directives in HTML or HTTP headers, login gates or broken resources.
• Search Console verification and analytics collection still work.
• Someone owns post-launch errors and the comparison against the saved baseline.

After release, inspect priority URLs and watch indexing reports, server errors and traffic by page group. In URL Inspection, distinguish the live test from indexed data: a successful live fetch does not guarantee indexing. Check indexed data for indexing status and, when available, Google’s selected canonical.

If a group loses visits, first check its routes, content, access rules and canonical targets. Compare equivalent periods and filters, allowing for reporting delay and ordinary variation. A single quiet day is not enough to diagnose a failed migration.

Bring the URL map into the migration review

Ask the team rebuilding your app to demonstrate one public page all the way from its Bubble record and existing URL to the replacement response. Then repeat the check with a redirected page, a retired page and a private record.

Bubble to Code’s SEO-safe rebuild service covers redirect mapping, metadata and launch checks as part of the rebuild.