A pre-launch SEO review prompt for Cursor-built websites

The pre-launch prompt to paste into Cursor

Fill in the four context lines, then paste the prompt. Cursor’s documentation lists an Ask mode that is read-only, an Agent mode that can edit files and run commands, and a Plan mode for reviewing an approach first. Pressing Shift + Tab cycles through the modes. Ask mode is the safest place to begin, because it cannot change your files.

Review this website codebase for SEO launch readiness. This is a read-only review: do not edit files or run commands that change the project.

Context
- Production origin: [https://www.example.com]
- Framework and router: [for example Next.js App Router / React Router / Astro / "tell me what you find"]
- Pages that should be indexable: [list route patterns, or "everything outside /app, /account and /api"]
- Pages that should not be indexable: [list, or "none yet"]

Tasks
1. Map every public route and the file that creates it. Flag important pages that are missing, duplicate paths, login-only pages and routes that appear unfinished.
2. For every indexable route pattern, check whether the main heading, body copy and internal links are present in the server-delivered or pre-rendered HTML. Explain how you established this from the framework and code.
3. Find where <title>, meta description, canonical link, robots meta, Open Graph and Twitter tags are produced. Work out the rendered values for every indexable route pattern. For dynamic routes, show the template and give two realistic example outputs without inventing data.
4. Check canonicals specifically:
   - Is the canonical absolute and on the production origin?
   - Does it follow the same trailing-slash, www and protocol convention as the redirects and sitemap?
   - Are query strings, pagination, filters and tracking parameters excluded or handled deliberately?
   - Can any two different URLs declare the same canonical when their content differs?
   - Does any page canonicalise to a URL that redirects, returns an error, or is noindex?
5. Check robots meta, X-Robots-Tag settings and robots.txt. Flag any block or noindex rule that could reach a public page, including settings controlled by environment variables.
6. Find the sitemap. Check that it lists the intended public routes, uses the production origin and excludes private or noindex pages.
7. Check internal navigation for broken, temporary or inconsistent links. Check whether unknown URLs return a proper not-found response.
8. Search for preview domains, localhost references, placeholder metadata and social images that should not reach production.
9. Separate everything that is confirmed from code from anything that must be tested on the deployed website, such as response status, redirects, headers, performance and the final HTML.

Output
Return a table: page or route | launch check | pass, warning or needs live check | evidence | file. Below it, list proposed fixes as a numbered plan with the files each would touch. Do not apply any of them. Do not state or imply that fixing these will improve rankings.

Attach the folders that hold your routes, layouts and any SEO helper functions as context so Cursor reads the real code. If you want these standards applied every time, Cursor’s rules are the place for persistent guidance.

When to use it

Use it when the website is nearly ready to publish and the main pages are in place. It is also useful before a later release, after a framework or router upgrade, or when adding a new template such as blog posts or product pages.

It is written for developers comfortable reading a code diff. If you built the project with a hosted builder and are not working in a code editor, the Lovable prompt or the Bolt prompt may be a better fit.

What it checks

• Public routes and rendered content. It maps the pages that should be found and checks whether their main content is available without relying on browser-only rendering.
• Where metadata comes from. Duplicate mechanisms for the same route are a common source of surprising output.
• Rendered values for templates. A dynamic route’s title is a pattern, so the prompt asks for example outputs to expose bad fallbacks.
• Canonical consistency. Absolute URLs, one convention for trailing slashes and hostnames, sensible handling of parameters and no canonicals pointing at redirects or errors.
• Accidental noindex. Including staging flags controlled by environment variables.
• Duplicate and placeholder metadata. It flags repeated values and unfinished copy without treating arbitrary character counts as pass or fail rules.
• Social tags. Absolute image and URL values.
• Crawl controls and launch files. Robots settings, sitemap coverage, internal links, missing-page handling and leftover development references.
• Live checks still required. It separates code evidence from redirects, headers and deployed HTML that need testing after publication.

The output table gives you one scannable record per route pattern, and the separate numbered plan keeps findings apart from proposed edits.

What Cursor may still get wrong

• It reads source, not responses. A canonical in code can still be altered by a redirect, proxy or edge rule. Fetch the live URL and compare.
• Dynamic data is invisible. If titles depend on database or CMS content, Cursor cannot know every possible value. That is why it is told not to invent examples.
• Outdated API advice. Models can suggest metadata patterns from older framework versions. Verify against the docs for your installed version.
• Partial context. If a relevant folder was not attached, a finding may be missing without any warning. Ask which files it read.
• Canonical tags are hints. Google treats a declared canonical as a signal, not an instruction, and may select another URL.

After applying fixes, compare Search Console’s user-declared and Google-selected canonical for key URLs. Our Next.js SEO guidance and Next.js SEO essentials cover how metadata and canonicals fit into the wider rendering picture.

A worked example

This is an illustrative scenario, not a client result. Imagine a software company’s documentation site with a template for guide pages at /guides/[slug].

Cursor’s table might show that guide pages build their canonical from the incoming request address, so /guides/setup?utm_source=newsletter declares itself as canonical. It might also show a shared layout that sets a default description which a few guide pages never override, and an environment flag that adds noindex whenever a variable is missing.

You read the plan, approve the canonical fix and the noindex guard, and decline the description rewrite until someone writes proper copy. You then switch to Agent mode to apply those two items, review the diff, deploy to a preview, and fetch the page source for a parameterised URL to confirm the canonical is clean. It is the live response, not Cursor’s summary, that settles the question.

Next step: test what the live site returns

Code review finds intent, and the live response shows the result. For complex stacks, our Cursor SEO service and the developer SEO pages cover rendering, metadata and release checks in depth.

Book a site review and we will check the live pages for you, or send us a message if you would like to describe the problem first. You can also browse the rest of the resources hub.