The SEO work the platform will not let you do
SEO advice stops being useful the second it asks for a change your platform will not let you make. You read that you need a 301 from the old URL, a canonical tag you control, and HTML that arrives already rendered. Then you open site settings and find a checkbox where the tag should be. On a ten page marketing site that gap is nothing. It widens with every page, every language, and every URL you ever decide to move.
Redirects have to be expressed the platform's way
Webflow puts 301 redirects behind a paid Site plan or a paid Workspace plan, which is reasonable. The constraint that bites later is how they are stored. Webflow's help center states there is no hard limit on the number of redirect rules but recommends 1,000 as a maximum, because each rule is written into the site's manifest.json file that visitors' browsers download. Your redirect table and your page weight come out of the same budget, so the advice is to lean on wildcard rules and keep the count low.
Two smaller rules follow from the same design. Redirects are relative to the root domain, so a localized site needs /old-url and /es/old-url written as two separate rules rather than one. And you cannot redirect a page that still exists: to point an old pricing page somewhere new, you first delete it, save it as a draft, or change its slug. With a hundred legacy URLs inherited from an older CMS, that is a hundred small manual acts in a browser UI, with no way to diff them, review them, or roll them back as a set.
Bubble arrives at the same place by a different road. Its documentation is explicit that a 301 redirect only fires for URLs pointing to pages that do not exist in the app. That covers inbound links from a platform you left. It does nothing for the case where you want to reshape URLs inside an app that is already live.
The HTML is the platform's output, not yours
Google crawls, then renders, then indexes, and the render is a separate queue. Google's JavaScript SEO documentation says a page may sit in that queue for a few seconds and can sit there longer, and it still recommends server side rendering or pre-rendering, partly for speed and partly because not every crawler runs JavaScript at all. If your platform decides what arrives in the first HTML response, it has already decided how much of that guidance you get to act on.
In Bubble the canonical tag is a setting. Ticking "Enable canonical url" switches on a Bubble-defined canonical pointing at your primary domain, which is genuinely useful for hiding the built-in bubble.io URL. You are not authoring the value, though, so the exact situation canonicals exist for, two URLs inside your app serving the same content, is the situation you cannot address. Custom head code helps to a point: Bubble's docs note that only script, meta and link tags are valid there, and anything else gets relocated into the body by the browser's own repair logic.
The sitemap works the same way. Bubble generates it, filters it by your privacy rules, and caps it at 50,000 URLs per page, which is the sitemap specification's limit rather than a Bubble decision. Past that, the first 50,000 go in and the rest do not. None of these choices is wrong. They were each made once, for every app on the platform, by someone who has never seen your URL structure.
What changes when you own the render
Stay World Class came to us on Webflow and Xano. We moved the front end to Next.js and the backend to NestJS and Supabase, with a four stage ETL that mapped legacy IDs onto PostgreSQL UUIDs so no record lost its history in the crossing. Lighthouse went from 55.91 to 91 out of 100 and LCP got 77% faster. Those are the numbers people quote back to us.
The SEO half is the unglamorous half, and it is mostly about where things live. Redirects became a config file in the repo, reviewed in a pull request like any other change, with the diff visible before it ships. Canonical tags are a line in the page component and can depend on whatever logic the page needs. Structured data is JSON-LD you write and validate. None of this is clever engineering. The difference is that nobody upstream is deciding it on your behalf, and nothing has to fit inside a form field.
When staying put is the right answer
If your site is forty marketing pages in one language with a URL structure you have no plans to change, everything above is theoretical. Webflow serves those pages as static HTML, a wildcard rule handles most restructures, and you will never come near the 1,000 redirect guidance. Paying an engineering team to rebuild that site would be a bad trade, and I would tell you so on a call rather than take the project.
The case gets real at particular moments. A domain change or an information architecture rewrite that generates hundreds of redirects at once. Localized URLs, where every rule has to be written twice and kept in sync by hand. Add an app-like surface behind a login where the first HTML response is nearly empty and search matters to the business, and the platform has started charging you in work you cannot hand to anyone. If none of that describes your situation, you are fine where you are.
