The one-step deploy is a preview, and its documentation says so

Windsurf will put your app on a public URL from inside the editor, which is genuinely convenient. The thing worth reading before you treat that URL as your product's home is Windsurf's own description of what it is.

Claims on this page were last checked against the platform's own documentation on .

See what a crawler gets

Windsurf's App Deploys lets you deploy web apps to public URLs from inside the editor. Its documentation describes the feature as beta, states that App Deploys are intended primarily for preview purposes, and explains that your code is uploaded and deployed to the provider under Windsurf's umbrella account, with claiming your deployment recommended for production use.

What App Deploys actually is

Windsurf's documentation describes App Deploys as a way to deploy web applications and sites directly within Windsurf, through the editor's agent, giving you a public URL you can share and update.

It also says three things about that feature which matter more than the convenience.

The feature is in beta, with support for additional frameworks and more robust builds described as coming. App Deploys are intended primarily for preview purposes, and for production applications with sensitive data the documentation recommends claiming your deployment and following security best practices. And when you use it, your code is uploaded to Windsurf's server and deployed to the provider under their umbrella account.

None of that is hidden and all of it is easy to skip past when the thing you wanted was a link to send somebody.

Why an address you do not own is the problem

This is the same argument made on the custom domain page, and it applies with extra force here because the deploy is so easy that people stay on it far longer than they meant to.

Everything your site earns accumulates onto the address it is served at. Pages get indexed at that address. Any link anybody makes points at it. Any mention in a directory names it.

When you eventually move to your own domain, all of that has to be redirected, and some of it does not transfer cleanly. The move gets more expensive every week you postpone it.

There is a second consideration specific to a deploy that sits under somebody else's account. Your ability to control redirects, to serve files at the root, and to keep the address permanently is not fully yours, which is precisely the set of things you need when you migrate.

Claim it, then move it

The documentation's own recommendation for production use is to claim your deployment, and that is the right first step.

Claiming moves the deployment out of the shared umbrella arrangement and into an account you control with the underlying provider, which is what gives you real control over the domain, the configuration and the lifetime of the thing.

After that, connect a custom domain, which is the item that should happen before you write a single content page. The order matters: claim, then domain, then everything else, because each step attaches to the one before it.

If you are past that already and have been publishing on the preview URL for a while, move anyway. It does not get cheaper.

The editor has no opinion about the rest

Once hosting is sorted, Windsurf is in the same category as Cursor and Claude Code: it writes code into your repository and makes no decisions about how the result is served.

Which means the rendering behaviour comes from the stack, and the stack was chosen in an early prompt, usually without anybody weighing it. In practice that most often produces Vite with React and client-side routing, which serves one nearly empty HTML file for every route.

It also means nothing will volunteer a sitemap, a robots.txt, per-route metadata or structured data, because a request to build a feature does not imply any of them. Every one of those has to be asked for.

The remedy is the same one that works on any assistant-driven project: ask for the whole set once rather than discovering the gaps one at a time, and write a standing rule into the project instructions so future sessions do not reintroduce the gap.

What to ask for

Specific requests, because vague ones produce vague results.

  • Build-time pre-rendering for every route, with the route list read from the router configuration rather than kept as a separate list.
  • A per-route metadata mechanism, and then actually different values for every page.
  • Sitemap generation during the build, from the same route source the pre-rendering uses, so the two cannot drift apart.
  • A robots.txt, which you then read yourself rather than assuming is sensible.
  • Structured data appropriate to what each page is, with the required properties checked rather than assumed.

Where that leaves you

Windsurf makes shipping fast, and speed of shipping is not the constraint on getting used.

An app on a claimed deployment, on your own domain, serving real HTML, with a sitemap and per-page titles, has cleared the obstacles. It has not yet solved anything, because a well-built site with one page describing the product can still only be found for one thing.

The tool can help you write the pages too, on one condition: you supply what only you know. A page generated from a general prompt about your category reads like every other page about that category, and there are already many of those.

So the sequence is claim, domain, technical set, then the long part, which is the pages.

Part of a larger guide

This page is one part of Vibe coding SEO. The other parts:

Questions people ask

Is Windsurf's App Deploys suitable for production?
Its documentation describes the feature as beta and says App Deploys are intended primarily for preview purposes, recommending that you claim your deployment and follow security best practices for production applications with sensitive data. Treat the default deploy as a preview, because that is what it is called.
Who owns the address my Windsurf app is deployed to?
By default not you. The documentation explains that your code is uploaded to Windsurf's server and deployed to the provider under their umbrella account. Claiming your deployment moves it into an account you control, which is what gives you real authority over the domain and configuration.
Why does staying on the preview URL cost me?
Everything your site earns accumulates onto the address it is served at: indexed pages, links, directory mentions. Moving later means redirecting all of it and accepting some will not transfer cleanly, and the cost grows every week. The deploy being so easy is exactly why people stay too long.
Does Windsurf handle SEO for my app?
No more than Cursor or Claude Code does. It writes code into your repository and makes no decision about how the result is served, so the rendering comes from the stack chosen in an early prompt, and nothing volunteers a sitemap or metadata because building a feature does not imply them.
What should I ask Windsurf to build?
Build-time pre-rendering with the route list read from the router config, a per-route metadata mechanism with genuinely different values, sitemap generation from that same route source, a robots.txt you then read yourself, and structured data with the required properties checked.
What is the right order to do all this in?
Claim the deployment, connect your own domain, then the technical set, then the pages. Each step attaches to the one before it, so doing the domain late means redoing most of what came after it.

Check what your deployed app is serving

The free crawler view fetches your deploy URL without running JavaScript and reports exactly what a crawler receives.

See what a crawler gets Have Licheo do it for you