Cursor is an AI-powered code editor, not a site builder. That distinction matters for SEO. Unlike vibe-coding platforms that generate a standalone app in one shot, Cursor sits inside your development workflow and writes code alongside you, file by file. That means every page component, every route, and every metadata call passes through prompts you write, and the quality of those prompts determines whether the output is crawlable or invisible to Google.
The mechanism that makes Cursor different from other AI coding tools is its project rules system. Rules files are persistent instructions that Cursor loads with every prompt in your project. Instead of repeating “always use server-side rendering” or “every page needs a canonical tag” in every chat message, you write those requirements once and they stick. For SEO, that’s the key leverage point.
Why AI-generated code often fails SEO
Most AI coding tools default to what works visually, not what works for crawlers. Client-side React components render blank HTML on the server, navigation built with onClick handlers produces no crawlable links, and generated pages frequently have identical or missing <title> tags.
The problem isn’t the AI. It’s that without explicit constraints, the model optimises for a working browser experience. Search crawlers and AI crawlers operate differently: Googlebot does render JavaScript, but with a delay and a queue. AI crawlers used by ChatGPT, Perplexity, and the systems powering Google AI Overviews often fetch raw HTML without executing JavaScript at all. If your content only exists after a React state update, those crawlers see an empty page. This is the same failure mode documented across the broader platform SEO landscape.
Writing project rules that enforce SEO
Project rules in Cursor live in .cursor/rules/ as .mdc files. Each file is a markdown document with optional scope patterns (which file types or paths trigger it) and freeform instructions. Rules are injected into the system prompt automatically when the scope matches.
The SEO-critical rules to encode from day one:
Server rendering first. If you’re building with Next.js, the rule should state that pages are Server Components by default and 'use client' is only added when interactivity requires it. For Astro projects, this is already the default, but the rule reinforces it.
Per-page metadata. Every page component must export or include a unique <title> and <meta name="description">. For Next.js, that means the Metadata API (export const metadata = { title, description }). For other frameworks, it means react-helmet or framework-equivalent calls. The rule should specify the exact API so the model uses it consistently.
Semantic HTML. Navigation goes in <nav>, main content in <main>, sections in <section> or <article> where appropriate. Headings follow a single H1 per page, then H2/H3 hierarchy.
Real anchor links. Any link that should be crawlable uses an <a href="..."> tag, not an onClick handler or useNavigate() call. The rule should say: “if the user is navigating to a URL, use an anchor tag.”
Sitemap and robots.txt. The project must include a sitemap at /sitemap.xml and a robots.txt. For Next.js 13+, this means app/sitemap.ts and app/robots.ts. For Astro, @astrojs/sitemap integration. The rule names the specific file or integration so the model adds it when generating the project scaffold.
Schema markup. Pages with products, articles, FAQs, or organisations should include JSON-LD. The rule specifies which schema types apply to which route patterns.
Here’s a working example of an SEO rules file for a Next.js 14 project:
// .cursor/rules/seo.mdc
---
description: SEO conventions for all pages and components
globs: ["app/**/*.tsx", "app/**/*.ts"]
---
# SEO Rules
## Rendering
- All page components are React Server Components by default.
- Only add 'use client' when the component requires browser APIs, event listeners, or React state/effects.
- Never fetch page content client-side if it can be fetched server-side.
## Metadata
- Every page.tsx file exports a metadata object or generateMetadata function.
- title must be unique per page (50-60 characters).
- description must be unique per page (150-160 characters).
- canonical URL must be set: alternates: { canonical: absoluteUrl }.
## Navigation
- All navigation links use <Link href="..."> (Next.js) or <a href="...">, never onClick navigation.
- Breadcrumbs use <nav aria-label="Breadcrumb"> with <ol> and <li> children.
## Sitemap
- app/sitemap.ts must exist and return all public routes.
- New routes must be added to the sitemap.
## Schema
- Product pages include JSON-LD Product schema.
- Blog posts include JSON-LD Article schema.
- The site root includes Organization schema.
- JSON-LD is injected via <script type="application/ld+json"> in the page layout or component.With this file in place, every code generation prompt in your project inherits these constraints. Ask Cursor to “add a blog post page” and it will output a Server Component with metadata exports, anchor-based navigation, and an Article JSON-LD block.
Prompting patterns for SEO-correct pages
Rules handle the defaults. Prompts handle the specifics. A few patterns that consistently produce crawlable output:
State the rendering requirement explicitly. “Build a product listing page as a Server Component. Data is fetched server-side from this API endpoint.” Even with rules, naming it in the prompt eliminates ambiguity.
Give the metadata values. “Page title: ‘Running Shoes for Women | Brand Name’. Description: ‘Shop women’s running shoes…’.” The model will use them exactly, which saves an edit cycle.
Specify the schema type. “Add JSON-LD for this product using schema.org/Product with name, image, description, sku, and offers.price.” Precise prompts produce complete schema rather than skeleton output.
Ask for internal links explicitly. “Add a breadcrumb using <nav aria-label='Breadcrumb'> linking back to /running-shoes/ and /women/.” Without this, AI tools often omit breadcrumbs or stub them.
Frame rewrites around crawlability. “This component uses onClick for navigation. Rewrite it using anchor tags so the links are crawlable.” Framing the goal rather than the technique gives the model room to find the cleanest solution.
Using Cursor to audit an existing codebase
Cursor isn’t only for greenfield builds. If you have an existing React or Next.js project, you can use it to systematically find and fix SEO gaps. The approach: point Cursor at specific problem categories with targeted prompts, then review and apply the output file by file.
Find client-only content. Ask: “Search this codebase for components that fetch content with useEffect or useState where the data should be visible to crawlers. List the files.” Then for each flagged file: “Refactor this component to fetch data server-side.”
Find pages missing metadata. Ask: “Which pages in app/ are missing a metadata export or generateMetadata function?” Then: “Add a metadata export to this page with the title and description I’ll provide.”
Find click-handler navigation. Ask: “Find all instances of onClick handlers that navigate to a URL using router.push or window.location. List them.” Then: “Replace these with anchor tags.”
Audit schema coverage. Ask: “Which of these pages would benefit from JSON-LD schema? For each one, suggest the schema type.” Then generate the JSON-LD per page.
This workflow pairs well with the React SEO and Next.js SEO guides, which cover the framework-specific mechanics in more depth.
How Cursor compares to Claude Code for SEO work
Both Cursor and Claude Code are AI coding assistants that can build and refactor sites. The practical difference is where the session lives. Cursor is embedded in VS Code and operates file by file with full project context via rules. Claude Code is a terminal agent that can orchestrate multi-step tasks across the codebase.
For SEO work specifically, Cursor’s rules system is the stronger lever when you’re building incrementally, because the rules run on every prompt without you having to repeat them. Claude Code has an equivalent mechanism (CLAUDE.md project instructions), but the interaction model is more agent-like, better suited to “audit the entire site and generate a fix list” than to in-editor code generation.
The two tools complement each other. Use Cursor rules to enforce SEO standards as you build. Use Claude Code or a one-shot agent for bulk audits and automated remediation runs.
AI citations and Cursor SEO
Getting cited in ChatGPT, Perplexity, and Google AI Overviews follows the same ground rules as Google ranking, with one difference: AI crawlers fetch content at indexing time and often skip JavaScript execution entirely. Pages that depend on client-side rendering for their main content are frequently absent from AI-cited sources, even if they rank reasonably well in Google.
The practical implication for Cursor projects: the server-rendering rule isn’t just about Google. It’s the prerequisite for AI visibility. A page that serves its full content in raw HTML is indexable by every crawler, human or AI. A page that renders content in the browser after a React hydration pass is invisible to most of them.
Schema markup has a multiplying effect here. AI systems use structured data to understand what a page is about, what it offers, and who produces it. An Article schema with author, datePublished, and headline gives AI models signal that the content is citable and attributable. A Product schema with name, offers, and description makes it easier for AI to surface your product in comparative queries. Adding schema via Cursor is a one-prompt task per page type once you have the pattern established. For a deeper look at how schema affects AI visibility, see the AI SEO guide.
Tools like Fokal can track how well a site shows up in AI citations over time, running target queries against ChatGPT, Perplexity, and Google AI Overviews on a schedule. That kind of monitoring makes it visible when a technical change, like fixing a client-rendering issue, actually moves the needle on AI mentions.
What to do next
If you’re starting a new project in Cursor, create the .cursor/rules/seo.mdc file before generating any pages. The rules take two minutes to write and save every future prompt from having to repeat the same constraints.
If you’re auditing an existing project, start with the client-rendering check. That single issue causes the most SEO damage and is the fastest to systematically find and fix with targeted prompts.
Quick checklist
- Create
.cursor/rules/seo.mdcwith rendering, metadata, navigation, sitemap, and schema rules - All page components are Server Components (or SSG) by default
- Every page exports a unique title and description
- Navigation uses
<a href>or<Link href>, not click handlers - Sitemap file exists and covers all public routes
- Key page types have JSON-LD schema (Article, Product, Organization)
- Breadcrumbs use semantic
<nav>markup with a crawlable link structure - Run a crawlability audit: fetch key pages with JavaScript disabled and confirm content is present
- Check AI visibility for pages you want cited in AI answers