Every other article in this series is about a platform: what Lovable does for you, what Bolt gates behind a paid plan, what Base44 generates automatically. Cursor does not belong in that list, and pretending it does would be unhelpful.
Cursor is an editor. It writes code with you. It does not host anything, does not serve anything to a crawler, and has no SEO features to enable or overlook. Whatever is happening to your app in search was not decided by Cursor.
It was decided at the very beginning of the project, in a moment you may not remember, when either you or the model chose a framework. That choice, made in about four seconds and usually never revisited, determines almost everything about whether search engines and AI assistants can read what you built.
So this article is not about Cursor. It is about finding out what you actually built.
The test that settles it
Open your deployed app, right click, choose "View page source", and look for your own words. Your headline. A feature name. Any real sentence from the page.
This test is completely reliable for a Cursor-built app, which is not true everywhere. Some platforms serve a different, fully rendered version to verified crawlers while showing your browser a shell, which makes view-source misleading. You have no such layer unless you built one. What you see is what Google gets.
The answer puts you in one of three situations.
Situation one: Next.js, or another server-rendering framework
If your content is in the source and your project has an app or pages directory, you built a server-rendering app. Astro, Remix, SvelteKit and Nuxt all land you here too.
Rendering is not your problem. What to check instead:
The 'use client' trap. In the Next.js App Router, the Metadata API only works in Server Components. If a page file has 'use client' at the top, its metadata or generateMetadata export stops working. There is no error and no warning. The page renders perfectly and the metadata is simply absent.
This happens constantly, because it happens for a good reason. You add a modal or a form, something needs useState, you put 'use client' at the top of the page file, the interactivity works immediately, and the metadata dies silently at the same moment.
The fix is to keep the page file a Server Component and move the interactive part into a child component that carries 'use client'. To check whether it has already happened, view source on several pages and compare the <title> tags. If they are all the same, you have found it.
sitemap.ts and robots.ts. Next.js supports both, and creates neither. Visit /sitemap.xml on your deployed site to see whether you have one.
metadataBase. Set it in the root layout to your production URL, or relative Open Graph URLs cannot be resolved and your social previews break.
Situation two: Vite plus React, the plain SPA
If you see an empty <div id="root"></div> and a script tag, this is you. It is the most common outcome, because it is the default that most models reach for when asked to build a React app.
Your content is assembled in the browser. The first response contains nothing to read.
You have three real options.
Pre-render at build time. If your pages are known in advance, marketing pages, guides, documentation, then generate static HTML for each one during the build. The app still behaves as a single-page app once loaded, but the first response has real content. This is the cheapest good answer when it applies, and it is what this very site does.
Move to a server-rendering framework. The durable answer if your pages depend on data that changes per request. It is a genuine migration rather than an afternoon, so do not start here unless pre-rendering truly does not fit.
Split the difference. Keep the app as a client-side app, and build your content pages, the guides and explanations that people actually search for, as server-rendered or static pages alongside it. This is often the most sensible route, because the thing that needs to be findable is your content, not your application interface. Nobody is searching for your settings screen.
Whichever you pick, you also need per-route titles. A Vite SPA ships one set of meta tags in index.html, shared by every route, so a search engine reads your ten pages as ten copies of one page.
Situation three: a static site
If you built with Astro, Eleventy, Hugo, or plain HTML, everything is already in the source and there is nothing to fix on the rendering side.
Check the ordinary things instead: a sitemap, a robots.txt that does not block you, a unique title and description per page, and structured data where it genuinely applies.
The things that are yours regardless
Since no platform sits between your code and the world, every one of these is your responsibility, in all three situations:
A sitemap at /sitemap.xml. Generated from the same source as your pages if they are data-driven, so it cannot drift.
A robots.txt that is not blocking you. The classic failure is a Disallow: / left over from a staging environment, which removes you from search entirely and reports no error anywhere. While you are in the file, decide deliberately whether you allow GPTBot, ClaudeBot, PerplexityBot and Google-Extended, because assistants cannot cite a site they are not allowed to read.
A title and description per page, each written as the answer to that page's question rather than as a brand slogan.
Structured data. SoftwareApplication on the homepage, Article on guides, FAQPage where there are genuine questions and answers, Organization once with your logo and profiles.
Analytics, installed before you start changing things. Otherwise you will work for a month with no way of telling whether any of it helped.
Your own domain, bought before you publish content rather than after, because moving published pages means redirects and redirects done in a hurry lose things.
And the part that is not technical at all
Working with Cursor tends to produce a particular kind of project: technically competent, often genuinely well built, and consisting of one page.
That is the actual reason most of these apps are never found. A page can only be found for the things it discusses. One page means one topic, and that topic is invariably the most contested phrase in your category.
The searches you can win are the specific ones, and they are questions about the problem rather than about your product. Somebody does not search for a category they have never heard of. They describe their situation in their own words and hope something useful appears.
We wrote up a small AI app whose domain was registered on 27 July 2026 and which received, in its first 25 days, 56 visitors from ChatGPT against 23 from Google Search. That happened because the site had specific pages answering specific questions rather than one page describing a tool. The numbers are in this case study, and the full argument is in Your App Has One Page. That Is Why Nobody Finds It.
The short version
Cursor did not cause your SEO situation and cannot fix it. The framework choice made in the first minute of the project did, and you can identify it in about ten seconds with view source.
Server-rendering framework: watch the 'use client' trap and add your sitemap and robots. Plain Vite SPA: pre-render, migrate, or build your content pages separately, and get per-route titles either way. Static site: you are already fine.
Then, in every case, go and write more than one page.
Want us to look at what you built?
If you are not sure which of the three situations you are in, or what it would take to fix, we are happy to go through the project with you on a call.
Related reading: