# Rampify — full documentation > The complete Rampify documentation in one file. Rampify is the SEO intelligence layer for AI coding tools: connect over MCP and your AI works from deterministic, real-time SEO context (live-site crawls + Google Search Console), the same data the dashboard shows. Sections below mirror the docs site. ## Getting Started URL: https://www.rampify.dev/docs Getting Started with Rampify Rampify is the SEO intelligence layer for AI tools. You bring the AI tool; Rampify brings the project context: site structure, what's indexed, which keywords are pulling weight, what gaps competitors are leaving open. How Rampify works Two surfaces, one project. The dashboard is the system of record. It pulls signals from the sources that matter for SEO (your site's crawls and technical state, Google Search Console queries and impressions, Discovery research sessions, the keyword clusters you've built), normalizes them, and synthesizes a coherent picture of your project. The visual workspace is for you to review and steer. The MCP server is the active surface. Every piece of that synthesized picture is queryable from Claude Code, Cursor, VS Code, Claude Desktop, or claude.ai through MCP tools. Your AI gets the same project context you see in the dashboard, in a shape it can reason over. The choice of AI tool is yours. The choice of surface depends on what you're doing. Drafting content in a long conversation? Use claude.ai or Desktop. Implementing a spec in code? Use Claude Code or Cursor. Same Rampify either way. Quick start Lands you straight in a setup wizard. Under 3 minutes. The wizard's first question, marketing site or app, sets the path for everything that follows. It adapts to where you're starting: The wizard ends on a stage-appropriate menu of first actions: Discovery research, keyword planning, content drafting, or a technical audit, depending on what fits your project. The wizard's last step (and every project page) has a one-click install picker. Pick the tool you use; Rampify handles the auth via OAuth on first connect. ↓ Try it. Fully interactive, same picker as in the app. Full setup details and the Claude UI walkthrough live in the Connecting guide. Once connected, Rampify pulls indexing data and weekly performance signals. The MCP get search performance tool gives your AI direct access to query data, top pages, and ranking-opportunity queries. Catch indexing problems early; turn search data into content briefs. Not sure what to do first? Ask your AI: What should I do next on this project? It calls suggest next action with your project's current state. What you can do A few common workflows that span both surfaces: Workflow Where it happens What you get --- --- --- Discover positioning gaps and competitor angles claude.ai, Claude Desktop A structured research output from a multi-step conversation Cluster keywords into content briefs claude.ai, Claude Desktop Content briefs grounded in your business profile Crawl your site for SEO issues Triggered from any AI tool Feature specs filed for Cursor or Claude Code to implement Generate meta tags and JSON-LD schema Any AI tool Ready-to-paste tags for a page you're shipping Pull GSC insights and content recommendations Any AI tool Query-level performance data ready to inform what to write next The split isn't rigid. A developer planning content can use claude.ai for the long thinking, then Cursor for the implementation. A marketer drafting a brief can stay in Claude Desktop the whole time. Rampify follows you across surfaces because every tool is exposed via MCP. ## Introduction URL: https://www.rampify.dev/docs/introduction What Is Rampify? Rampify provides SEO Intelligence Where You Code , a new way for developers to understand, fix, and optimize SEO from their AI coding tools, empowering developers to optimize websites, in collaboration with marketers. Instead of switching between dashboards, crawlers, and browser extensions, Rampify crawls your live site in the cloud, turns it into structured SEO intelligence , and makes that data available directly inside Cursor, VS Code, Claude Code, or any MCP-compatible tool. You get real page-level insights, metadata analysis, schema detection, internal link context, indexability signals, and issue summaries, all right where you write your code. This is particularly valuable when building custom coded websites with marketing pages, as opposed to using a CMS like WordPress or Webflow. Why Rampify Exists Most SEO tools were built for marketers but most development happens in your AI coding tools, creating a painful gap. SEO issues are typically discovered after deployment, requiring developers to jump between multiple tools to investigate and fix them. Metadata gets written manually and inconsistently, crawlers run outside the development loop entirely, and AI coding assistants try to "guess" at SEO without any real context about your live site. Rampify closes this gap by bringing live-site SEO intelligence directly into the developer workflow. How Rampify Works (High-Level) Rampify is built around three simple ideas: 1. Crawl your live site (hosted HTTP-only crawler) Rampify runs a fast, cloud-based crawler built on axios + cheerio . It follows your sitemap (recommended), discovers pages through navigation when needed, collects structured SEO fields, and identifies issues and signals. Importantly, it does not execute JavaScript, making it faster and more predictable for SEO analysis. Crawls happen on-demand (free tier) or automatically every 24 hours (paid plans). 2. Turn crawl results into structured SEO intelligence All extracted fields and signals are stored in a structured format to support cross-URL comparisons, issue analysis, internal link mapping, and indexability evaluation. Metadata (title, description), canonical tags , robots directives , Open Graph tags, JSON-LD / microdata / RDFa structured data, headers , indexability signals , response codes , internal links , and content depth hints . Rampify does not rewrite your content and does not make ranking predictions. Its job is to surface real data from your site, cleanly and consistently. 3. Bring SEO intelligence where you code Rampify uses the Model Context Protocol (MCP) to expose structured SEO data as tools your AI assistant can query. Think of it like RAG (Retrieval-Augmented Generation) but for SEO intelligence: instead of your AI guessing about your site's SEO health, it retrieves real data from Rampify's crawl results and Google Search Console, then uses that context to provide accurate recommendations. When you ask "How's my SEO?" your AI calls get page intelligence to fetch actual metadata, indexing status, and detected issues. When you ask "Generate meta tags for this page," it calls generate meta with real page content and SEO signals as context. A few of the most-used MCP tools: - crawl site : Crawl the site, record URLs, and detect SEO issues - get page intelligence : Every metric Rampify knows about one page in a single call - generate meta : Optimized meta tags grounded in real page data - generate schema : Auto-generated schema.org JSON-LD markup - get search performance : Top pages, queries, and ranking opportunities from Google Search Browse the full catalog in MCP Tools, where every tool has its own page with parameters and sample prompts. Architecture Rampify is a data layer, not an AI service. It crawls your site, extracts structured SEO fields, and exposes that data through MCP tools. Your AI assistant (Claude, GPT-4, etc.) calls these tools to retrieve real context, then generates recommendations or content based on actual data rather than assumptions. What You Can Do With Rampify Who Rampify Is For Rampify analyzes sites at the HTTP level, so the underlying stack doesn't matter: Next.js, Astro, WordPress, or static HTML all crawl the same. The question is who's doing the work: Summary Rampify delivers SEO intelligence where you code by combining live-site crawling, Google Search Console integration, and structured data APIs. Your AI assistant queries real SEO context through MCP tools instead of guessing, by checking actual indexing status, analyzing real metadata, and generating recommendations grounded in your site's current state. This isn't another SEO dashboard you switch to. It's SEO intelligence in your AI coding tools, available wherever you write code. Ask your AI assistant about SEO, and it retrieves real data. Generate metadata, and it's grounded in actual page content. Check indexability, and it pulls from Google Search Console. The result: faster SEO workflows, fewer regressions, and AI-powered optimizations backed by deterministic data rather than assumptions. ## How Rampify Works URL: https://www.rampify.dev/docs/how-rampify-works How Rampify Works Rampify brings SEO Intelligence Where You Code by combining a hosted crawler, structured data extraction, and editor-native tools built on the Model Context Protocol (MCP). This page explains the architecture that powers it. Overview Rampify's architecture flows from ground truth to natural language interface through four distinct layers: 1. Reality : Your actual site and Google Search Console data 2. Rampify API : HTTP crawler and structured data storage 3. MCP Server : Stateless intelligence layer exposing structured tools 4. LLM : Natural language interface powered by deterministic data Each layer handles what it does best, ensuring your AI assistant gets deterministic, real-time SEO context grounded in how your actual website behaves, not guesses, heuristics, or hallucinations. The Layered Architecture Rampify uses a layered architecture that puts each technology in its proper place: Reality (Your Site + Google) Your actual site, GSC data Ground truth ↑ accesses Rampify API (Data Layer) Crawling, GSC integration, rules Deterministic (Authoritative sources) ↑ fetches MCP Server (Intelligence Layer) get page intelligence, crawl site Deterministic (Structured data access) ↑ queries LLM (Natural Language Interface) "What SEO issues should I fix?" Non-deterministic (Conversation, explanation) --- Layer 1: Reality (Ground Truth) The foundation of Rampify's architecture is your actual site and Google Search Console data . This is the source of truth. What actually exists, how Google sees it, and what performance data shows. Instead of relying on AI to guess about your site's SEO health, Rampify starts with deterministic facts: HTTP responses, HTML structure, GSC indexing status, and search performance metrics. Everything flows from this ground truth. Layer 2: Rampify API (Data Collection & Storage) Rampify uses a hosted, HTTP-only crawler designed specifically for SEO diagnostics. It's built on axios for HTTP requests and cheerio for server-side HTML parsing (jQuery-like traversal), with deterministic sitemap-first crawling and navigation fallback when needed. Google's crawler (Googlebot) primarily operates as an HTTP crawler, not a full JavaScript runtime. While Google can execute JavaScript, most SEO signals come from the initial HTML response. An HTTP-only approach is: - Faster - No browser overhead, Puppeteer crashes, or memory leaks - More reliable - Deterministic behavior, easier to debug and reproduce - Closer to reality - Matches how Googlebot actually sees most sites - Better for SEO - Server-side rendered content is what gets indexed first This approach works best for sites with server-side rendering (Next.js, Remix, Astro) or static generation. For heavily client-rendered SPAs, you'll want server-side rendering for SEO anyway. How & When Crawling Happens The crawler follows a sitemap-first approach : it looks for your sitemap.xml (or discovers it through robots.txt), prioritizes those URLs, and only falls back to navigation crawling if no sitemap is found. Each URL gets a 10-second timeout, redirects are followed up to 5 hops (tracking the full chain), and canonical URLs are identified to avoid duplicates. Crawls run on-demand (free tier) or automatically every 24 hours (paid plans). Each crawl includes change detection, automatically flagging new pages that appeared since the last run. This ensures your AI coding tools always have fresh SEO intelligence. What Gets Collected Page metadata (title, description), canonical URL , robots directives , status codes & redirect chains , Open Graph tags , JSON-LD/Microdata/RDFa structured data, internal links (with link graph relationships), and content depth signals (word count, heading structure). We do not scrape full content bodies to avoid overreach and keep page evaluation fast. Your Website Metadata as a Queryable API Here's what makes Rampify different: we store metadata about your site in a structured database that you can query through the Rampify API . This isn't just another crawler report you download once, it's persistent, queryable infrastructure for your site's SEO state. SEO has hundreds of nitpicky details to track: canonical tags, redirect chains, schema markup, internal link counts, indexing status, meta descriptions, Open Graph tags. The only way to get this right is to retrieve, store, and query this data deterministically. AI cannot hold all this information in context or reliably follow instructions across conversations. It needs ground truth to retrieve from. This gives you something unique: an API for your own website's metadata . You can ask questions like "Which pages are missing descriptions?" and get back structured data from your actual site, not AI guesses, not stale reports, but current facts stored in a queryable format. Cross-URL comparisons, issue analysis, internal link mapping, indexability evaluation, all backed by deterministic storage, not LLM memory. The result is a separation of concerns that developers understand: persistent storage handles ground truth, APIs provide structured access, and AI provides the natural language interface on top. Layer 3: MCP Server (Intelligence Layer) Rampify integrates with IDEs through the Model Context Protocol (MCP) , a standard that lets tools expose structured actions your AI assistant can call. This layer is intentionally stateless . The MCP server acts as a bridge between your AI coding tools, Rampify's API, and your live site. A stateless design means SEO data is always fresh and consistent: - Always current - Every query fetches latest crawl data, no stale cache - Deterministic - Same query always returns same result for current site state - Auditable - You can trace every recommendation back to source data - Reliable - No cache invalidation bugs, no sync issues between machines - Lightweight - No local database, no storage management in your AI coding tools The tradeoff: slightly higher latency per query. But for SEO data that changes slowly (hours/days, not seconds), fresh data beats cached speed. MCP Tools Available Rampify exposes tools across three categories: - Analysis tools - Get SEO data for pages and sites ( get page intelligence , get issues , get search performance ) - Generation tools - Create metadata and schema grounded in real data ( generate meta , generate schema ) - Crawl tools - Trigger fresh analysis on-demand ( crawl site ) For complete tool documentation, parameters, and examples, see the MCP Tools Reference. Layer 4: LLM (Natural Language Interface) The top layer is your AI assistant using natural language to interact with all the deterministic data below. Rampify is not an LLM wrapper : you bring your own model (Claude, GPT-4, etc.) and your own subscription. Rampify simply delivers SEO context to your model of choice through the MCP protocol. The MCP layer enables a clear separation of concerns between what AI should and shouldn't handle: When you ask your AI assistant "How's the SEO on this page?", it calls get page intelligence to retrieve deterministic data, then synthesizes that into a natural language explanation. The AI doesn't guess; it reports what the crawler actually found. Here's what actual data looks like (simplified): { "url": "/blog/seo-tips", "status code": 200, "metadata": { "title": "10 SEO Tips for Developers", "description": "Learn how to optimize your site...", "canonical": "/blog/seo-tips" }, "indexability": { "robots meta": "index, follow", "in sitemap": true, "internal links count": 3 }, "schema": { "detected": true, "types": ["Article", "BreadcrumbList"], "valid": true }, "issues": [] } Your AI uses this structured data to generate responses like: "This page looks good - indexed, has schema markup, 3 internal links. Title could be shorter (currently 65 chars, aim for 60)." Summary Rampify's architecture separates deterministic data collection from AI-powered analysis. The HTTP crawler extracts structured SEO fields from your live site, stores them in a queryable format, and exposes that data through MCP tools your AI assistant can call. When you ask "How's my SEO?", your AI doesn't guess, it queries get page intelligence for actual crawl data, then synthesizes that into natural language. When you generate metadata, it's grounded in real page content and existing SEO signals. When you check indexability, it pulls from Google Search Console. The result: SEO workflows that happen in your editor, powered by deterministic data instead of LLM assumptions. Next: the Discovery Optimization guide covers the research methodologies that turn this data into being found across search and AI answer engines. ## Dashboard & MCP URL: https://www.rampify.dev/docs/dashboard-and-mcp Two surfaces, one project Everything in a Rampify project (keywords, specs, crawl data, research) is one dataset with two front doors. The dashboard is where you see and curate it. MCP is how your AI does something with it , in the middle of a conversation, without you switching tabs. The model Neither surface is a copy or an export of the other. Both read and write the same records, so a cluster your AI creates over MCP is on the Keywords page before you finish the sentence, and a spec you edit in the dashboard is what your coding tool sees on its next call. The mapping isn't 1:1 everywhere. Agent-invoked tools (the discovery submit family) have no dashboard surface at all, and Project Settings deliberately has no MCP surface; credentials stay out of conversations. Where the surfaces meet Each dashboard page pairs with a family of MCP tools over the same data: Specs , 'Feature specs, tasks, criteria, commits', 'Feature Specs'], [ Discovery , 'Research sessions and findings', 'Discovery Research Sessions'], [ Website , 'URLs, crawl checks, issues', 'Site Analysis & Monitoring'], [ Keywords , 'Clusters and tracked keywords', 'Keyword Research & Management'], [ Google Search , 'GSC performance and indexing', 'Site Analysis & Monitoring'], [ Business Profile , 'Positioning, audience, competitors', 'Business Profile & Competitors'], [ Products , 'Products and their positioning', 'Business Profile & Competitors'], ]} / The bridge between them You don't have to remember the mapping; the product carries it. Every dashboard page's toolbar has an MCP handoff : a paste-ready prompt, pre-filled with the project context of the page you're looking at, that drops your AI into the same data over MCP. It's the one-click path from reviewing something in the dashboard to acting on it in a conversation. (Not connected yet? The same pill installs the connection; see Connecting.) How these docs reflect it Every dashboard page ends with a From your AI tool section mapping what you just read to the tools that do it. In the other direction, tool pages carry a connected surface note pointing back to the dashboard page that views the same data, wherever the mapping is clean. Tools without one (agent-invoked bookkeeping, workflow utilities) genuinely have no dashboard counterpart, and that absence is informative too. ## Search Engine Indexing URL: https://www.rampify.dev/docs/indexing Search Engine Indexing Publishing a page and being findable are two different things. Between them sits a pipeline you don't control (discovery, crawling, indexing), and pages drop out of it silently. The index that pipeline feeds is the foundation of being found everywhere it matters now: the classic results page and the AI answer. Understanding it is the difference between "we shipped it" and "people can find it." From published to findable Every search surface (Google, Bing, and increasingly the AI answer engines) runs some version of the same pipeline: 1. Discovery: the engine learns your URL exists, from your sitemap, a link, or a previous crawl. 2. Crawling: it fetches the page and reads what's actually served. 3. Indexing: it decides the page is worth storing and retrieving. 4. Ranking / citation: the page competes to appear in results or get cited in an answer. Each stage is a gate. A page that fails discovery is invisible no matter how good it is; a page that's crawled but judged thin never reaches the index; an indexed page with no authority never ranks. When something "isn't showing up in Google," the first question is always which gate did it fail? , and that's exactly what coverage states tell you. What coverage states actually mean Google reports a verdict per URL. Four of them cover almost everything you'll see: Ranking: the algorithm after the index Reaching the index isn't the finish line: it's admission to the competition. When someone searches, the engine doesn't scan the web; it queries its index and runs an algorithmic selection over everything stored there. The signals are familiar even where the weights are secret: relevance (does the page actually answer the query), authority (do other credible pages and entities point at it), freshness (is it current, where currency matters). The failure mode at this gate is indexed but invisible : the page is in the index, eligible to appear, and sits at position 40 where nobody will ever see it. That's not an indexing problem, and indexing fixes won't move it; it's a competition problem. The levers are different: tighter content-to-query match, internal links that concentrate authority on the pages that matter, and picking queries you can plausibly win. The most movable ground is the within-reach queries (page-two rankings and high-impression-low-CTR results), which Google Search surfaces directly. One index, two retrieval surfaces The reason indexing is worth understanding, rather than delegating to a checklist, is that the crawl-and-index foundation now feeds two different kinds of retrieval: These aren't separate disciplines — they're two facets of the same thing. Both start from a crawler that found your URL, fetched it, read real content, and stored it. The hygiene work (a sitemap, clean internal links, server-rendered content, a deliberate robots policy) pays on both surfaces at once. Where they genuinely differ: - AI crawlers keep their own indexes. OAI-SearchBot, PerplexityBot, ClaudeBot and friends fetch and store independently of Google, and your robots.txt is a per-crawler decision: being indexed by Google says nothing about being readable to the bots that feed answers. AI Visibility covers that side's three gates (discoverable, allowed, readable), the same pipeline told for AI crawlers. - Most AI crawlers don't run JavaScript , not even as a deferred second pass the way Google does. A client-rendered page is a handicap in classic search and a wall in AI answers. - Answers cite; results rank. A results page degrades gracefully: position 8 still earns some clicks. An answer is winner-take-most: a few citations carry it, and everything else might as well not exist. Whether you're among them is your AI Answer Presence. Getting indexed is the shared prerequisite; what changes per surface is how winners are picked. Fix the foundation once, then optimize each scoreboard on its own terms: rankings on one, citations on the other. Why the raw data goes unused Search Console holds all of this, and most developers check it once and never go back. The failure modes are consistent: - Data without direction. A thousand queries, 47 not-indexed pages, no "fix this next." Everything is reported; nothing is prioritized. - Scattered context. Query data in Performance, coverage in Pages, per-URL detail in URL Inspection. Understanding one page means mentally assembling three tabs. - Outside your workflow. The data lives in a browser tab; your work lives in an editor and a repository. Every check costs a context switch. - Expertise required. "Crawl anomaly detected" and "average position 7.8" are only actionable if you already know SEO. The interface assumes you do. The result isn't that the data is wrong; it's that fixable issues accumulate unread. Check it yourself Don't trust site: queries; they're a rough sketch, not the index. For a real answer about one URL, use Search Console's URL Inspection and read the coverage state and the crawled as date. If the verdict surprises you (a page you care about sitting in "Discovered – currently not indexed" for weeks), that's the pipeline telling you where it stalled. How Rampify surfaces it Rampify pulls your Search Console data on a schedule and folds the verdicts back into the pages they belong to, so the pipeline is readable instead of reconstructed: - Per-URL verdicts sit in the Website table next to each page's crawl health: coverage state, canonical choice, last crawl, and 28-day performance in one row. - Indexed pages over time charts on Home, reconstructed from Google's own URL inspection log. "Indexed" always means Submitted and indexed : one definition everywhere, so numbers never disagree between pages. - Query and page performance reads cleanly in Google Search, including the within-reach queries (page-two rankings, high-impression low-CTR) where small fixes move real traffic. - The AI side of the foundation is checked on the same crawl: the Website page's AI visibility card reports render mode and which AI crawlers your robots.txt admits. - Your AI gets the same data over MCP: get search performance for the site-wide picture, get page intelligence for one page's full story, so "how is this page doing?" is answerable without leaving your editor. What to do about pages that go missing The remediation follows the gate that failed. Not discovered: fix your sitemap and internal links, because orphan pages stay invisible. Discovered but not crawled: raise the page's apparent value (link to it from pages that matter) and give Google time. Crawled but not indexed: the content itself needs work; make it less thin or less duplicative before asking again. Excluded: audit your robots.txt, noindex tags, and canonicals, and make sure every exclusion is a decision, not an accident. Indexed but never seen: that's the ranking gate, not an indexing problem; compete on the queries within reach. And if the whole site under-indexes despite good content: check what crawlers actually receive. Client-side rendering is the classic invisible failure, fine in a browser and empty to a bot, and doubly costly because AI crawlers won't render it at all. Rampify flags it on Home when it detects it. ## AI Visibility URL: https://www.rampify.dev/docs/ai-visibility AI Visibility AI visibility is whether AI assistants can reach and read your site at all. It's the technical foundation beneath Answer Engine Optimization (AEO), sometimes called Generative Engine Optimization (GEO). Before an AI can cite, summarize, or recommend you, it has to be able to fetch and read your pages . Many modern sites quietly fail this first step while looking perfect to human visitors. The problem: AI crawlers don't run JavaScript When a person visits your site, their browser downloads your HTML, runs your JavaScript, and paints the page. AI crawlers mostly skip that last part. ChatGPT, Claude, Perplexity, Google's AI Overviews, and the link-preview bots behind Slack, iMessage, and social platforms fetch your page over plain HTTP and read the HTML the server returns , before any JavaScript runs. If your content only appears after JavaScript executes in a browser, those crawlers receive an empty shell. Your page works flawlessly for humans and is invisible to the machines that increasingly decide what gets recommended. Running a full browser for every page is slow, expensive, and unreliable at web scale. So most crawlers, including Googlebot for its first pass, read the server's HTML response first. Server-rendered content is what gets read, indexed, and cited reliably. JavaScript-only content is a coin flip. How to think about it: three gates A page is AI-visible only when it clears three independent gates . Fail any one and the page is effectively invisible, no matter how good the content is. in the server HTML' }, ], }} newWay={{ title: 'Visible to AI', items: [ { label: 'Real content in the initial HTML response' }, { label: 'Citation crawlers allowed in robots.txt' }, { label: 'Sitemap present, pages well linked' }, { label: 'Headings and text readable without JavaScript' }, ], }} / 1. Discoverable: can a crawler find your URLs? (a sitemap, clean internal links) 2. Allowed: does your robots.txt permit the crawlers that cite you? 3. Readable: does the server return real content, or an empty shell that needs JavaScript? The gates are independent: a perfectly readable site that blocks AI crawlers in robots.txt is invisible, and a site that allows every crawler but ships an empty shell is invisible. You need all three. If these gates feel familiar, they should: classic search runs the same discover → fetch → read pipeline before anything can rank. Search Engine Indexing covers that shared foundation, and why the same hygiene work pays on both surfaces at once. Client-side rendering: the readable gate The readable gate is where modern stacks most often fail, so it's worth understanding in depth, especially when you're choosing a stack. A single-page app (SPA) built with a client-rendering setup (Create React App, Vite + React or Vue, and similar) ships a near-empty HTML document: a and a JavaScript bundle. The browser fills in the content by running that bundle. A crawler that doesn't run the bundle sees exactly that empty and nothing else. Open your homepage, right-click → View Page Source (Ctrl+U on Windows/Linux, ⌥⌘U on Mac), and read the raw HTML, which is exactly what an AI crawler receives. - Server-rendered: you'll see your headings, paragraphs, and links in the HTML. - Client-rendered: you'll see an empty and a bundle, with none of your text. Use View Page Source (the server's response), not Inspect (the live DOM after JavaScript runs). On a client-rendered site they differ, and the crawler only ever gets the former. Titles and meta may still be read A nuance worth knowing: many SPAs still set the and meta tags server-side (or via the host), so a crawler may read those even when the body is empty. That's why a client-rendered site can look half there to AI: it knows your page exists and what it's called , but not what it says . For being cited and summarized, the body is what counts. This is a stack-selection decision If you're building a marketing site, docs, or any content you want discovered, choose a stack that renders on the server from the start: - Astro: excellent for content and marketing sites; ships static HTML by default. - Next.js (App Router): server components return real HTML, which is great when the same project also needs marketing surfaces. - Other SSR/SSG frameworks (Remix, SvelteKit, Nuxt, Hugo) work well too. If you already have a client-rendered app, you don't have to rewrite it, but the pages you want AI to read should be server-rendered or statically generated. A common, healthy pattern: keep the app client-rendered, and build the marketing and content site on a server-rendered stack alongside it. There's no tag or robots directive that makes a client-rendered page readable. The content has to exist in the server's HTML response, a build and architecture choice, which is exactly why it's worth getting right early. Crawler access: the allowed gate Even a perfectly readable site is invisible if its robots.txt turns the crawlers away. Two kinds are worth separating: - Citation crawlers (OAI-SearchBot, ChatGPT-User, PerplexityBot, Claude-User, Googlebot, Bingbot, and friends) fetch pages to answer questions and cite sources . Blocking these means you can't be surfaced in AI answers, which is rarely what you want. - Training crawlers (GPTBot, ClaudeBot, CCBot, Google-Extended, and friends) collect data to train models . Allowing or denying them is a legitimate preference, entirely separate from whether you can be cited. The common footgun is a leftover User-agent: / Disallow: / (often from a staging config) that blocks everyone . If you want to be cited, allow the citation crawlers; training is your call. Allowing them only gets you into the running, though. Whether AI actually cites you is your AI answer presence. Discoverability: the discoverable gate Finally, crawlers have to find your URLs. A sitemap.xml (plus clean internal linking) is how they enumerate your pages. Missing a sitemap isn't fatal, since crawlers can follow links, but it's the cheapest way to make sure nothing important gets overlooked. How Rampify surfaces this When Rampify crawls your site, it checks all three gates the same way an AI crawler would, over plain HTTP without running JavaScript, and reports the result on your project's Website page as an AI Visibility card: - Readable: Rampify classifies each site's render mode (server-rendered vs client-rendered) from the homepage's server HTML. - Allowed: it parses robots.txt against a known list of citation vs training crawlers. - Discoverable: it checks for a sitemap during the crawl. When a site is client-rendered, Rampify raises a high-priority finding, your site is invisible to AI crawlers , with the page-source self-check and remediation above, instead of burying you in per-page SEO issues that don't matter until the page is readable in the first place. Beyond visibility: AI Answer Presence Being readable is necessary but not sufficient . Once AI can read you, the next question is whether it actually cites and recommends you, your AI Answer Presence . That's the outcome side (mentions, citations, recommendations), covered on its own page. This page is about the foundation: clearing the gates so you're in the running at all. Once they're clear, a Category Visibility session from the Discovery Optimization guide measures whether the answer engines actually name you. and a script bundle with none of your content, you\'re client-rendered. Note that Inspect / DevTools shows the post-JavaScript DOM, which hides the problem, so use View Page Source, which shows the server\'s raw response.', }, ]} / ## AI Answer Presence URL: https://www.rampify.dev/docs/ai-answer-presence AI Answer Presence AI answer presence is whether AI assistants actually surface you , naming you, citing you as a source, or recommending you when someone asks a question you should be the answer to. It's the outcome side of Answer Engine Optimization (AEO), the counterpart to AI Visibility, which is whether AI can reach and read you at all. Visibility is necessary, not sufficient AI Visibility gets you into the running : AI crawlers can find, are allowed to fetch, and can actually read your pages. But being readable doesn't mean you get surfaced. An assistant still has to choose you , from everything it can read, as worth naming, citing, or recommending. That's the gap this page is about. On the AI Visibility page, citation crawlers are the bots that fetch your pages in order to cite sources. Whether they actually do cite you is your AI answer presence. Allowing the citation crawlers is table stakes; being cited is the result. The same layering exists in classic search: getting indexed puts you in the pool, and ranking decides whether anyone sees you. Presence is the AI-answer counterpart of that second step: same foundation, different scoreboard. Visibility: can AI reach and read you? (crawlers, robots, render mode). Presence: once it can, does it surface you? (mentions, citations, recommendations). You need the first to have any shot at the second, and the first alone guarantees nothing. The forms of presence "Presence" shows up in three forms. They overlap (you can have one without the others), but they roughly increase in value, and they differ sharply in how measurable they are. Form What it means Measurable? ------ --------------- ------------- Mention The assistant names your brand or product in its answer, with no link or attribution Hard (no signal to catch) Citation Your page is referenced as a source , usually with a link or named attribution Yes , it appears in the answer's sources and can drive AI-agent referral traffic Recommendation The assistant actively suggests you as the answer ("use X for this") The goal state (strongest, but not always linked) Citation is the backbone of everything below, because it's the form you can actually see and improve against. A mention leaves no trace, and a recommendation may arrive without a link. A citation is attributed and observable, which makes it the practical proxy for "are we present?" Being cited means the AI referenced you as a source. A referral or click is a person then following that link. You can be cited heavily and clicked rarely, because the citation already did its job: the answer carried your information and credited you. Track them as two different things, where citations measure presence and clicks measure downstream traffic. Why citation is the one to track You can't reliably observe every place an AI mentions your name, because assistants answer privately, billions of times, mostly without telling you. Citations are different. When an assistant cites a source, that attribution is visible in the answer, and the fetch that produced it, plus any human who follows the link, leaves a footprint you can capture. So citation is both the most valuable observable form of presence and the most trackable . It's the metric AEO is ultimately optimizing. How Rampify surfaces this Rampify's server-side tracker records AI-agent activity on your own site , the leading and lagging indicators of presence: - Crawler coverage (leading indicator): which AI crawlers actually fetch your pages, and how often. If the citation crawlers aren't visiting, citations can't follow; if they are, you're in the candidate pool. - AI-assistant referrals (lagging indicator): visits that arrive from an AI assistant, the downstream signal that a citation existed and someone acted on it. These live in your project's Discovery area, so you can watch presence as a trend rather than guess at it. Crawler coverage tells you you're readable and being fetched ; referrals tell you it's converting to real reach . How to earn presence Presence is earned in two layers, in order: 1. Be readable first. None of this matters if AI can't read you, so fix AI Visibility before anything else. A client-rendered site has zero presence by construction. 2. Be citation-worthy. Among everything an assistant can read, it cites the sources that best, and most credibly, answer the question: - Answer-shaped content: directly answer real questions, near the top, in plain language. Assistants cite the source that already contains the answer. - Specific, first-hand authority: original data, concrete numbers, and genuine expertise get cited, while generic aggregation gets skipped. - Clear structure and markup: clean headings and schema.org markup help an assistant parse and attribute you correctly. - Entity clarity: make it unambiguous who you are and what you do, so the assistant can identify you as the source worth naming. ## Spec-Driven Development URL: https://www.rampify.dev/docs/spec-driven-development Spec-Driven Development Spec-driven development is a methodology for AI-assisted software engineering where structured specifications drive the entire development lifecycle . Instead of describing features in chat and hoping for the best, you define specs with acceptance criteria, affected files, and implementation tasks. AI queries the spec, implements against it, and you verify the result. This is the professional alternative to vibe coding. Models come and go. Prompts are ephemeral. Specs persist across sessions, tools, and team members. Spec-driven development was previously explored as "context-driven development" (CDD), which focused on bringing deterministic context into the editor. Spec-driven development builds on that foundation with a concrete methodology: specs are the context . The Problem: AI Without Structure AI coding tools are fast. They generate code in seconds. But speed without direction creates a different kind of technical debt. The vibe coding loop: 1. Describe a feature in chat 2. AI generates code 3. It mostly works, but misses edge cases 4. Describe the fix in another chat message 5. AI patches it, breaks something else 6. Repeat until it seems right 7. Ship and hope The result: code that works but nobody understands why. No traceability from requirements to implementation. No way to verify completeness. Context is lost between sessions. A different AI (or teammate) starts from zero. The spec-driven loop: 1. Define a spec with acceptance criteria and tasks 2. AI queries the spec via MCP 3. AI implements against the spec, knowing exactly what to build and which files to touch 4. You commit, and the commit links back to the spec 5. Scan to verify the fix 6. Spec tracks what's done, what's left, and why decisions were made Why Specs, Not Prompts Prompts are instructions for a single moment. Specs are durable artifacts that persist: How It Works in Practice Manual specs: you define what to build You create a spec when you know what needs to happen. The spec includes a description, acceptance criteria, implementation tasks, affected files, and tech stack. Any AI coding tool can retrieve it via MCP and implement against it. "Get the feature spec for auth token expiration" AI: calls get feature spec() "Spec: Implement token expiration logic Acceptance criteria: 1. Tokens expire after 15 minutes 2. Refresh tokens last 7 days 3. Expired tokens return 401 Tasks: 1. Add expiration check in lib/auth.ts 2. Update verify endpoint 3. Add refresh token flow Affected files: lib/auth.ts, app/api/auth/verify/route.ts Starting with task 1..." Auto-generated specs: Rampify defines what to fix Run a scan, and Rampify analyzes your site for real issues. Each issue becomes a spec with affected URLs and fix instructions. No manual triage needed. After scan: - "Missing Canonical Tag" (4 URLs affected) - "Pages Missing Structured Data" (3 URLs affected) - "Meta Description Too Short" (2 URLs affected) Each is a spec your AI can pick up and fix immediately. The verification loop After AI implements a fix, you don't just trust it. You scan again. Rampify re-crawls the affected URLs and checks whether the issues are resolved. If they are, the spec is automatically marked as verified. If not, it stays open with updated affected URLs. This closes the loop: define, implement, verify . No manual checking. No hoping it worked. Specs Are the Single Source of Truth In spec-driven development, the spec is the authority. Not the chat log. Not the PR description. Not someone's memory of what was discussed. A spec contains: - What to build (title, description) - Why it matters (context, business value) - How to verify it's done (acceptance criteria) - Where to implement it (affected files, tech stack) - What's next (ordered tasks with dependencies) - What happened (linked commits, progress tracking) When a new developer joins the project, when you switch AI tools, when you resume work after a week, the spec has everything. No context reconstruction needed. AI as Interface, Data as Truth Spec-driven development draws a clear line between what AI should do and what deterministic systems should do: AI is a powerful interface. But it should operate on top of structured data, not instead of it. Beyond SEO Spec-driven development is a general methodology. Rampify currently implements it for SEO, where the scan-to-spec pipeline creates specs from real site issues. But the same pattern applies to any domain: - Accessibility - scan for WCAG violations, create specs with affected components - Security - scan for vulnerabilities, create specs with remediation steps - Performance - scan for Core Web Vitals issues, create specs with optimization targets The architecture is the same: deterministic scan produces structured findings, findings become specs, AI implements against specs, scan verifies the fix. Getting Started The fastest way to try spec-driven development: 1. Sign up at rampify.dev 2. Install the VS Code extension from the marketplace 3. Set up the MCP server so your AI tools can query specs directly 4. Run a scan to auto-generate your first specs from real site issues 5. Pick a spec and tell your AI to implement it Or create a spec manually and watch your AI build to spec instead of building to vibes. ## Dashboard URL: https://www.rampify.dev/docs/dashboard The Dashboard is the one screen above your projects: every project you have access to, in one list, each a door into its own workspace. Every project at a glance Each project is a separate workspace with its own site, crawl history, keywords, specs, and connections. The Dashboard lists them all, whether you run one site or a portfolio, and is where new projects are created. Step into a project Opening a project lands you on its Home (launch progress and growth at a glance), with the rest of the tools in the project sidebar. Everything from here down is scoped to that one project. MCP connections are project-scoped too: when you connect via OAuth you pick one project, and tools operate on it alone. See Connecting for switching projects. Everything above is also reachable over MCP: same data, no dashboard tab. ## Home URL: https://www.rampify.dev/docs/dashboard/home Home is where you read your project's momentum: how far your launch has progressed, and whether the last twelve months of work are showing up in Google. Track your launch phase by phase The launch progression is the spine of the page. Every project moves through the same phases, from first crawl to steady growth, and each phase breaks into concrete steps with its own progress. The current phase is highlighted, so the answer to "where are we?" is always one glance. Phases advance from real signals (crawls completing, GSC connecting, pages indexing), not from checking boxes. If a phase looks stuck, the step list tells you exactly what's missing. Read twelve months of growth Below the progression, Home charts your project's trajectory, including indexed pages over time , reconstructed from Google's own URL inspection log. It's the same canonical series the Presence suite uses, so the number you see here never disagrees with the one you see there. Every tier gets the full twelve months of its own history. Plan depth affects the Presence suite, not your past. Catch rendering problems early If Rampify detects that your site is client-rendered (meaning search engines and AI crawlers may see an empty shell instead of your content), a diagnosis card appears at the top of Home with what was detected and what to do about it. Dismiss it once you've addressed it (or accepted the tradeoff). Everything above is also reachable over MCP: same data, no dashboard tab. The toolbar's MCP handoff on this page pre-fills the project context for you. ## Specs URL: https://www.rampify.dev/docs/dashboard/specs Specs turns SEO findings into work your AI coding tool can actually implement. Every improvement becomes a feature specification, with tasks, acceptance criteria, and a commit trail, instead of a bullet in a report nobody executes. Capture work as specs Specs arrive two ways: you write them with New Spec , or Rampify files them for you: every site crawl that detects issues creates specs describing the fix. Filter the list by status or tag to keep planned, in-progress, and completed work separated. Hand a spec to your AI The point of a spec is that you don't implement it by hand. The MCP handoff in the toolbar gives you a paste-ready prompt; your coding tool pulls the spec over MCP and works it task by task. From the Specs toolbar; it carries the project context with it. The AI fetches the spec with get feature spec and sees the same tasks and criteria you do. As the AI marks tasks complete and links commits, the dashboard updates, with no copy-paste status meetings. Trace specs to commits Tasks and acceptance criteria live on the spec; commits link back to both. Your AI can generate a conventional-commits message straight from spec context, so six months later git log still explains why a change happened. Everything above is also reachable over MCP: same data, no dashboard tab. The toolbar's MCP handoff on this page pre-fills the project context for you. ## Discovery URL: https://www.rampify.dev/docs/dashboard/discovery Discovery answers the question your analytics can't: what does your category look like to AI models, and where are you missing? It runs structured research sessions that turn AI conversations into findings you can act on. Run research from a template Each template is a packaged research method (a Category Visibility Check, a Market Opportunity scan) that directs your AI through a multi-step session instead of one shallow conversation. The Discovery Optimization guide walks through each methodology: what it measures, how to read the results, and what to do about the gaps it finds. Templates unlock as your Business Profile fills in: Market Opportunity, for example, needs your category phrase to know what to research. Locked templates stay visible and tell you exactly which profile detail unlocks them. Discovery runs in conversational AI surfaces (claude.ai or Claude Desktop) where long research sessions are natural. The dashboard is where sessions are launched from and where results land. Review sessions over time Every session is kept with its status and structured output. Skim summaries in the session list, or open one for the full per-query responses when you want to see the evidence behind a finding. Turn findings into keyword clusters Research that ends as a document is research that gets forgotten. After a session, derive keyword clusters straight from the findings, pre-grouped with live volume data, and they land in Keywords ready to drive content. Everything above is also reachable over MCP: same data, no dashboard tab. The toolbar's MCP handoff on this page pre-fills the project context for you. Discovery also has a family of agent-invoked bookkeeping tools ( discovery submit ) the AI calls mid-session; you never invoke them directly. They're documented under MCP Tools. ## Website URL: https://www.rampify.dev/docs/dashboard/website Website is the canonical map of every URL Rampify knows about: what's healthy, what's broken, what Google thinks of each page, and whether AI crawlers can even get in. When something on your site costs you visibility, this is where it surfaces. Crawl and audit your site Analyze Site crawls your pages the way a search engine would and records what it finds per URL: HTTP status, redirect chains, titles, meta descriptions, schema markup, and sitemap membership. Progress streams live; results land in the URL table the moment the crawl finishes. Discovery starts from your sitemap ( /sitemap.xml , sitemap indexes, and robots.txt directives are all checked) and falls back to following your navigation when no sitemap exists. A sitemap is worth having: it's faster, more complete, and tells Rampify (and Google) exactly which pages you consider yours. Work the issues list Everything the crawl flags becomes an issue with a severity ( critical , warning , medium , info ) attached to the page it lives on. Issues don't stop at detection: crawls file Specs describing the fix, so the path from "found" to "shipped" is already paved. See what Google sees, per page With Google Search Console connected, every URL row also carries Google's own verdict: indexing state, coverage, canonical choice, last crawl time, plus 28-day clicks, impressions, and average position. One table answers both "is this page healthy?" and "is it earning anything?" Check AI crawler access The AI visibility card reads your robots.txt and reports which AI crawlers can reach your site. If you're blocking the crawlers that feed AI answers, you'll see it here before you wonder why you're invisible. Scheduled crawls in Project Settings keep this picture fresh without anyone remembering to press the button. Everything above is also reachable over MCP: same data, no dashboard tab. The toolbar's MCP handoff on this page pre-fills the project context for you. ## Keywords URL: https://www.rampify.dev/docs/dashboard/keywords Keywords organizes what you want to rank for into clusters: keyword groups with live volume data, tied to the pages that should win them. It's the bridge between research and a content plan. Build clusters that mirror intent A cluster is a group of keywords that one page can plausibly own. Create them by hand, or let Discovery derive them from research findings with volume data already attached. Comparison-stage clusters ("X vs Y", "best X for…") get dramatically richer when your Business Profile lists competitors. Without them, comparison keywords fall back to generic patterns. Research before you commit Look up search volume, competition, and trend for any candidate before it earns a slot, and expand from a seed keyword to the related terms you haven't thought of yet. Tracking keywords nobody searches is the most common way keyword lists rot. Keep the list honest Keywords carry a tier (how much you care), a cluster, and a target URL. As strategy shifts, retier and reassign rather than letting the list drift, and remove keywords that stopped mattering. Removals are soft-deletes, so history survives. Everything above is also reachable over MCP: same data, no dashboard tab. The toolbar's MCP handoff on this page pre-fills the project context for you. ## Google Search URL: https://www.rampify.dev/docs/dashboard/google-search Google Search is your Search Console property made legible: connection health, sync freshness, and performance you can read by page or by query, without the GSC interface's sixteen clicks. Connect once, stay synced Connect your GSC property and Rampify keeps it synced, pulling queries, impressions, and indexing data on a schedule. The last refreshed line reflects the full sync-and-evaluate chain, so "fresh" means the analysis is fresh, not just the download. Read performance by page and query The Overview tab gives the headline stats over your chosen window; Queries shows the actual searches you appear for. The same per-page data also flows into Website, where it sits next to each URL's crawl health. Find the queries within reach The highest-leverage SEO work is usually a query where you already rank on page two, or rank well but earn no clicks. Those ranking and CTR opportunities are exactly what the performance data surfaces, and what your AI can act on with the rest of the toolkit. Everything above is also reachable over MCP: same data, no dashboard tab. The toolbar's MCP handoff on this page pre-fills the project context for you. ## Business Profile URL: https://www.rampify.dev/docs/dashboard/business-profile The Business Profile is the context layer everything else reads: who you are, who you serve, what category you compete in, and against whom. The richer it is, the smarter every other tool (and your AI) gets. Complete the profile in phases The profile tracks a completeness score and breaks the work into phases (positioning, audience, competitors), each with its own status. You don't need all of it on day one; you need to know what's missing and what it's costing you. Know what completeness unlocks Market Opportunity and other Discovery templates that need to know your category ], ['Competitors', 'Comparison-stage keyword clusters with real rival names instead of generic patterns'], ['Audience & positioning', 'Sharper Discovery prompts and content briefs grounded in who you actually serve'], ]} / See what context changes The same generate meta call, before and after the profile knows who you are. Without context: Title: Project Management Software YourCompany Description: Manage your projects efficiently with our project management software. With audience, differentiators, and voice filled in: Title: Real-Time Dev Collaboration 50% Faster YourCompany Description: Built for developers: API-first project management with real-time sync. Ship features faster with Git integration, webhooks, and CLI tools. The difference isn't a smarter model; it's that the profile told the AI the audience is developers, the differentiator is real-time speed, and the voice is technical but approachable. Every generation, recommendation, and research prompt reads the same context. Let your AI do the filling-in The fastest way to a complete profile isn't typing into forms; it's a conversation. Ask your AI to enrich the profile and it will read your site, propose positioning fields, and write them back. Competitor research works the same way: candidates found by keyword overlap and homepage analysis, saved to the profile when you approve. Specific beats vague, in every field. "Full-stack developers at Series A startups" gives your AI something to aim at; "technical professionals" doesn't. Write fields in your customers' language, not internal jargon. Everything above is also reachable over MCP: same data, no dashboard tab. The toolbar's MCP handoff on this page pre-fills the project context for you. ## Products URL: https://www.rampify.dev/docs/dashboard/products Products names the things this project actually markets. Every project has a default product; sub-products let each offering carry its own category, one-liner, and positioning, so research and keywords can target the right thing. One project, many offerings A site that sells three things shouldn't be profiled as one blur. Each product carries its own category phrase and one-liner , and moves through its own bootstrap phases. Discovery sessions and keyword clusters can then anchor to a specific product instead of the brand average. Create and edit in place Products are created and edited inline on the page. How many you can add is set by your plan tier; at the cap, the create button becomes an upgrade prompt rather than silently failing. The default product can't be deleted; it is the project's baseline identity. Sub-products can come and go as your catalog changes. Everything above is also reachable over MCP: same data, no dashboard tab. The toolbar's MCP handoff on this page pre-fills the project context for you. ## Project Settings URL: https://www.rampify.dev/docs/dashboard/settings Project Settings is the project's control panel: identity, API keys, tool connections, and automation. You'll visit rarely, but when you do, it's because something here unblocks everything else. Manage project identity Rename the project, update the contact, change the logo treatment. The project's domain is editable too, but once a crawl has run, changes are guarded, because crawl history, GSC data, and issues are all anchored to it. Keys and connections Project API keys live here, alongside the one-click MCP install picker for connecting your AI tools (the same picker from the setup wizard). GitHub and Conductor connections, for running agents against your repo and worktrees, appear here as they roll out. API keys are project-scoped credentials. Treat them like passwords: rotate anything that's been pasted somewhere it shouldn't have been. Automate the routine Scheduled crawls keep the Website picture fresh without anyone remembering to press the button; issues and specs file themselves as your site changes. Settings is deliberately dashboard-only : keys and connections are credentials, and credentials don't belong in an AI conversation. Nothing here is exposed over MCP. ## Agent Orchestration URL: https://www.rampify.dev/docs/integrations/agent-orchestration Agent Orchestration Tools like Conductor, Cursor, Emdash, and Sculptor , the new agentic development environments, run coding agents in parallel, each in its own isolated git worktree or container. Connect Rampify and those same agents can do your marketing and SEO: research keywords, ship optimized pages, fix issues. This page covers the orchestration-specific setup. Start with the Connecting page, which covers connecting Rampify via OAuth and the one-click picker. This page assumes that's done and focuses on running Rampify across parallel agents and multiple projects . How it fits Your orchestrator runs the agents and keeps them isolated. Rampify gives each agent its marketing toolkit (over MCP) and the spec to work on. Whatever the orchestrator drives (Claude Code, Codex, or a tool's own model like Cursor's Composer), Rampify connects through MCP, so its tools show up inside it. For the bigger picture on why you'd point coding agents at marketing, see Marketing & SEO for parallel coding agents. --- Conductor Conductor runs coding agents in parallel git worktrees on macOS. Rampify plugs in two ways. Open in Conductor Every spec in Rampify has an Open in Conductor button. One click opens a new Conductor workspace in the right repo with the task prompt already in the chat, pre-filled and ready to send. Set it up once per machine: in your project's Settings → Connect Conductor , paste the local path to that repo. The path is stored in your browser only, so you set it once on each machine you use. Open in Conductor is in beta. If you don't see Connect Conductor in your project Settings yet, ask us to enable it, or use the inherited-MCP setup below, which works everywhere today. Inherited MCP Conductor reads a repository's MCP config from its project root: If a repository has an .mcp.json file at its project root, Conductor agents in that workspace inherit those MCP servers. So if you add Rampify to a repo's .mcp.json , every agent Conductor runs in that repo's workspaces gets Rampify's tools automatically. The one catch (keeping that file out of git while still delivering it to every workspace) is the worktree pattern below. --- Connect the agent your orchestrator runs If you connected Rampify through the OAuth picker, you're already done: skip to the worktree pattern. To wire it in by config (required for the worktree pattern, or for tools without OAuth), here's the per-tool setup. The Rampify MCP endpoint is https://www.rampify.dev/api/mcp . Use a project-scoped API key (create one in your project's Settings → API keys ) so the agent is bound to exactly one Rampify project (see Multiple projects). Claude Code The agent most orchestrators drive. Add it via the CLI: claude mcp add --transport http rampify https://www.rampify.dev/api/mcp Or as a project-root .mcp.json (this is the file Conductor inherits): { "mcpServers": { "rampify": { "type": "http", "url": "https://www.rampify.dev/api/mcp", "headers": { "Authorization": "Bearer sk live your project key" } } } } Cursor Add to .cursor/mcp.json (project) or ~/.cursor/mcp.json (global): { "mcpServers": { "rampify": { "url": "https://www.rampify.dev/api/mcp", "headers": { "Authorization": "Bearer sk live your project key" } } } } Codex Edit ~/.codex/config.toml (or a project-level .codex/config.toml ): [mcp servers.rampify] url = "https://www.rampify.dev/api/mcp" bearer token env var = "RAMPIFY API KEY" Codex reads the bearer token from the named environment variable, so export RAMPIFY API KEY with your project-scoped key. Other tools Antigravity, Sourcegraph Amp, and other MCP-capable agents connect the same way: add Rampify's HTTP endpoint ( https://www.rampify.dev/api/mcp ) as an external MCP server using their configuration. See each tool's MCP docs for the exact format. --- One setup for every workspace Conductor and other worktree-based tools create a fresh git worktree per workspace. Git worktrees don't copy gitignored files , so a .mcp.json holding your API key (which you should gitignore) won't be in new workspaces by default. Two steps fix it: 1. Put Rampify in the repo's .mcp.json with a project-scoped key , and gitignore the file so the key never lands in git history. 2. Add .mcp.json to a .worktreeinclude file at the repo root so Conductor copies it into every new workspace: # .worktreeinclude — files Conductor copies into each new workspace .env .env. .mcp.json .worktreeinclude uses .gitignore syntax; you can also configure this in Conductor under Settings → (your repo) → Files to copy . Now every parallel workspace inherits Rampify, scoped to the right project, with no per-workspace sign-in. Never commit a file containing an sk live ... key. Keep .mcp.json gitignored; .worktreeinclude delivers it to each workspace without it ever entering git history. OAuth vs. a project-scoped key Both work; pick by workflow: - OAuth (the one-click picker) is simplest for a single, interactive setup on one machine. - A static project-scoped key in .mcp.json is more robust for parallel worktrees, automation, and agencies. It avoids re-authenticating in every new workspace and removes the chance of picking the wrong project. --- Multiple projects Rampify scopes all data by project, and a project-scoped key binds an agent to exactly one Rampify project . That maps cleanly onto how you already organize repos: - One repo → one Rampify project. Put that project's scoped key in the repo's .mcp.json . Every Conductor workspace for that repo, however many agents you run in parallel, operates on the right project. - An agency with many client repos gets many Rampify projects that never cross wires: each repo carries its own client's key, so an agent working Client A's repo can't touch Client B's data, even running side by side. To check which project a connection is bound to, ask the agent to run the list projects tool. --- No MCP? Copy the prompt Using a tool we haven't covered, or not using MCP at all? Every spec in Rampify has a copy-ready prompt : paste it into any agent and it loads the spec and picks up the current task. No setup required, works with anything. --- ## VS Code Extension URL: https://www.rampify.dev/docs/integrations/vscode-extension VS Code Extension The Rampify extension brings spec-driven development into VS Code and Cursor. Browse your feature specs, set up MCP in one click, and copy spec context directly into AI chat. The extension is compatible with both VS Code and Cursor. Install it from the Extensions panel in either editor. Installation From the Extensions panel: 1. Open VS Code or Cursor 2. Go to Extensions ( Cmd+Shift+X / Ctrl+Shift+X ) 3. Search for "Rampify" 4. Click Install From the command line: code --install-extension rampify.rampify Or install from the VS Code Marketplace. --- Getting Started 1. Set your API key 1. Open Command Palette ( Cmd+Shift+P / Ctrl+Shift+P ) 2. Run Rampify: Set API Key 3. Enter your key from rampify.dev/settings/api-keys 2. Link your project 1. Open Command Palette 2. Run Rampify: Setup Project Link 3. Select your project or create a new one 3. Set up MCP (optional) 1. Open Command Palette 2. Run Rampify: Set Up MCP Server 3. Select your editor, and the wizard handles the rest Once connected, your AI coding tools can query specs, run scans, and generate fixes directly. --- Features Specs sidebar Browse all feature specs grouped by status: Planned, In Progress, Completed. Each spec shows priority, progress, and affected files. Click to open in the Rampify dashboard. Toggle resolved specs on/off to keep the sidebar focused. Auto-generated specs from scans Rampify scans your site and creates specs for issues it finds: missing structured data, broken meta tags, canonical tag problems. Each spec includes affected URLs and fix instructions your AI can act on immediately. One-click AI context Copy a spec reference into Claude or Cursor with a single click. Your AI retrieves the full spec (title, description, acceptance criteria, tasks, affected files, tech stack) and implements against it. MCP server setup wizard Set up the Rampify MCP server in one command. The built-in wizard supports Claude Code, Cursor, and Windsurf with automatic configuration. Commit tracking After committing a fix, link the commit SHA back to the spec for full traceability: code - commit - task - spec - requirement. --- Commands Command Description --------- ------------- Setup Project Link Link this workspace to a Rampify project Set API Key Configure your Rampify API key Set Up MCP Server Install MCP server for Claude Code, Cursor, or Windsurf Refresh Feature Specs Re-fetch specs from Rampify Toggle Resolved Specs Show/hide Completed, Verified, and Deprecated sections Copy Feature Spec Reference Copy spec ID for pasting into AI chat Open Feature Spec in Browser Open spec detail in the Rampify dashboard Switch Environment Switch between production and local API --- Configuration The extension works out of the box after setting your API key and linking a project. Optional settings: Setting Description Default --------- ------------- --------- rampify.apiKey Your Rampify API key None rampify.environment API environment ( production or local ) production rampify.localApiUrl Local API URL for development http://localhost:3000 rampify.clientId Project client ID (set via Setup Project Link) None rampify.domain Project domain (auto-detected) None --- Requirements - A free Rampify account - VS Code or Cursor --- Related ## Server-side Tracker URL: https://www.rampify.dev/docs/server-side-tracker Server-side tracker The Rampify JS tracker fires when a browser executes JavaScript, which catches every human visitor. But LLM agents (ChatGPT-User, Claude-User, Perplexity-User), training crawlers (Bytespider, GPTBot, anthropic-ai), and search/bot crawlers (Googlebot, Bingbot) all fetch server-side. They never run JavaScript. The standard tracker can't see them. Every analytics product on the market has this gap: Plausible, GA4, Umami, PostHog, Fathom are all JS-only. As AI search becomes the dominant content-consumption surface, JS-only analytics are blind to half the traffic story. The Rampify server-side tracker fills that gap. Drop a single file into your Netlify or Vercel project, set one env var, and every bot/agent request gets classified and recorded, without changing what your site does for human visitors. Open your project's Settings page in the Rampify dashboard (left sidebar → Settings). The "Project API Key" panel generates the key you'll need for the steps below. The same key works for both the server-side tracker and the MCP server. How it works The template installs as an edge function : a small piece of code that runs on every request to your site, before reaching your origin. It does three things: 1. Skip non-trackable requests (assets, API paths, framework internals, anything but GET). The AI-readable site maps and crawler directives, llms.txt , llms-full.txt , robots.txt , and sitemap.xml , are deliberately kept, so you can see when LLMs and crawlers fetch them. 2. Check the User-Agent header. If it matches a known bot/agent/crawler pattern, prepare a payload. 3. Fire-and-forget POST the payload to https://www.rampify.dev/api/collect with your project's API key. Then immediately return control to your site, so the request to Rampify never blocks your page render. If anything fails (missing API key, network error, Rampify is down) the function falls through silently. Your site continues to render exactly as it did before. There is no failure mode where the tracker breaks your site. Audit the code before you install The template is intentionally short (~120 lines, self-contained, no hidden imports). Read it before you deploy: - netlify-edge-tracker.ts (Netlify version) - vercel-proxy.ts (Vercel version) What this code sends to Rampify For every request that matches a known bot/agent/crawler User-Agent : - URL the bot requested (path + query string) - Referrer header (if present) - User-Agent string verbatim - Country and region code (pre-resolved by your platform's edge, e.g. US / CA ) - Accept-Language value (first locale only) That's it. The payload is one JSON POST, fire-and-forget, never blocks your origin. What this code never does - No visitor IPs leave your edge. Country and region are resolved by Netlify or Vercel before the function runs; we only receive the codes. - No cookies, no localStorage , no fingerprint hashing. No identifier is set on the visitor. - No JavaScript injected into your pages. This runs server-side only. - No data on human visitors. The User-Agent regex filters to bots/agents/crawlers, so humans pass straight through to your origin and are tracked (if at all) by your existing JS analytics. - No requests modified. The function calls next() with the original request unchanged. Your origin sees exactly what it saw before. You'll want to disclose server-side analytics on bots in your privacy policy regardless, as that's standard. But the data Rampify receives contains no PII, so you don't have a new compliance surface. Install on Netlify The template uses Netlify Edge Functions (Deno runtime, free tier 1M invocations/month). 1. Generate an API key In the Rampify dashboard, open Settings for your project and click Generate key in the Project API Key panel. Copy the sk live … value, which you'll only see once. 2. Set the environment variable In Netlify → Site configuration → Environment variables, add: RAMPIFY API KEY=sk live … (paste your key here) 3. Add the edge function From your project root: mkdir -p netlify/edge-functions && \ curl -o netlify/edge-functions/rampify.ts \ https://www.rampify.dev/api/templates/netlify-edge-tracker.ts 4. Wire it up in netlify.toml [[edge functions]] path = "/ " function = "rampify" 5. Deploy Push to your repo. Netlify auto-deploys the edge function. Back in Rampify Settings, the Server-side tracker traffic panel will transition from "Waiting for first event…" to "N events in last 24h" once a bot or LLM agent visits your site. To force an immediate test, hit your site with a bot UA: curl -A 'Claude-User/1.0' https://your-domain.com/ You should see the event in the Rampify dashboard within seconds. Install on Vercel The template uses Next.js routing-middleware ( proxy.ts for Next.js 16+, middleware.ts for ≤15). 1. Generate an API key Same as Netlify: open Settings for your project and click Generate key in the Project API Key panel. 2. Set the environment variable In Vercel → Project settings → Environment Variables, add: RAMPIFY API KEY=sk live … (paste your key here) 3. Install the Vercel runtime helper npm install @vercel/functions 4. Drop the middleware at the project root For Next.js 16 or later: curl -o proxy.ts https://www.rampify.dev/api/templates/vercel-proxy.ts For Next.js 15 or earlier, save it as middleware.ts instead. (The exported function name middleware is what Next.js looks up; the filename varies by version.) 5. Deploy Push to your repo. Vercel auto-deploys the middleware. Back in Rampify Settings, the Server-side tracker traffic panel will transition once the first bot/agent request hits your site. What the dashboard shows after install The Server-side tracker traffic panel on your project's Settings page polls every 10 seconds and updates the status block: - "Waiting for first event…" means the function is deployed but no bot has visited yet, or the API key isn't reaching Rampify. - "N events in last 24h" means bot/LLM-agent traffic is flowing. Sample user-agents are listed below for sanity-checking. The full per-event breakdown (which bot, which page, when) lives on the existing Traffic dashboard. Filter by visitor type to see just LLM agents or just crawlers. Privacy The server-side tracker collects the same data the JS tracker does (URL path, referrer, user-agent, pre-resolved geo: country and subdivision code) and adds nothing else. Visitor IPs never reach Rampify. Geo is resolved at your platform's edge (Netlify and Vercel both expose it) and only the pre-resolved values are sent. Because the tracker runs server-side and isn't using cookies, fingerprinting, or third-party identifiers, the no-cookies posture from the JS tracker carries over. Your site's privacy policy should still disclose that you're running server-side analytics on bot/agent traffic , which is your responsibility, not Rampify's. Troubleshooting The status panel still says "Waiting for first event…" after I deploy. - Check that RAMPIFY API KEY is set on the deployed environment (not just local). - Hit your site with a bot UA: curl -A 'Claude-User/1.0' https://your-domain.com/ . If that produces an event, the tracker is working, and you just hadn't received any real bot traffic yet. - View your platform's edge function logs. The template logs [rampify] collect failed: on any non-2xx response from /api/collect . My site has noticeably higher latency after install. The template uses fire-and-forget, so the POST to Rampify never blocks the response. But every request now passes through the edge function before reaching your origin, which adds ~5–20ms even when the function is a no-op. If that's not acceptable, narrow the matcher in netlify.toml (Netlify) or config.matcher (Vercel) to only the routes you care about. Can I see what the template does before installing? Yes. Both templates are served as plain text: - netlify-edge-tracker.ts - vercel-proxy.ts The classifier patterns are inline at the top of each file, with no hidden imports and nothing magic. Audit before you deploy. ## Connecting URL: https://www.rampify.dev/docs/mcp/connecting Connecting Rampify hosts a remote MCP server. No packages to install, no API keys to manage: connect via OAuth, pick your project, and start querying. New tools appear instantly without version updates. What is MCP? The Model Context Protocol (MCP) is an open standard that lets AI assistants connect to external tools and data sources. When you connect Rampify via MCP, your AI can check SEO status, generate meta tags, analyze search performance, all from natural language prompts in your editor. See all available tools. Prerequisites - A Rampify account with at least one project Coding tools Pick your tool below to connect Rampify in one click (Cursor, VS Code) or copy a ready-to-paste command (Claude Code, Claude Desktop). Each picks up your account's OAuth on first connect. You'll see this same picker inside the app on every project page, where the "Then run this" prompts adapt to whatever page you're on. ↓ Try it: fully interactive, same picker as in the app. Claude UI Using Claude on the web (claude.ai) or Claude Desktop? Add Rampify as a connector through the UI. In Claude, go to Customize → Connectors , click the + icon and choose Add custom connector . Name it Rampify and enter https://www.rampify.dev/api/mcp as the URL. Click Add , then the Connect button that appears, and sign in to Rampify when prompted. Multiple projects When you connect via OAuth, you select which project to use. The connection is scoped to that project, so tools only operate on the data you chose. To switch projects, re-authenticate your MCP connection. The project picker will appear again and you can select a different project. You can also check which project is currently active: Use the list projects tool to show my projects Running agents in parallel across worktrees (Conductor, Cursor, Emdash)? See Agent Orchestration for project-scoped keys and the .worktreeinclude pattern that connects every workspace at once. FAQ Do I need an API key to connect Rampify? No. The Rampify MCP server uses OAuth. You connect, pick your project, and start querying. There are no API keys to create or manage. Which AI tools can connect to the Rampify MCP server? Any MCP-compatible client: Claude Code, Cursor, VS Code, Windsurf, Zed, Claude Desktop, and claude.ai. Do I need to install anything? No. Rampify hosts a remote MCP server, so there is nothing to install and new tools appear automatically with no version updates. How do I switch which project Rampify uses? Re-authenticate your MCP connection. The project picker appears again during sign-in and you can select a different project. Getting help Stuck on a connection step, or a tool not behaving the way this page says it should? Email support@rampify.dev and we'll get you unblocked. Already connected? The send feedback tool sends notes to the Rampify team straight from your AI tool, no email required. ## list_projects URL: https://www.rampify.dev/docs/mcp/list_projects List every Rampify project you can access and see which one is currently active. A read-only Rampify MCP tool for Claude Code, Cursor, and claude.ai. Takes no parameters; the project is resolved from the connection scope. ## crawl_site URL: https://www.rampify.dev/docs/mcp/crawl_site Crawl your live site to record URLs, detect SEO issues, and file feature specs that fix them. A Rampify MCP tool for Claude Code, Cursor, and claude.ai. Parameters: domain (string) — Site domain (optional override); project_id (string) — Project UUID (optional override) ## scan_page URL: https://www.rampify.dev/docs/mcp/scan_page Audit a single page's SEO and keyword usage against the live URL or content you paste in. A Rampify MCP tool for Claude Code, Cursor, and claude.ai. Parameters: url_path (string, required) — Page URL path (e.g., "/compare/ai-coding-tools"); content (string) — Page content (raw text or HTML) for pre-deploy audit. If omitted, fetches from the deployed URL.; domain (string) — Site domain (optional override); project_id (string) — Project UUID (optional override) ## get_page_intelligence URL: https://www.rampify.dev/docs/mcp/get_page_intelligence Pull every metric Rampify has for a single page — SEO, indexing, GSC, issues — in one call. A read-only Rampify MCP tool for Claude, Cursor, and claude.ai. Parameters: url_path (string, required) — Page URL path (e.g., "/", "/blog/my-post") or full URL.; domain (string) — Site domain (optional override); project_id (string) — Project UUID (optional override); period (enum("7d" | "30d" | "90d" | "all")) — Time window for traffic / conversions / AI-visibility data (default 30d). GSC search performance always uses the standardized lag-adjusted 28-day window so its impressions/clicks reconcile with get_search_performance and suggest_next_action.; include (enum("meta" | "summary" | "performance" | "traffic" | "conversions" | "ai_visibility" | "seo_health" | "content" | "feature_specs" | "campaigns" | "history")[]) — Sections to return. Default: all sections. ## get_issues URL: https://www.rampify.dev/docs/mcp/get_issues Get every detected SEO issue across your site with a prioritized health score. A read-only Rampify MCP tool for Claude Code, Cursor, and claude.ai. Parameters: domain (string) — Site domain; project_id (string) — Project UUID ## get_search_performance URL: https://www.rampify.dev/docs/mcp/get_search_performance See site-wide Google Search Console performance: top pages, queries, and ranking and CTR opportunities. A read-only Rampify MCP tool for Claude and Cursor. Parameters: domain (string) — Site domain; project_id (string) — Project UUID ## generate_meta URL: https://www.rampify.dev/docs/mcp/generate_meta Generate optimized title and meta-description tags for any page, grounded in its real content. A Rampify MCP tool for Claude Code, Cursor, and claude.ai. Parameters: domain (string) — Site domain; project_id (string) — Project UUID; url_path (string) — Page URL path. Optional when `content` is provided.; content (string) — Page content (text or HTML). When provided, takes precedence over stored meta.; current_title (string) — Explicit override for the existing title, used when content can't supply it.; current_description (string) — Explicit override for the existing meta description, used when content can't supply it. ## github_open_meta_pr URL: https://www.rampify.dev/docs/mcp/github_open_meta_pr Open a GitHub pull request that updates a page's title and meta description in MDX repos. A Rampify MCP tool for Claude Code, Cursor, and claude.ai. Parameters: domain (string) — Site domain; project_id (string) — Project UUID; url (string, required) — The full page URL (or path) whose meta to update; title (string) — New title. Provide title and/or description.; description (string) — New meta description. ## generate_title URL: https://www.rampify.dev/docs/mcp/generate_title Generate title-tag candidates for a page, each safety-verified against the source content. A Rampify MCP tool for Claude Code, Cursor, and claude.ai. Parameters: domain (string) — Site domain; project_id (string) — Project UUID; url_path (string) — Page URL path. Optional when `content` or `current_title` is provided.; content (string) — Page content (text or HTML). When provided, takes precedence over stored meta.; current_title (string) — Explicit override for the existing title, used as the must_retain baseline when content can't supply it.; must_include_keywords (string[]) — Keywords every candidate must contain. Defaults to the URL's primary target keyword when url_path is provided.; must_retain_keywords (string[]) — Keywords that cannot be dropped if present in the current title. Auto-populated from target keywords found in the current title if omitted.; min_length (number) — Minimum title length (default 30).; max_length (number) — Maximum title length (default 70).; brand_suffix (string) — Brand suffix to append, e.g. "| Rampify". Optional.; num_candidates (number) — Max candidates to return (default 5). ## generate_description URL: https://www.rampify.dev/docs/mcp/generate_description Generate meta-description candidates for a page, each safety-verified against the source content. A Rampify MCP tool for Claude and Cursor. Parameters: domain (string) — Site domain; project_id (string) — Project UUID; url_path (string) — Page URL path. Optional when `content` is provided.; content (string) — Page content (text or HTML). When provided, takes precedence over stored meta.; current_description (string) — Explicit override for the existing meta description, used as the must_retain baseline when content can't supply it.; must_include_keywords (string[]) — Keywords every candidate must contain. Defaults to the URL's primary target keyword when url_path is provided.; must_retain_keywords (string[]) — Keywords that cannot be dropped if present in the current description. Auto-populated from target keywords found in the current description if omitted.; min_length (number) — Minimum description length (default 110).; max_length (number) — Maximum description length (default 160 — SERP snippet fit).; num_candidates (number) — Max candidates to return (default 5). ## generate_schema URL: https://www.rampify.dev/docs/mcp/generate_schema Auto-generate valid schema.org JSON-LD markup for a page based on its type and content. A Rampify MCP tool for Claude Code, Cursor, and claude.ai. Parameters: domain (string) — Site domain; project_id (string) — Project UUID; url_path (string) — Page URL path. Optional when `content` is provided.; content (string) — Page content (text or HTML). When provided, takes precedence over stored meta and improves schema-type inference. ## optimize_content URL: https://www.rampify.dev/docs/mcp/optimize_content Scan a page and get specific, keyword-aware instructions for optimizing its content. A Rampify MCP tool for Claude Code, Cursor, and claude.ai. Parameters: url_id (string, required) — URL row ID. Used to look up the keyword cluster mapped to this page. Resolve via get_page_intelligence (returned at url.id).; content (string) — Page content (text or HTML). When provided, the audit runs against this content instead of fetching live — useful for pre-deploy drafts or content composed in conversation.; domain (string) — Site domain (optional override); project_id (string) — Project UUID (optional override) ## create_content_spec URL: https://www.rampify.dev/docs/mcp/create_content_spec Create a page-type content spec linked to a keyword cluster, ready for your AI to build. A Rampify MCP tool for Claude Code, Cursor, and claude.ai. Parameters: domain (string) — Site domain; project_id (string) — Project UUID; cluster_id (string, required) — The keyword cluster ID; title (string) — Custom spec title; description (string) — Content strategy overview; outline (string) — Proposed content outline; goals (string) — Goals — traffic, conversion, ranking targets; inspiration (string) — Reference links; voice_notes (string) — Voice and tone guidance; priority (enum("critical" | "high" | "normal" | "low")) — Spec priority ## create_keyword_cluster URL: https://www.rampify.dev/docs/mcp/create_keyword_cluster Create a keyword cluster from grouped keywords so one page can target them together. A Rampify MCP tool for Claude Code, Cursor, and claude.ai. Parameters: domain (string) — Site domain; project_id (string) — Project UUID; name (string, required) — Cluster name; description (string) — Strategic rationale; priority (enum("critical" | "high" | "normal" | "low")) — Cluster priority; competitive_landscape (string) — What currently ranks, competitors, positioning gaps; notes (string) — Free-form strategic notes; target_content_type (string) — Content type: blog_post, landing_page, guide, authority_page, tool_page, feature_page; target_url (string) — Proposed SEO-optimized URL path. Always propose a URL based on the primary keyword and content type.; keywords (string | object[]) — Keywords to assign. Accepts strings (default secondary) or {keyword, tier} objects. New keywords are auto-created.; primary_keyword (string) — The head term — set as primary tier. Others default to secondary. ## get_keyword_clusters URL: https://www.rampify.dev/docs/mcp/get_keyword_clusters Read your keyword clusters with live search-volume data and audit status. A read-only Rampify MCP tool for Claude Code, Cursor, and claude.ai. Parameters: domain (string) — Site domain; project_id (string) — Project UUID; target_url (string) — Filter by target URL path (e.g., "/" for homepage); name (string) — Filter by cluster name (partial match); cluster_id (string) — Filter by specific cluster ID ## lookup_keywords URL: https://www.rampify.dev/docs/mcp/lookup_keywords Look up live search volume, competition, and trend data for any keywords. A Rampify MCP tool for Claude Code, Cursor, and claude.ai. Parameters: domain (string) — Site domain; project_id (string) — Project UUID; keywords (string[], required) — Keywords to look up (max 100); locale (string) — Language locale (default: "en"); location_code (number) — Location code (default: 2840 = US) ## suggest_keywords URL: https://www.rampify.dev/docs/mcp/suggest_keywords Get related keyword suggestions expanded from a seed keyword you provide. A Rampify MCP tool for Claude Code, Cursor, and claude.ai. Parameters: domain (string) — Site domain; project_id (string) — Project UUID; seed (string, required) — Seed keyword; locale (string) — Language locale (default: "en"); location_code (number) — Location code (default: 2840 = US); limit (number) — Max suggestions (default: 50) ## update_keyword URL: https://www.rampify.dev/docs/mcp/update_keyword Update a tracked keyword's tier, cluster assignment, or target URL. A Rampify MCP tool for Claude Code, Cursor, and claude.ai. Parameters: domain (string) — Site domain (optional override); project_id (string) — Project UUID (optional override); keyword_id (string) — Single keyword UUID (alternative to keyword_ids); keyword_ids (string[]) — Multiple keyword UUIDs for batch update; tier (enum("primary" | "secondary" | "tertiary")) — New tier; cluster_id (string | null) — Target cluster ID; pass null to move to unclustered; target_url (string) — Target URL path ## remove_keyword URL: https://www.rampify.dev/docs/mcp/remove_keyword Soft-delete a tracked target keyword while preserving its history. A Rampify MCP tool for Claude Code, Cursor, and claude.ai. Parameters: domain (string) — Site domain (optional override); project_id (string) — Project UUID (optional override); keyword_id (string) — Single keyword UUID (alternative to keyword_ids); keyword_ids (string[]) — Multiple keyword UUIDs for batch removal ## create_feature_spec URL: https://www.rampify.dev/docs/mcp/create_feature_spec Create and save a feature specification to capture work the moment it surfaces. A Rampify MCP tool for Claude Code, Cursor, and claude.ai. Parameters: domain (string) — Site domain; project_id (string) — Project UUID; title (string, required) — Short, imperative title; description (string) — Full description (the what/why, not the how — use tasks for the how); feature_type (enum("new_feature" | "enhancement" | "refactor" | "bug_fix" | "optimization" | "page" | "positioning")) — Type of work this spec represents; priority (enum("critical" | "high" | "normal" | "low")) — Spec priority; status (enum("idea" | "planned" | "in_progress" | "completed" | "verified" | "deprecated")) — Initial status. Defaults to 'planned'. Use 'idea' for captured-but-not-committed work.; tags (string[]) — Freeform tags for grouping and filtering specs; tech_stack (string[]) — Technologies involved in the work; affected_files (string[]) — Files expected to change; ai_context_summary (string) — Short context summary for agents picking up the spec; next_action (string) — The immediate next step to take on this spec; tasks (object[]) — Implementation tasks. Break the spec into concrete steps. ## get_feature_spec URL: https://www.rampify.dev/docs/mcp/get_feature_spec Fetch one feature spec by ID with its full tasks, criteria, and commit history. A read-only Rampify MCP tool for Claude Code, Cursor, and claude.ai. Parameters: spec_id (string, required) — Spec UUID; include (enum("tasks" | "criteria" | "commits" | "description" | "ai_context_summary")[]) — Sections to include; omit to include all (back-compat). ## list_feature_specs URL: https://www.rampify.dev/docs/mcp/list_feature_specs Find feature specs by search, status, priority, or tags, with a fast summary-only mode. A read-only Rampify MCP tool for Claude and Cursor. Parameters: domain (string) — Site domain; project_id (string) — Project UUID; search (string) — Substring match on title and description (case-insensitive); status (string) — Comma-separated: idea,planned,in_progress,completed,verified,deprecated; priority (string) — Comma-separated: critical,high,normal,low; feature_type (string) — Comma-separated: new_feature,enhancement,refactor,bug_fix,optimization,page,positioning; tags (string) — Comma-separated; matches specs with any of these tags; assigned_to (string) — Filter to specs assigned to this user UUID; source (string) — user, system, seo_scan, security_scan, accessibility_scan; module (string) — seo, security, accessibility; limit (integer) — Max rows (default 50, max 200); offset (integer) — Skip this many rows (default 0). Pair with limit to paginate.; summary_only (boolean) — Return slim id/title/status/priority/next_action/tags shape ## update_feature_spec URL: https://www.rampify.dev/docs/mcp/update_feature_spec Update a feature spec's title, description, status, priority, or tags. A Rampify MCP tool for Claude Code, Cursor, and claude.ai. Parameters: spec_id (string, required) — Spec UUID; title (string) — Rewrite the spec title; description (string) — Replace the spec description / body; feature_type (enum("new_feature" | "enhancement" | "refactor" | "bug_fix" | "optimization" | "page" | "positioning")) — Type of work this spec represents; priority (enum("critical" | "high" | "normal" | "low")) — Spec priority; status (enum("idea" | "planned" | "in_progress" | "completed" | "verified" | "deprecated")) — New spec status; next_action (string) — The immediate next step to take on this spec; tags (string[]) — Replace the tags array; tech_stack (string[]) — Replace the tech_stack array; affected_files (string[]) — Replace the affected_files array; ai_context_summary (string) — Short context summary for agents picking up the spec; assigned_to (string | null) — User the spec is assigned to; null clears it; depends_on_specs (string[]) — Spec UUIDs this spec depends on. Validated against existing specs. ## create_spec_task URL: https://www.rampify.dev/docs/mcp/create_spec_task Add one or more tasks to a feature spec as the implementation plan takes shape. A Rampify MCP tool for Claude Code, Cursor, and claude.ai. Parameters: spec_id (string, required) — Spec UUID; task (object) — Single task to add; tasks (object[]) — Multiple tasks to add ## update_spec_task URL: https://www.rampify.dev/docs/mcp/update_spec_task Update a spec task's status or content, individually or as a batch. A Rampify MCP tool for Claude Code, Cursor, and claude.ai. Parameters: spec_id (string) — Spec UUID (resolved from task_id if omitted); task_id (string) — Task UUID for single update; status (enum("todo" | "in_progress" | "completed" | "blocked")) — New task status; title (string) — New task title (single mode); description (string) — New task description (single mode); task_type (enum("backend" | "frontend" | "database" | "testing" | "docs")) — Category of work (single mode); files_to_modify (string[]) — Files this task is expected to change (single mode); code_snippet (string) — Reference code snippet for the task (single mode); tasks (object[]) — Batch mode: multiple {task_id, status} pairs ## delete_spec_task URL: https://www.rampify.dev/docs/mcp/delete_spec_task Remove one or more tasks from a feature spec when the plan changes. A Rampify MCP tool for Claude Code, Cursor, and claude.ai. Parameters: spec_id (string) — Spec UUID (resolved from task_id if omitted); task_id (string) — Task UUID (single); task_ids (string[]) — Task UUIDs (batch) ## create_spec_criterion URL: https://www.rampify.dev/docs/mcp/create_spec_criterion Add an acceptance criterion to a feature spec to define when the work is done. A Rampify MCP tool for Claude Code, Cursor, and claude.ai. Parameters: spec_id (string, required) — Spec UUID; title (string, required) — Criterion title; description (string) — What the criterion verifies; criterion_type (enum("functional" | "technical" | "performance" | "security" | "accessibility")) — Default 'functional'; verification_method (enum("automated_test" | "manual_qa" | "code_review")) — Default 'manual_qa'; status (enum("pending" | "implemented" | "tested" | "verified")) — Criterion status; default 'pending' ## update_spec_criterion URL: https://www.rampify.dev/docs/mcp/update_spec_criterion Update an acceptance criterion on a feature spec as edge cases emerge. A Rampify MCP tool for Claude Code, Cursor, and claude.ai. Parameters: spec_id (string) — Spec UUID (resolved from criterion_id if omitted); criterion_id (string, required) — Criterion UUID; title (string) — New criterion title; description (string) — What the criterion verifies; criterion_type (enum("functional" | "technical" | "performance" | "security" | "accessibility")) — Criterion category; verification_method (enum("automated_test" | "manual_qa" | "code_review")) — How the criterion is verified; status (enum("pending" | "implemented" | "tested" | "verified")) — Criterion status ## delete_spec_criterion URL: https://www.rampify.dev/docs/mcp/delete_spec_criterion Remove an acceptance criterion from a feature spec when it no longer applies. A Rampify MCP tool for Claude Code, Cursor, and claude.ai. Parameters: spec_id (string) — Spec UUID (resolved from criterion_id if omitted); criterion_id (string, required) — Criterion UUID ## link_commit URL: https://www.rampify.dev/docs/mcp/link_commit Link a git commit SHA to the feature spec and task it implements, for full traceability. A Rampify MCP tool for Claude Code, Cursor, and claude.ai. Parameters: spec_id (string, required) — UUID of the feature spec to link the commit to; commit_sha (string, required) — Git commit SHA (from `git rev-parse HEAD`); task_id (string) — UUID of a specific task to link the commit to. Always pass when one task drove the commit.; repo_url (string) — Repository HTTPS URL (e.g., "https://github.com/owner/repo"); commit_message (string) — Full commit message body. When passed, Task: and Spec: trailers are parsed to auto-populate task_id and validate spec_id.; domain (string) — Site domain; project_id (string) — Project UUID ## get_commit_message URL: https://www.rampify.dev/docs/mcp/get_commit_message Generate a conventional-commits message from a feature spec's context. A read-only Rampify MCP tool for Claude Code, Cursor, and claude.ai. Parameters: spec_id (string, required) — UUID of the feature spec; task_id (string) — UUID of the specific task being completed. If omitted and exactly one task is in_progress, that task is auto-selected.; files_changed (string[]) — List of files changed in this commit; domain (string) — Site domain; project_id (string) — Project UUID ## list_campaigns URL: https://www.rampify.dev/docs/mcp/list_campaigns List your marketing campaigns along with their tracked links. A read-only Rampify MCP tool for Claude Code, Cursor, and claude.ai. Parameters: domain (string) — Site domain; project_id (string) — Project UUID; channel (string) — Filter by channel: social, email, newsletter, podcast, partner, paid, print, community, other; status (string) — Filter by status: active (default), archived; search (string) — Search by campaign name or source ## create_campaign URL: https://www.rampify.dev/docs/mcp/create_campaign Create a marketing campaign to track attribution for your content and links. A Rampify MCP tool for Claude Code, Cursor, and claude.ai. Parameters: domain (string) — Site domain; project_id (string) — Project UUID; channel (enum("social" | "email" | "newsletter" | "podcast" | "partner" | "paid" | "print" | "community" | "other"), required) — Marketing channel; source (string, required) — Traffic source (e.g., "linkedin", "reddit_saas", "mailchimp"); medium (string) — Medium (e.g., "post", "bio", "signature"); description (string) — Campaign description ## create_tracked_link URL: https://www.rampify.dev/docs/mcp/create_tracked_link Generate a tracked URL for a campaign so visits attribute back to it. A Rampify MCP tool for Claude Code, Cursor, and claude.ai. Parameters: campaign_id (string, required) — Campaign UUID; destination_path (string, required) — Page path on the site (e.g., "/pricing", "/blog/my-post"). Must match an existing crawled URL.; domain (string) — Site domain; project_id (string) — Project UUID ## save_campaign_content URL: https://www.rampify.dev/docs/mcp/save_campaign_content Save marketing content you created for a campaign so it's tracked with the rest. A Rampify MCP tool for Claude Code, Cursor, and claude.ai. Parameters: campaign_id (string, required) — Campaign UUID; campaign_link_id (string) — Tracked link UUID (if content includes a specific tracked link); channel (string, required) — Distribution channel (e.g., "linkedin", "reddit", "email"); content_type (enum("post" | "article" | "comment" | "reply" | "thread" | "email" | "ad" | "bio"), required) — Content type; body (string, required) — The content text; posting_account (enum("personal" | "company" | "other")) — Which account this is intended for (e.g., personal LinkedIn vs Rampify company page). Stored in metadata.posting_account.; metadata (object) — Additional metadata (subject_line, cta, hashtags, etc.); domain (string) — Site domain; project_id (string) — Project UUID ## get_top_campaign_content URL: https://www.rampify.dev/docs/mcp/get_top_campaign_content See your top-performing campaign content for reference when writing more. A read-only Rampify MCP tool for Claude Code, Cursor, and claude.ai. Parameters: domain (string) — Site domain; project_id (string) — Project UUID; channel (string) — Filter by channel; content_type (string) — Filter by content type; sort_by (enum("clicks" | "ctr")) — Sort by clicks or CTR (default: clicks); limit (integer) — Max results (default: 10, max: 50) ## get_campaign_performance URL: https://www.rampify.dev/docs/mcp/get_campaign_performance Get traffic and performance data for a marketing campaign. A read-only Rampify MCP tool for Claude Code, Cursor, and claude.ai. Parameters: campaign_id (string, required) — Campaign UUID; period (string) — Time period: 7d, 30d (default), 90d; domain (string) — Site domain; project_id (string) — Project UUID ## get_business_profile URL: https://www.rampify.dev/docs/mcp/get_business_profile Read your project's business profile and onboarding completeness so your AI's advice fits who you are. A read-only Rampify MCP tool for Claude and Cursor. Parameters: domain (string) — Site domain; project_id (string) — Project UUID ## update_business_profile URL: https://www.rampify.dev/docs/mcp/update_business_profile Update business-profile fields — positioning, audience, category — and onboarding state. A Rampify MCP tool for Claude Code, Cursor, and claude.ai. Parameters: domain (string) — Site domain; project_id (string) — Project UUID; section (string) — Section to update (e.g., "business_identity", "competitive"); fields (object, required) — Field key-value pairs to update, keyed by PROFILE FIELD KEY (not raw DB column names — several are JSONB fields). Accepted keys: primary_industry, business_model, company_stage, elevator_pitch, service_area_type, primary_location, service_radius_km, primary_goals, audience_personas, competitors, differentiators, voice_samples, voice_analysis, focus_areas, primary_cta, primary_content_types, publishing_frequency, business_narrative, projection_monthly_price, projection_trial_conversion, projection_paid_conversion, projection_aov, projection_conversion_rate, projection_deal_value, projection_lead_rate, projection_close_rate, projection_rpm, projection_custom_ctr_curve. Call get_business_profile to see the current values and shape. Unknown keys are rejected — the error response returns the full valid_keys list. ## list_products URL: https://www.rampify.dev/docs/mcp/list_products List the products configured on a project: the default plus any the founder added. A read-only Rampify MCP tool for Claude, Cursor, and claude.ai. Parameters: domain (string) — Site domain; project_id (string) — Project UUID ## create_product URL: https://www.rampify.dev/docs/mcp/create_product Add an additional product to a project to track a distinct offering separately. A Rampify MCP tool for Claude Code, Cursor, and claude.ai. Parameters: project_id (string) — Project UUID. Required unless domain is provided.; domain (string) — Site domain. Required unless project_id is provided.; name (string, required) — Human-readable product name (e.g., "Directory Sync"). Required.; slug (string) — URL-safe slug for the product. Derived from name when omitted. Must be unique per project. ## update_product URL: https://www.rampify.dev/docs/mcp/update_product Update a product's name, slug, or positioning fields. A Rampify MCP tool for Claude Code, Cursor, and claude.ai. Parameters: product_id (string) — Single product UUID (alternative to product_ids).; product_ids (string[]) — Multiple product UUIDs for batch update — the same fields are applied to each.; name (string) — New human-readable product name.; slug (string) — New URL-safe slug. Must be unique per project.; category_phrase (string | null) — New category phrase; null clears the field.; one_liner (string | null) — New one-line positioning; null clears the field.; primary_cta (string | null) — New primary CTA copy; null clears the field.; tagline (string | null) — New tagline; null clears the field.; tech_stack_category (enum("developer_built" | "website_builder" | "traditional_cms" | "ecommerce_platform" | "jamstack_headless" | "unknown") | null) — New tech stack category; null clears the field. ## delete_product URL: https://www.rampify.dev/docs/mcp/delete_product Delete a non-default product from a project. A Rampify MCP tool for Claude Code, Cursor, and claude.ai. Parameters: product_id (string, required) — UUID of the product to delete. Required. ## research_competitors URL: https://www.rampify.dev/docs/mcp/research_competitors Find competitor candidates by keyword overlap and homepage analysis, then save them to the project. A Rampify MCP tool for Claude and Cursor. Parameters: domain (string) — Site domain; project_id (string) — Project UUID; seed_competitors (string[]) — Optional seed domains to include in the analysis (e.g., ["acme.com", "rival.io"]) ## start_discovery URL: https://www.rampify.dev/docs/mcp/start_discovery Start a multi-step Discovery research session, like a Category Visibility Check, on your project. A Rampify MCP tool for Claude, Cursor, and claude.ai. Parameters: domain (string) — Project domain (alt to project_id).; project_id (string) — Project UUID.; product_id (string) — Optional. Product to scope this session to. Defaults to the project's default product when omitted. Use list_products to discover product IDs for multi-product projects.; template (enum("category_visibility" | "comparison_readiness" | "scenario_surfacing" | "developer_workflow" | "narrative_audit" | "market_opportunity")) — Optional. Map the user's natural-language template name to one of the slugs. Omit only when the user did not name a template at all — the tool will tell you whether to pick automatically or ask the user. ## get_discovery_action URL: https://www.rampify.dev/docs/mcp/get_discovery_action Read the current next action for a Discovery session, with no side effects. An agent-invoked, read-only Rampify MCP tool used mid-session. Parameters: session_id (string, required) — Session returned from start_discovery. ## discovery_submit_profile_enrichment URL: https://www.rampify.dev/docs/mcp/discovery_submit_profile_enrichment Submit agent-derived business-profile enrichment during a Discovery session. An agent-invoked Rampify MCP tool the agent calls mid-flow. Parameters: session_id (string, required) — Session returned from start_discovery.; fields (object, required) — Profile fields the agent inferred from the site. Recognized keys: category_phrase (string); one_liner (string); primary_cta (string); tagline (string); competitors_named (array of names (replaces the existing list)); brand_name (string). Other keys are ignored and reported back in the response. ## discovery_submit_clarify_answers URL: https://www.rampify.dev/docs/mcp/discovery_submit_clarify_answers Submit user answers to a Discovery clarify step. An agent-invoked Rampify MCP tool the agent calls mid-session, not one you invoke directly. Parameters: session_id (string, required) — Session returned from start_discovery.; answers (object, required) — User answers to the clarify questions, keyed by field name. Same recognized keys as discovery_submit_profile_enrichment. Recognized keys: category_phrase (string); one_liner (string); primary_cta (string); tagline (string); competitors_named (array of names (replaces the existing list)); brand_name (string). Other keys are ignored and reported back in the response. ## discovery_submit_prompts URL: https://www.rampify.dev/docs/mcp/discovery_submit_prompts Submit the generated research prompts for a Discovery session. An agent-invoked Rampify MCP tool the agent calls mid-flow. Parameters: session_id (string, required) — Session returned from start_discovery.; prompts (object[], required) — Generated prompts to persist as research_queries. The set must exactly match the shape defined by the session template (e.g. 3 category + 2 competitor_shootout for comparison_readiness) — server-side validation rejects mismatched counts. ## discovery_submit_subagent_results URL: https://www.rampify.dev/docs/mcp/discovery_submit_subagent_results Submit per-query subagent answers and extractions during Discovery. An agent-invoked Rampify MCP tool the agent calls mid-session. Parameters: session_id (string, required) — Session returned from start_discovery.; results (object[], required) — Per-query subagent results. Each item carries the natural-language raw_text plus structured extraction fields (brand_mentioned, citations, competitor_mentions, claims, refusals, tone, recommendations, confidence). Inner objects are strict — typos like citations: ["url"] (string instead of {url}) fail with a clear shape error. ## discovery_record_filed_spec URL: https://www.rampify.dev/docs/mcp/discovery_record_filed_spec Record that the agent filed a feature spec during a Discovery session. An agent-invoked Rampify MCP tool used mid-flow. Parameters: session_id (string, required) — Session returned from start_discovery.; spec_id (string, required) — UUID of the feature_spec the agent just created.; spec_url (string) — Dashboard URL for the spec, if available. ## discovery_record_keywords_derived URL: https://www.rampify.dev/docs/mcp/discovery_record_keywords_derived Record that the agent derived keyword clusters during a Discovery session. An agent-invoked Rampify MCP tool used mid-flow. Parameters: session_id (string, required) — Session returned from start_discovery.; clusters_created (number) — Informational — number of keyword clusters created. Not persisted; the snapshot only records that derivation happened. ## derive_keyword_clusters URL: https://www.rampify.dev/docs/mcp/derive_keyword_clusters Turn Discovery findings into pre-clustered keyword groups with live volume data. A Rampify MCP tool for Claude Code, Cursor, and claude.ai. Parameters: domain (string) — Project domain (alternative to project_id).; project_id (string) — Project UUID. Pass one of this or domain.; session_id (string) — Discovery session UUID that produced these insights. Shown as provenance on each cluster ("Derived from Discovery session …"). Pass it when you are acting on a derive_keywords next_action from a Discovery session.; source_type (enum("discovery_session" | "homepage" | "manual"), required) — How the keywords were derived. discovery_session = synthesized from a Discovery session + business profile (normal close-the-loop). homepage = synthesized only from homepage/profile (pre-Discovery bootstrap pass). manual = user-directed.; keywords_by_bucket (object, required) — Keywords pre-grouped by Discovery bucket. You synthesize these in your own context from the business profile + optional Discovery session data. Aim for 5-12 keywords per bucket so the whole batch stays under ~50 keywords (one DataForSEO call). Keywords must be category-level search terms, not brand-mentions. "customer data platform" ✓, "Acme CDP reviews" ✗.; locale (string, required) — Locale code for DataForSEO lookup. Default: en. ## list_research_sessions URL: https://www.rampify.dev/docs/mcp/list_research_sessions List the Discovery research sessions run on a project. A read-only Rampify MCP tool for Claude Code, Cursor, and claude.ai. Parameters: domain (string) — Project domain (alternative to project_id).; project_id (string) — Project UUID (alternative to domain).; plan_id (string) — Filter to sessions for a specific Discovery plan.; limit (integer, required) — Max sessions to return (1-200, default 50).; offset (integer, required) — Pagination offset (default 0). ## get_research_session URL: https://www.rampify.dev/docs/mcp/get_research_session Read a Discovery session's findings: a summary by default, or full responses on request. A read-only Rampify MCP tool for Claude and Cursor. Parameters: session_id (string, required) — Discovery research session UUID.; detail (enum("summary" | "full")) — Response detail level. Default "summary" returns counts only; "full" inlines responses, citations, and indexation snapshots. ## suggest_next_action URL: https://www.rampify.dev/docs/mcp/suggest_next_action Get a recommended next action for your project based on its current state, so you always know what to do next. A read-only Rampify MCP tool for Claude. Parameters: domain (string) — Site domain; project_id (string) — Project UUID; time_budget_minutes (number) — How many human minutes are available. Filters out anything bigger.; autonomy (enum("agent" | "agent-draft-human-approve" | "human-only" | "any")) — Who should do the work. Default (omit): human-involved only (decisions + reviews). "agent" = agent-autonomous items. "human-only" = strategic judgment only. "any" = no filter.; opportunity_types (string[]) — Filter to these opportunity types (e.g., ["fix_meta", "close_ranking_gap"]).; min_confidence (number) — Minimum confidence threshold 0..1. Default 0 (no filter).; launch_phase (enum("pre_launch" | "initial_submission" | "indexing" | "public_launch" | "growth" | "all")) — Override the project's current launch phase. Pass "all" to see opportunities regardless of stage. Default: use the project's current_phase.; limit (number) — How many options to return (default 5, max 20). ## send_feedback URL: https://www.rampify.dev/docs/mcp/send_feedback Send feedback — praise, an issue, a suggestion, or confusion — to the Rampify team. A Rampify MCP tool for Claude Code, Cursor, and claude.ai. Parameters: feedback_type (enum("praise" | "issue" | "suggestion" | "confusion"), required) — Type of feedback; description (string, required) — Clear description of the feedback. For issues, describe what happened. For praise, describe what worked well.; expected_behavior (string) — What the user expected to happen (for issues/confusion); severity (enum("minor" | "major" | "blocking")) — Severity level (for issues only); tool_name (string) — Which MCP tool triggered this feedback; tool_params (object) — Parameters that were passed to the tool; tool_response_summary (string) — Brief summary of the tool response (truncate to ~500 chars); user_goal (string, required) — What the user was trying to accomplish when this happened; conversation_summary (string, required) — Brief summary of the relevant conversation context leading to this feedback; domain (string) — Site domain; project_id (string) — Project UUID ## REST API URL: https://www.rampify.dev/docs/integrations/rest-api REST API Reference Complete REST API reference for programmatic access to Rampify's SEO intelligence. Quick Start 1. Generate API Key Get your API key from Settings → API Keys: # Your key will look like this sk live abc123def456... 2. Set Environment Variable 3. Make Your First Request curl https://www.rampify.dev/api/clients/{clientId}/analyze \ -H "Authorization: Bearer $RAMPIFY API KEY" \ -H "Content-Type: application/json" \ -d '{"callbackUrl": "https://hooks.n8n.cloud/webhook/abc123"}' Authentication All endpoints require API key authentication. Include your API key in the Authorization header: curl https://www.rampify.dev/api/sites/{siteId}/feature-specs \ -H "Authorization: Bearer sk live your api key" \ -H "Content-Type: application/json" Get your API key: Settings → API Keys Sites POST /clients/{clientId}/analyze Triggers a full site crawl and analysis. This is an asynchronous operation that returns immediately with a siteCheckId for polling. Workflow Options: Option 1: Webhook (Recommended for n8n/Zapier) 1. Call this endpoint with callbackUrl in request body 2. Continue with other tasks - no polling needed 3. Receive POST to your callback URL when complete 4. Fetch the generated specs with /api/sites/{siteId}/feature-specs Option 2: Polling 1. Call this endpoint (no callback URL) 2. Poll /api/site-checks/{siteCheckId}/status every 10s until status === "completed" 3. Fetch the generated specs with /api/sites/{siteId}/feature-specs Parameters Parameter Location Type Required Description ----------- ---------- ------ ---------- ------------- clientId path string ✓ Client ID Request Body Optional webhook configuration - Skip polling by providing a callbackUrl . When analysis completes, Rampify POSTs to your webhook with: - event : "analysis.completed" - data.siteCheckId : Use to generate action plan - data.status : "completed" - data.totalUrls , data.urlsChecked , data.issuesFound Perfect for n8n Wait nodes and Zapier webhooks. { "callbackUrl": "https://hooks.n8n.cloud/webhook/abc123" } Responses 200 Analysis started successfully { "success": true, "siteId": "303fe31c-963c-45dd-a35d-49460e71b16b", "siteCheckId": "0af7de47-8fff-4a89-83bc-002436ef2a8b", "backgroundJob": "in progress", "summary": { "totalUrls": 28, "urlsChecked": 0, "issuesFound": 0, "criticalIssues": 0, "warnings": 0, "duration": 2907 }, "issues": [], "message": "Found 28 URLs. Checking URLs in background..." } 401 Unauthorized - Missing or invalid API key { "error": "Unauthorized" } 404 Resource not found GET /site-checks/{siteCheckId}/status Check the status of a background site analysis. Poll every 10 seconds until status === "completed" Parameters Parameter Location Type Required Description ----------- ---------- ------ ---------- ------------- siteCheckId path string ✓ Site check ID from analyze endpoint Responses 200 Status retrieved { "urls checked": 28, "total urls": 28, "status": "completed" } 401 Unauthorized - Missing or invalid API key { "error": "Unauthorized" } 404 Resource not found Rate Limits Tier Requests/Hour Scans/Day --------- --------------- ------------ Free 100 1 Starter 1,000 10 Pro 10,000 Unlimited Rate limit headers are included in all responses: X-RateLimit-Limit: 1000 X-RateLimit-Remaining: 943 X-RateLimit-Reset: 1634567890 Error Handling Errors follow this format: { "error": { "type": "authentication error", "message": "Invalid API key", "details": {} } } Common error types: - authentication error - Invalid API key - rate limit error - Too many requests - validation error - Invalid parameters - not found error - Resource not found - tier required error - Feature requires upgrade ## Overview URL: https://www.rampify.dev/docs/guides { question: 'What is Discovery Optimization?', answer: 'The unified practice of getting found across algorithmic search (Google), AI answer engines (ChatGPT, Claude, Perplexity, Gemini), and the SERP, then wiring every gap directly to the work that closes it. It centers the outcome of being discovered, rather than the mechanism of any single ranking algorithm.', }, { question: 'How is it different from SEO, AEO, GEO, or LLMO?', answer: 'Those terms each name a single layer of the same problem. SEO is the algorithmic-search layer; AEO, GEO, and LLMO are the answer-engine layer. The underlying levers (extractable content, authoritative third-party mentions, indexation, a consistent narrative) are shared across every surface, so Discovery Optimization treats them as one discipline instead of separate stacks.', }, { question: 'Which methodology should I run first?', answer: 'Category Visibility. It needs almost no setup and gives you a baseline for whether the answer engines name you at all. From there, Comparison Readiness, Scenario Surfacing, and Developer Workflow probe sharper moments in the buyer journey, and Search Performance Analysis works the search data you already own.', }, { question: 'Do I need to replace my existing SEO tools?', answer: 'No. Discovery Optimization assumes your keyword research and technical SEO already exist. Rampify reads the same data (Search Console, your pages) and adds the answer-engine layer those tools do not cover.', }, ]; The Discovery Optimization Guide Discovery Optimization is the unified practice of making your brand findable everywhere people now discover things: algorithmic search (Google), AI answer engines (ChatGPT, Claude, Perplexity, Gemini), and the SERP itself. It then wires every gap directly to the work that closes it. It centers the outcome of being discovered, not the mechanism of any one ranking algorithm. This guide is a growing set of techniques for doing that work. Each chapter is a repeatable methodology, something you (or an agent) can run end to end. They are organized by the question that actually separates them: which signal does the technique read? How this maps to SEO and AEO You probably know these surfaces by their usual names. SEO is optimizing for algorithmic search engines like Google. AEO (also called GEO or LLMO) is optimizing for AI answer engines like ChatGPT and Claude. They are not competing disciplines. They are two surfaces of the same job, getting discovered, and the SERP increasingly blends them. Discovery Optimization is the practice that treats all of it as one. Your own search data The signals you already own: the impressions, clicks, and conversions sitting in your own Search Console and analytics. This is the traditional-search end of the spectrum, and the cheapest place to start, because the data is already yours. The answer engines What the LLMs actually say when a prospect asks, measured by probing them with realistic, conversational questions. This is the AI-answer end of the spectrum. In Rampify these run as Discovery research sessions , and each is its own methodology. These run inside Discovery ( start discovery ), and each probes the same business from a different angle in the buyer's journey: The SERP The results page itself: who ranks, which result shapes win, and the AI Overviews now embedded in it. This is the bridge between the first two. The SERP increasingly contains the answer engine, so reading it agentically connects ranking research to answer-engine research in one pass. - Agentic SERP research. Coming soon. The agent retrieves and analyzes real search results instead of paying a SERP API, then turns what it finds into opportunities. --- New to Rampify? Start with How Rampify Works, or see the MCP tools that power these methodologies. ## Search Performance Analysis URL: https://www.rampify.dev/docs/guides/search-performance-analysis Search Performance Analysis seo google search console your own data Search Performance Analysis is a Discovery Optimization technique for finding SEO opportunities in the search data you already have. Most SEO advice starts with a keyword tool and a volume estimate for a term you don't rank for yet. This technique starts at the other end: the impressions, clicks, CTR, and position already sitting in your Google Search Console, including queries you're surfacing for at position 40 that nobody told you about. It is the part of SEO that needs no new keywords and no new content. You are optimizing what you already rank for. You don't need volume estimates to begin. You need to read the data your own site is already producing. This is the search-data side of Discovery Optimization; the answer-engine side starts with Category Visibility. When to use it Reach for Search Performance Analysis when: - You have a site with some Search Console history. Even a few hundred impressions is enough. - You see queries you rank for but earn no clicks on, meaning high impressions and a CTR near zero. - You have content that sits adjacent to a real query but doesn't quite match what the searcher wants. It is the cheapest technique in the guide, because the input is free. You already paid for it by publishing. The method: the impression, intent, conversion loop Open the Search Console performance report (or Rampify's search performance) and sort your queries by impressions, ascending CTR . You are hunting for queries with real impressions and a click-through rate near zero, and especially queries you didn't know you ranked for at all. These are demand signals you already hold. Don't filter by volume. Filter by surprise. For each candidate, ask the load-bearing question: does the page Google is serving actually match what this searcher wants? High impressions with a CTR near zero is rarely a title-tag problem. It is usually an intent problem. You rank, but for the wrong shape of result. Someone searching "X checker" wants a checker; if Google is serving them your how-to blog post, they won't click no matter how good the snippet is. The single highest-leverage move here: when you find high impressions paired with a CTR near zero, you have found a page that is ranking on the wrong intent . You don't need to win a new keyword. You need to reclaim the impressions you already have by giving them the page they were looking for. Rebuild the content into the shape the query wants. A blog post becomes a use-case page. A generic overview becomes a comparison. A docs stub becomes a tool page. Then 301-redirect the old URL to the new one so the ranking and impressions you already earned carry over instead of starting from zero. This is the step people skip, and it is why their rewrite tanks. A fresh URL throws away the signal you spent months accumulating. A page that ranks but cannot convert is vanity. Give the restructured page an unambiguous next step, a "Get started" action that routes to your signup or activation flow. The whole point of working the signal is to turn it into an outcome, so build the outcome in before the traffic arrives. Watch the right metric. Rank and impressions tell you Google is serving the page. Conversions tell you the loop closed. Track which landing pages actually produce signups, not just which ones rank, and let that decide where you look next. (As you'll see below, the conversions can arrive even when the classic clicks don't.) Worked example: /use-cases/claude-seo-checker This is the page that prompted the technique, a real and verifiable run of the loop on Rampify's own site. 1. The faint signal. In December 2025 the query "claude seo checker" showed up in Search Console with 27 impressions at average position ~44.9 , page five, a handful of impressions, easy to ignore. We didn't ignore it. 2. The intent diagnosis. The page Google was serving for it was a blog post about Claude Code subagents for blog writing . Over the following months that post climbed to 1,009 impressions, at 0% CTR . Google was convinced we were relevant to "claude seo checker," but the result was a how-to article and the searchers wanted a checker . Textbook wrong-intent ranking. 3. The restructure. We rebuilt the content as a purpose-built use-case page, /use-cases/claude-seo-checker , framed as "here is the checker," and 301-redirected the old blog URL to it so the roughly 1,000 impressions of equity came along. 4. The conversion path. The new page leads with a "Get started" action into the free signup. 5. The result. As Google re-served the intent-matched page, it climbed to roughly 7,916 impressions over 28 days and now ranks top-5 across the whole cluster : position ~2 on "claude seo checkers," ~4 on "claude seo checker," and in the top handful on dozens of tool, tracker, and audit variants. To date the page has produced 6 free-signup conversions . Here is the counterintuitive part. Even at the top of the rankings, this page's Google CTR is still about 0.1%. Almost nobody clicks the organic result. The conversions come from the blend of organic and direct traffic, and a large share of that direct traffic is people who asked an AI assistant "best claude seo checker," got pointed here, and arrived without a tracked click. Search Performance Analysis bought us the ranking and the AI-recommendation surface , and on today's web, owning those converts even when the classic click never happens. That is the bridge between traditional search and AI search in a single page. Scale the win into a cluster There is one more move, and it is where the compounding happens. Once a page wins, treat it as a template . The claude-seo-checker win became the pattern for a family of sibling use-case pages, one per platform, each the same restructure aimed at a different query. Combined, the cluster has produced 9 conversions (claude-seo-checker 6, cursor-seo 2, windsurf-seo 1), not just the original page's 6. One winning template, compounding across a family. One rule, learned the hard way on our own cluster: every page you add must own a distinct query intent. We once had a Claude Code page that drifted into the same "claude seo" queries the winner already owned. Instead of adding reach, it cannibalized: 2,750 impressions stuck at position 40, zero conversions, and four pages quietly competing for "seo software for claude." We folded it back into the winner. If a new page targets a query an existing page already wins, that is one page too many, not one more win. The conversions column on your Pages tab is how you tell the siblings apart: which ones actually convert versus which just rank. Scale the template only where the conversions follow. How Rampify does each step for you This is a manual loop you can run by hand. Rampify shortens every step: - Read the data. get search performance (and per-page intelligence) surface your impressions, CTR, and the queries you rank for, so the faint signals come to you instead of you scrolling Search Console. - Triangulate intent. The Google Search surface and the traffic Pages tab flag the tell-tale pattern, a striking-distance rank with weak CTR, so wrong-intent pages are highlighted rather than hunted. - Restructure and preserve equity. Rampify's opportunities are redirect-aware, so once you 301 a page it stops re-flagging the old URL and tracks the equity moving to the new one. - Add the conversion path and measure. The traffic Pages tab carries a conversions column beside impressions and CTR, so you can rank your landing pages by what actually converts and watch the loop close. That is how we know this page produced six signups. The fastest way to start is to connect Search Console and ask your AI tool, through the Rampify MCP, where your wrong-intent impressions are. ## Category Visibility URL: https://www.rampify.dev/docs/guides/category-visibility Category Visibility aeo answer engines 5 prompts · ~5 min needs: category Category Visibility is a Discovery Optimization research methodology that answers one question: when someone asks about your category, do you come up? Not "do you rank for your own brand name." Anyone surfaces for their own name. The real test is whether an answer engine recommends you to a prospect who does not know you exist yet and asks a plain category question. Where Search Performance Analysis reads the signals you already own, Category Visibility probes a signal you do not control, what the LLMs say, by asking them the questions your buyers ask. First, what is a "category"? Your category is the space you compete in, described the way buyers describe it, not the way you describe yourself. It is the job to be done, not your brand or your feature list. "Project management software for engineering teams" is a category. "Acme Tracker, the AI-native planning workspace" is not, that is your brand. Buyers who do not know you yet search and ask in category terms, so that is the language the answer engines have to associate with you. If you are not sure how to phrase yours, that is fine, and it is the first thing to fix (see "Before you run it" below). When to use it This is the default first session in Rampify Discovery, and the right starting point for almost everyone: - You want a baseline for how visible you are in AI answers, before any optimization. - Your brand is not a household name in your space yet, so buyers describe what they need in category terms instead of asking for you by name. - You want to know whether the answer engines even know you belong in the conversation. It needs almost nothing to run, no competitor list and no deep profile, which is why it is first. How the method works The session runs from a persona, a stand-in for a real prospect in your category, and the prompts are written from that point of view. Your brand is deliberately kept out of frame so the test measures organic surfacing, not recall. The methodology generates five questions a prospect might ask a coding agent or ChatGPT before they know any brands, mixed across how specific they are: one broad, two medium, and two narrow and qualified. None of them name your brand or domain. That is the whole point. They are written the way people actually talk to an assistant, with context and follow-up, not as one-line search queries. Each question is put to the answer engine in search-enabled mode, so you are measuring what a real user gets today, training knowledge plus live retrieval, not just what the model memorized. This is what makes it a measurement of the live web, not a trivia quiz. For each answer, the session records whether your brand came up, in what company, and how it was framed. Five prompts give you a read across the category, not a single anecdote. A worked example Think back to the last time you researched buying something through an AI assistant. You did not type a terse keyword. You opened with a plain question and then added context until the assistant narrowed things down for you. Say your category is project management for engineering teams , the space where Linear, GitHub Projects and Issues, Jira, Asana, and Notion all compete. A real prospect does not search "best PM tool." They have a conversation that looks more like this: Broad: "What are engineering teams using these days to plan work and track issues?" Medium, with context: "I run a 15-person engineering team. We basically live in GitHub and Slack, and we are tired of keeping the roadmap in spreadsheets. What project management tools actually fit a developer-first workflow?" Narrow and qualified: "We are a Series A startup, around 25 engineers, already on GitHub. We want something fast and keyboard-driven that engineers will not resist, with a clean API and solid issue tracking. We do not need heavyweight enterprise PM. What should we shortlist?" Notice what is happening. None of these name a brand, and each one carries the kind of context (team size, existing stack, requirements, what they are not looking for) that an assistant uses to narrow the field. That context is the difference between AI search and a traditional one-shot query, and it is exactly what Category Visibility reproduces. Now the test: when the answer engine responds, are you in the list? If you sell a developer project management tool and the assistant names Linear and Jira but never you, you have a category-visibility gap. And the three altitudes tell you different things: - Missing from the broad question means a top-of-funnel awareness gap. New buyers start here. - Missing from the medium question means you are not connected to the workflow and constraints buyers describe. - Missing from the narrow question, even when your product is a great fit for those exact requirements, is the most painful and the most fixable: the engine does not yet know what you are specifically good at. If you ask whether your brand is good for X, every model will say yes. It is being agreeable, not informative. Category Visibility only means something because the prompts never mention you. Surfacing in a no-brand category answer is earned. Surfacing in a brand-named one is just politeness. How to read the results - You surface on broad and narrow alike. Strong category presence. Move on to sharper methodologies like Comparison Readiness or Scenario Surfacing (see the guide hub). - You surface only on narrow, qualified questions. You are known for a specific niche but invisible in the general category. The opportunity is broad-category content and authority. - You do not surface at all. The answer engines do not yet associate you with your category. This is the most common early-stage result, and the most actionable. It means the foundational content and third-party signals that LLMs read are not there yet. A gap here is not a verdict. It is a worklist. What to do about gaps When you are missing from category answers, the levers are the same ones that make content extractable and authoritative for LLMs: - Publish clear, category-level content that states plainly what you do and who it is for (see AI Visibility for how answer engines read a page). - Earn the third-party mentions and structured, extractable signals models lean on. - Re-run the session over time to watch the gap close. The same five questions make a clean before-and-after. Before you run it: your category lives in your Business Profile The questions are generated from your Business Profile , specifically the category you operate in. If that is thin or missing, the prompts will be vague and the results will be too. Flesh it out first. From your AI tool you can say "Enrich my business profile" and Rampify will auto-fill your category and positioning from your site's public pages, so the session has a sharp category to probe. Run it in Rampify Category Visibility runs as a Discovery session. It takes about five minutes and needs no setup beyond a connected project. Once your business profile has a category, use the Connect Rampify button at the top of this page to start it. The agent generates the persona-shaped questions, probes the answer engines with search, records where you surface, and turns the gaps into specs you can act on. ## Comparison Readiness URL: https://www.rampify.dev/docs/guides/comparison-readiness Comparison Readiness aeo answer engines 5 prompts · ~5 min needs: competitors Comparison Readiness is a Discovery Optimization research methodology that asks whether you make the shortlist when a buyer is already narrowing between named options. Category Visibility tests whether you come up at all. This tests the next moment in the journey: the buyer has two or three names in hand and asks the assistant to help them decide. When that comparison happens, are you pulled in, or left out of a conversation you should be in? When to use it Run Comparison Readiness when: - You already have some category presence and want to test the consideration stage, not just awareness. - You have real competitors buyers actively weigh you against. - You are losing deals to a specific rival and want to see how the answer engines frame that matchup. It is a natural second session after Category Visibility. You need a competitor set first This methodology only works if Rampify knows who your competitors are. The session names them in the prompts (it needs at least one tracked competitor, and will round out a field of two or three if you only track one). Before you run it, make sure your competitor set is current. From your AI tool you can say "Find my competitors" and Rampify will discover candidates by keyword and homepage overlap and save them to your project, or you can edit the list directly in your business profile. Your competitive landscape shifts. A list you typed once goes stale, and a stale list quietly narrows what this methodology can test. Re-checking your competitors on a regular cadence is its own discipline, and a good habit to build alongside this session. How the method works The session generates five prompts: three neutral category questions (no brand names, the same shape as Category Visibility) plus two competitor-shootout questions that name your tracked rivals. The category questions set a baseline; the shootouts are where the real test lives. A shootout prompt sounds like a buyer who has already narrowed the field: "Between A, B, and C, which is best for this job?" or "I have been comparing A and B, what else should I consider?" The second shape is the important one. It measures defensive surfacing : when a buyer is deciding between your competitors and has not mentioned you, does the assistant pull you into the conversation anyway? Each prompt runs in search-enabled mode. The session records not just whether you appear, but how you are positioned against the named rivals, who the assistant defaults to, and what reasons it gives. A worked example We are using one category across these chapters, project management for engineering teams (Linear, GitHub Projects, Jira, Asana, Notion), so you can see how each methodology asks a different question about the same business. Category Visibility asked the open question. Comparison Readiness asks the deciding one. A buyer who is already narrowing talks to the assistant like this: Shootout, named field: "We are choosing between Jira and Asana for a 20-person engineering team. Which one fits a developer-first workflow better?" Defensive surfacing, you are not named: "I have been comparing Linear and Jira for our eng team and I am leaning Linear. Before I commit, what else should I be looking at?" That second prompt is the test that matters. If you sell a developer project management tool and the assistant answers "Linear and Jira are both solid, you might also look at..." and your name is not in that list, you just lost a deal you did not know you were in. You were comparison- un ready. How to read the results - You are named in the shootouts, framed favorably. Strong consideration-stage presence. The work is defending and sharpening that framing. - You appear, but framed as the weaker option. You are in the set but losing the narrative. The fix is positioning and proof, not awareness. - You are absent from the shootouts, even the defensive one. The most expensive gap. Buyers are deciding without you in the room. You need the comparison content and third-party signals that make the assistant include you when rivals are named. What to do about gaps - Publish clear, honest comparison content against the competitors you actually lose to (the assistant reads it). - Earn third-party mentions that place you in the same sentence as those rivals. - Re-run after each change to watch whether you start getting pulled into the shootouts. Run it in Rampify Comparison Readiness runs as a Discovery session. Confirm your competitor set is current, then use the Connect Rampify button at the top of this page to start it. The agent writes the category and shootout prompts, probes the answer engines, and turns each gap into a spec you can act on. ## Scenario Surfacing URL: https://www.rampify.dev/docs/guides/scenario-surfacing Scenario Surfacing aeo answer engines 5 prompts · ~5 min needs: category Scenario Surfacing is a Discovery Optimization research methodology that asks whether you are recommended when a real problem shows up in natural language. Most buyers do not start by naming a category (that question is Category Visibility). They start by describing a situation: something broke, something is slow, the team outgrew a tool. They tell the assistant what is wrong and ask what to do. This methodology measures whether you surface at that moment, before the buyer has framed their problem as a category at all. When to use it Run Scenario Surfacing when: - You want to test the earliest, messiest part of the journey, where buyers describe pain rather than shop for a category. - Your product solves a recognizable problem people can articulate in their own words. - You suspect you are invisible until someone already knows they want your category. How the method works The session generates five problem-framed questions, each opening with a first-person situation: "My team just hit X," "I need to solve Y," "We are evaluating a change because Z." These are not category queries. They are the way a founder or engineer actually talks to an assistant when something is wrong. The scenarios stay grounded in your category without naming it, and never name your brand. The point is to see whether the assistant connects a described problem to you as a solution, which is a harder and more valuable test than category recall. Each prompt runs in search-enabled mode. The session records whether you surface, and just as importantly, what the assistant recommends instead when it does not reach you. A worked example Same category as the other chapters, project management for engineering teams . Category Visibility asked "what do teams use." Scenario Surfacing starts from the pain, before the buyer has even decided they are shopping for a project management tool: The pain comes first: "Our eng team has grown to 30 people and our GitHub issues are total chaos. Planning happens in three different spreadsheets and nobody trusts any of them. How do other teams actually keep this organized?" A situation, not a category: "We keep missing deadlines because no one has a clear view of what everyone is working on. We live in GitHub and Slack. What should we change?" Notice the buyer never says "project management software." They describe a mess. The test is whether the assistant hears "30-person eng team, GitHub chaos, missing deadlines" and routes them to your category, and to you specifically. If you sell a dev project management tool and the assistant suggests "better issue hygiene and a tool like Linear or Jira" without you, you are invisible at the exact moment the buyer is most ready to act. How to read the results - You surface from the pain itself. Excellent. You are connected to the problem, not just the category label. This is the hardest visibility to earn. - You surface only once the category is named, not from the scenario. You have category presence but no problem association. The opportunity is content that speaks to the symptom , not the product. - You do not surface at all. The assistant does not associate your category, or you, with the problems your buyers describe. Start with the problem language your customers actually use. What to do about gaps - Publish content framed around the problem and symptoms , in the buyer's words, not around your feature list. - Make sure your problem framing is extractable and concrete enough for an answer engine to match a described situation to it (see AI Visibility). - Re-run with the same scenarios to track whether you start getting reached from the pain. Run it in Rampify Scenario Surfacing runs as a Discovery session. Make sure your business profile describes your category clearly, then use the Connect Rampify button at the top of this page to start it. The agent writes the scenario prompts, probes the answer engines, and turns each gap into a spec you can act on. ## Developer Workflow URL: https://www.rampify.dev/docs/guides/developer-workflow Developer Workflow aeo coding agents 5 prompts · ~5 min needs: category Developer Workflow is a Discovery Optimization research methodology that asks whether coding agents recommend you while an engineer is building. The other answer-engine methodologies measure the buying conversation, which tool to pick (see Category Visibility and Comparison Readiness). This one measures the implementation conversation: an engineer mid-task asks Claude Code or a similar agent how to add something, install something, or fix something, and the question is whether you come up as part of the answer. For a developer tool, this is often where adoption actually starts. When to use it Run Developer Workflow when: - Your product is something an engineer adopts in the flow of work, not something a buyer evaluates in a meeting. - Your buyers and your users are the same people, and they live inside a coding agent. - You want to measure presence in the implementation register, which behaves very differently from the evaluation register. How the method works The session generates five developer-shaped questions in the implementation register: words like add, integrate, install, configure, handle, and fix, never compare or evaluate. The spread is deliberate: a couple of mid-task implementation questions (each naming a real framework or language), a package recommendation question, a troubleshooting question, and an architecture question. The prompts name concrete frameworks (Next.js, FastAPI, Rails, Go, and the like) because that is how engineers actually ask. No brand names, no domains. The test is whether you surface as the right tool for a specific build, not whether the assistant recalls your marketing. Each prompt runs in search-enabled mode. The session records whether you are recommended, for which kind of task, and which package or tool the assistant reaches for by default. A worked example Same category, project management for engineering teams , but now the question is implementation, not purchase. An engineer mid-build does not ask "what is the best PM tool." They ask: Implementation, mid-task: "I want to automatically open and link a tracking issue from our CI pipeline when a deploy fails. We are on GitHub Actions. What is the cleanest way to wire that up?" Package recommendation: "What is a good API or library for syncing our project tasks into a Next.js internal dashboard?" If your tool has a strong API and a clean developer story, these are exactly the moments you want to surface. An engineer who wires you into their pipeline while building has adopted you before any buying decision ever happened. If the assistant answers with GitHub's native API and never mentions you, you are missing from the workflow where developer tools actually win. This methodology is only meaningful because the prompts are build questions, not buy questions. "Which project tool is best" is a different test (that is Category Visibility and Comparison Readiness). "How do I wire task tracking into my deploy pipeline" measures whether you are part of how engineers work , which for developer tools is the higher-value surface. How to read the results - You surface in implementation and package questions. Strong. You are part of the build, not just the brochure. Protect the API and docs that earn this. - You surface in architecture questions but not hands-on ones. You are known as a concept but not reached for in the moment of work. The gap is concrete, copy-pasteable developer content. - You do not surface at all. Engineers are building around you. You need extractable docs, real code examples, and the kind of developer content coding agents quote. What to do about gaps - Publish task-shaped developer content: how to add, integrate, and troubleshoot, with real code. - Make your API and docs extractable and example-rich, since coding agents quote what they can lift directly. - Re-run to see whether you start showing up in the build, not just the evaluation. Run it in Rampify Developer Workflow runs as a Discovery session. Make sure your business profile describes your category, then use the Connect Rampify button at the top of this page to start it. The agent writes the implementation-shaped prompts, probes the coding agents, and turns each gap into a spec you can act on. ## Narrative Audit URL: https://www.rampify.dev/docs/guides/narrative-audit Narrative Audit aeo training data · no search 3 prompts · ~3 min needs: brand presence Narrative Audit is a Discovery Optimization research methodology that tests what a model knows about your brand from training alone. Every other methodology in this guide measures the live web with search turned on. This one turns search off and asks the model directly about you, so you see what it absorbed into memory from training data, and whether that cached story is accurate, outdated, or simply wrong. It is the only methodology that names your brand on purpose. This is an advanced session, and it only tells you something once a model has actually learned about you. A brand the model has never encountered will produce a blank or a hallucination, neither of which is useful. If you are early, start with Category Visibility instead and come back to Narrative Audit once you have built up presence. When to use it Run Narrative Audit when: - You have enough public presence that models have likely trained on content about you. - You have rebranded, repositioned, or shipped something that may have changed your story. - You want to catch cached misconceptions before they harden across model generations. How the method works The session runs in training-only mode. The model cannot look anything up. Its answer comes purely from what it internalized during training, which is exactly what you want to inspect. Unlike every other methodology, these prompts name you. They cover three framings: identity ("What is X?"), comparison ("How does X compare to alternatives in its category?"), and sentiment ("What do people say about X?"). Together they reveal what the model thinks you are, where it slots you, and how it characterizes you. The value is in the delta. Read each answer against reality and mark what is stale, what is missing, and what is flatly incorrect. A worked example The other chapters use a hypothetical tool in the project management category. Narrative Audit is different: it only works on a brand the model has actually learned about, so picture running it on an established name in that same category, say Linear . Identity: "What is Linear?" Comparison: "How does Linear compare to other project management tools?" Sentiment: "What do people say about Linear?" With search off, the answers come entirely from training. You are looking for the gaps: Does the model still describe an old positioning the company has since moved past? Does it miss a major capability shipped after the training cutoff? Does it compare it against the wrong set of rivals, or repeat a criticism that is no longer true? Each of those is a piece of narrative drift baked into the model, and the audit is how you find it before your buyers run into it. How to read the results - The model describes you accurately and current. Your narrative is well-established and consistent. Maintain it. - The model is roughly right but out of date. Expected, since training lags. The fix is fresh, consistent public content that the next training run can absorb. - The model is wrong, or slots you against the wrong category or rivals. A real narrative problem. Inconsistent or sparse public signals let the model invent a story. Tighten and repeat your positioning everywhere it reads. What to do about gaps - State your positioning consistently across every public surface, since models average what they read. - Earn authoritative third-party coverage that reinforces the story you want remembered. - Re-run periodically. Narrative drift is slow, and catching it early is cheaper than correcting a hardened misconception. Run it in Rampify Narrative Audit runs as a Discovery session. Use the Connect Rampify button at the top of this page to start it. The agent asks the three brand-direct questions with search off, records what the model believes, and turns each correction into a spec you can act on. ## Market Opportunity URL: https://www.rampify.dev/docs/guides/market-opportunity Market Opportunity aeo answer engines 4 archetypes · ~12 min Market Opportunity is a Discovery Optimization research methodology that points the lens at the market instead of at you. Every other methodology in this guide (start with Category Visibility) measures where your brand surfaces. This one steps back and reads the category itself: how crowded it is, where the gaps are, where the vendor pitch and the real-world experience diverge, and what angle you could own. It does not output a content fix. It outputs a strategic positioning read. It works whether or not your brand is established yet. When to use it Run Market Opportunity when: - You are deciding how to position or differentiate, not just how to get found. - You want to understand the competitive landscape and the whitespace in it, in the model's own words. - You are entering or re-entering a category and need to find the wedge before you commit to a message. How the method works It probes the same market through four buyer archetypes , one prompt each, none of which name your brand. Each voice surfaces a different cross-section, and the value is in reading across all four. An engineering-led founder ready to decide asks the standard "what tools exist, what should I look at" question. This surfaces the consensus and shows how dense the category is with well-known players. Someone suspicious of the category asks the hard question: "is this even real, how is X actually different from Y, isn't this just rebranded Z?" This surfaces vendor critique, vocabulary mismatches, and the cracks in the consensus pitch. Someone who has tried things and got stuck asks in first-person frustration: "I tried A and B, here is what is not working, what am I missing?" This surfaces the real failure modes and the gap between marketing and daily use. Someone tracking the space asks for the full picture, including newer and less-marketed entrants. This surfaces the up-and-comers the models tend to under-index, which is where wedges often hide. A worked example Same category as the rest of the guide, project management for engineering teams . Instead of asking "do we show up," Market Opportunity interrogates the market four ways: The Buyer: "What are the main project management tools engineering teams use today, and how do I choose between them?" The Skeptic: "Every project management tool claims to be developer-first. Is there a real difference, or is it all the same Kanban board with different branding?" The Practitioner: "We have bounced between Jira and Asana and both feel heavy for an engineering team. What are we missing about how to actually run this?" The Industry Watcher: "Beyond the obvious names, who is doing something genuinely different in engineering project management right now?" Read across the four and the angles appear. The Skeptic exposes that "developer-first" has become a meaningless claim, which is a vocabulary gap you could own with a sharper one. The Practitioner reveals that "too heavy" is the accepted pain, a wedge for something lighter. The Industry Watcher shows who the models already treat as the interesting outsiders. None of this is about your visibility. It is about where the opening is. The other methodologies hand you a worklist of pages to write. Market Opportunity hands you a strategic read: the density, the gaps, the language mismatches, and a candidate wedge. Use it earlier, when you are deciding what to be in the market, not just how to get found in it. How to read the results - The market reads as crowded and well-defined. Differentiation is your problem to solve. Look for the narrow wedge the four voices agree is underserved. - The voices disagree about what the category even is. A vocabulary opportunity. Whoever names the category clearly can own it. - The Industry Watcher surfaces emerging players the Buyer never mentions. That gap between the consensus and the frontier is often exactly where a new entrant wins. What to do about gaps - Pick the wedge the four archetypes point to and sharpen your positioning around it. - Turn the strongest finding into a positioning spec, then let the other methodologies measure whether the new angle starts landing. - Re-run as the market shifts. Density and whitespace move, and so does your angle. Run it in Rampify Market Opportunity runs as a Discovery session and takes a little longer than the others, since it synthesizes across four distinct voices. Use the Connect Rampify button at the top of this page to start it. The agent runs all four archetype prompts, synthesizes the cross-section, and turns the opening it finds into a positioning spec. ## The Real SEO Play of a Product Hunt Launch (Not the Backlink) URL: https://www.rampify.dev/blog/product-hunt-launch-seo Scroll through IndieHackers a week after any decent Product Hunt launch and you'll find the same post, over and over. The launch went well. Top five of the day, a few hundred upvotes, a spike of signups that felt incredible for about 36 hours. Then the graph fell off a cliff. A month later, the founder searches for their own category ("best tool for X") and they're nowhere. Not on Google. Not in ChatGPT. The launch happened, and then it was like it never happened. That disappointment is real, and it's predictable. The Product Hunt spike is rented attention . You borrow the front page for a day, the traffic is real, and then the lease is up. Nothing about that day makes you findable . And in 2026, findable means two things at once: you rank in Google, and the AI your buyer asks "what's the best tool for X?" actually names you. This guide is about the part of a Product Hunt launch that survives the week: using the moment to build the foundation that makes both search engines and AI find you. It's a contrarian take, so it's sourced. Let's start by making sure you're the right reader. Is This Guide For You? The advice here only pays off if organic search and AI discovery are real channels for your product. That's true for a specific shape of company, and genuinely not true for others. Being explicit up front saves you from following a playbook that doesn't fit your growth model. If you're shipping a single-screen iOS app or a Chrome extension, most of your discovery happens inside a store or a gallery, not on a website you control. The SEO foundation still doesn't hurt, but it won't be your lever. If you're a website-first product (SaaS, a dev tool, an AI tool, a marketplace, a content play), then organic and AI discovery are exactly where your durable growth lives, and this is written for you. The Myths That Set Founders Up For Disappointment The letdown usually traces back to two beliefs that get repeated in launch guides and never checked. Both are wrong, and correcting them is the whole reframe. Myth 1: The Product Hunt Backlink Is An SEO Jackpot You'll read that a Product Hunt link is a "DA-91 dofollow backlink," a shortcut to authority. Open your browser's DevTools on a live Product Hunt product page, inspect the "Visit website" link, and look at the rel attribute: Visit website That rel="noreferrer noopener ugc" tells the honest story, and it's neither of the two things people claim. ugc marks the link as user-generated content. Google treats ugc as a hint that generally passes no standard link equity. This is not a ranking-authority link. noreferrer strips the referrer header, so the destination often can't even attribute the visit to Product Hunt in analytics. noopener is a security attribute and irrelevant to SEO. So the link is not a "dofollow jackpot," and it's also not precisely "just nofollow." It's a UGC link with the referrer stripped. So the Product Hunt link itself is not going to move your rankings. But that doesn't make the launch worthless for SEO. It means the SEO value comes from somewhere other than the link. Myth 2: Launching Makes AI Recommend You The newer belief is that getting featured on Product Hunt teaches ChatGPT, Claude, and Perplexity to recommend you. It's an appealing idea: you got a burst of mentions, surely the models noticed. We'll come back to this one in the study section, because there's actual data on it now, and the data says otherwise. Hold the thought. What The Launch Is Actually Good For Strip away the myths and a launch still has real, defensible value: it's just second-order. A launch drives genuine referral traffic and brand exposure for a day or two. More importantly, a strong launch gets you covered : newsletters, roundups, "tools we loved this week" posts, and press pieces that link to you with normal, followed editorial links. Those second-order links compound over time in a way the Product Hunt link never will. The play isn't the Product Hunt backlink. The play is the coverage the launch earns you, and the foundation that makes that coverage worth something. That reframe (the launch as an authority-building moment , not a traffic event) is the spine of the rest of this guide. The Five Stages: Where The Launch Actually Fits At Rampify we model a launch as five stages, because "launch day" is the visible tip of a much longer arc. The Product Hunt launch anchors the fourth stage, but everything that makes it pay off happens before and after. Here's the whole spine. Notice what this reorders. Most launch guides are 90% about stage four and treat one through three as a checklist you rush the night before. But stages one through three are what decide whether the launch compounds or evaporates. If you land the spike on an un-indexed site with no rank-worthy content, you get exactly the IndieHackers post from the intro. The Product Hunt launch is the amplifier. The foundation is the signal. Founders launch, get a great day, then discover a week later their key pages were serving a leftover noindex from staging the whole time. Google never indexed them, so none of the launch-day authority had anywhere to accumulate. Run URL Inspection on your top pages in stage three, before launch day, not after. The Discovery Gap: What The One Real Study Found Here's the growth-stage evidence, and it's the part that reframes the AI myth. In 2026, Sharma published the first study to actually quantify how visible Product Hunt startups are inside AI discovery (arXiv 2601.00912). It looked at 112 startups from Product Hunt's top 500 and ran 2,240 queries against large language models: both "named" queries (asking about the company directly) and open-ended discovery queries ("what's the best tool for X?"). The gap is stark. When named directly, these startups showed up around 99% of the time. The models know they exist. But in open-ended discovery, where a real buyer doesn't yet know your name, they surfaced only about 3.3% of the time in ChatGPT and 8.3% in Perplexity . Top-500 Product Hunt startups, companies that by definition had strong launches, are almost invisible at the exact moment a buyer is choosing between options. The launch didn't close that gap. So what predicted whether a startup did surface in open-ended AI discovery? In the study, classic SEO signals predicted open-ended visibility in Perplexity: the number of referring domains correlated positively (r = +0.319), and so did Product Hunt ranking. What did not predict it: the GEO / AEO "optimization scores," the AI-specific tricks. The author's paraphrased takeaway is blunt: don't optimize for AI discovery directly. Build the SEO foundation first, and LLM visibility follows. That's the empirical backbone of this whole guide. The thing that makes AI recommend you in open-ended queries isn't an AI-specific hack and isn't the launch badge. It's the same authority foundation (referring domains, real coverage, indexed rank-worthy content) that makes Google rank you. Which is exactly why the durable play of a launch is earning those referring domains, not chasing the backlink. Two honest caveats, stated inline so you can weight this correctly: This is the first study to put numbers on the discovery gap, and it's worth taking seriously, but it's one study. It's single-author, the findings are correlational (not causal), the sample is 112 startups, and ChatGPT was tested without web search enabled, which likely understates what a web-connected model would find. Treat it as directional evidence that points the same way as SEO first principles, not as gospel. It's the best data we have, and it happens to agree with the boring answer: build the foundation. This is also why the AEO and GEO framing matters in the growth stage. Answer engine optimization and generative engine optimization are real disciplines, but the study suggests the highest-leverage version of them is unglamorous: earn referring domains and publish content that genuinely answers buyer questions. The "optimization score" tactics didn't move the needle; the foundation did. Frequently Asked Questions Is the Product Hunt backlink dofollow? No. On a live Product Hunt product page, the "Visit website" link carries rel="noreferrer noopener ugc" (verifiable in your browser's DevTools). The ugc value marks it as user-generated content, which Google generally treats as passing no standard link equity, and noreferrer strips the referrer so the visit often can't even be attributed back to Product Hunt. It is not a dofollow authority link, and it is not precisely a plain nofollow link either. Don't build your SEO plan around it. Build it around the followed editorial links your launch earns from newsletters, roundups, and press. Does a Product Hunt launch help AI visibility? Not directly. In the one study that measures this (Sharma 2026, arXiv 2601.00912), even top-500 Product Hunt startups surfaced in open-ended AI discovery only ~3.3% of the time in ChatGPT and ~8.3% in Perplexity. What predicted visibility was the SEO foundation (referring domains and Product Hunt ranking), not AI-specific optimization scores. So a launch helps AI visibility only insofar as it helps you build that foundation. The launch is the occasion; the foundation is the cause. The Launch Isn't The Play. The Foundation Is. Here's the whole guide in five sentences. The Product Hunt spike is rented attention that evaporates in days. The link it gives you is a ugc link with the referrer stripped, not a ranking shortcut. Launching does not, on its own, teach AI to recommend you. What does make both Google and AI find you is an authority foundation: indexed, rank-worthy content and real referring domains from the coverage a strong launch earns. So use the launch as the moment to build that foundation; that's the play that survives the week. The one thing you can't do from a dashboard of vanity metrics is answer the question that actually matters: when a buyer asks AI "what's the best tool for X?", does it name you? That's the discovery gap, and it's measurable. ## Best SEO MCP Servers for Claude and Cursor (2026) URL: https://www.rampify.dev/blog/best-seo-mcp-servers-claude-cursor There is no shortage of SEO MCP servers anymore. DataForSEO, Ahrefs, Semrush, SE Ranking, Google Search Console wrappers, Frase, Vercel's Next.js dev tools, and a long tail of community projects all expose SEO capabilities to Claude Code, Cursor, and claude.ai. A ranked leaderboard would be the wrong way to compare them, because most of them are not trying to do the same job. The useful split is not "which one is best." It is read versus act . Most SEO MCP servers read your data and hand it to your agent. The harder, more valuable question is what your agent then does with that data. This post maps the category by what each server actually does, names every tool fairly, and is explicit about what each one is not for, including Rampify. If you take one idea away: the gap that matters is between the SEO audit and the fix, and the spec-and-commit discipline you already use for code is exactly what closes it. The real split: read vs. act Every SEO MCP server falls into one of four jobs. Get the job right and the tool choice is obvious. The first three buckets are well populated. The fourth is the one most developers actually want and the one the category mostly skips: a server that reads and acts, grounded in your real site, with the discipline of a spec and a commit. Bucket 1: Read-only data layers These are the data vendors. Each is genuinely strong at the data it owns. None of them touch your codebase; they feed your agent facts. DataForSEO MCP The DataForSEO MCP server is the official, open-source (Apache-2.0) bridge to the DataForSEO API. It exposes modular toolsets for SERPs, keyword data, backlinks, on-page, domain analytics, and DataForSEO Labs. Billing is pay-per-call rather than a flat subscription, which makes it a good raw-data primitive: you pay for the queries you run. If you want keyword volume, SERP snapshots, or backlink rows piped into your agent without committing to a seat-based plan, this is the base layer. Ahrefs MCP The official Ahrefs MCP server is a hosted, remote server (available to Lite plans and above) that connects your Ahrefs account to Claude and other clients. Its differentiator is the backlink database, which remains one of the strongest in the industry, plus rank tracking, keyword research, and batch analysis. If backlinks are the question, Ahrefs is the answer. Semrush MCP The official Semrush MCP is available as a Semrush app inside Claude (and ChatGPT) and connects over OAuth with no headers to configure. It exposes Semrush's broad competitive and keyword data: a wide all-rounder when you want one vendor across keywords, competitive analysis, and traffic estimates. SE Ranking MCP The SE Ranking MCP server is the broadest of the data layers, exposing roughly 180 tools across keyword research, backlinks, domain analysis, site audits, SERP analysis, and AI search visibility tracking. The AI-visibility piece (tracking how your brand appears across LLM answer engines) is a notable inclusion if generative-engine visibility is on your radar and you want it inside the same connection as classic SEO data. Google Search Console MCP Your Search Console data is first-party and free, and a community server like AminForou/mcp-gsc (MIT-licensed) brings it into Claude Desktop, Cursor, and other clients: property info, search analytics, URL inspection, and sitemap management. If you only need your own search performance rather than third-party competitive data, this is the cheapest, most direct option. Data layers answer questions; they do not change anything. They are the right tool when the bottleneck is knowing the facts. The moment the bottleneck becomes acting on those facts inside your repo, you are in a different bucket. Bucket 2: Code-aware (read-focused) next-devtools-mcp (Vercel) Vercel's next-devtools-mcp is a different animal. It discovers your running Next.js 16+ dev servers and exposes runtime diagnostics from the built-in MCP endpoint: get page metadata (routes, pages, and component metadata), get errors (build, runtime, and type errors), get logs , and project structure. It is read-focused and Next.js-specific. For an SEO workflow this is the missing link between "the data vendor says page X is thin" and "here is what page X actually renders." It lets your agent see your real generateMetadata output and route map instead of guessing. It does not crawl your live site or pull search data; pair it with a data layer for that. Bucket 3: Content and CMS read-write Frase MCP Frase's MCP server covers the content production lifecycle: research a keyword, generate a brief with target scores, write and optimize the draft, then publish to a CMS. It maps your CMS fields automatically and can push to WordPress, Webflow, Sanity, Wix, or Frase's own CMS, handling metadata and featured images on the way out. Pricing starts around $39/mo. Frase is marketer-first and agency-first, and that is a strength for that audience: it is built around producing and shipping articles, not around your repository. If your "website" is a content site in a CMS and the job is publishing optimized posts, Frase is purpose-built for it. Bucket 4: Read-write into your codebase (dev-first) This is the slot most of the category skips, and it is where Rampify sits. The other servers either read data or write content into a CMS. Rampify reads and acts, and it acts on your actual site and, where you own the code, your repository. Where Rampify fits Rampify crawls your real site (not a cached snapshot), synthesizes the crawl together with keyword data and your Search Console performance, finds where you are weak or invisible (including in AI answers), writes the fix as a feature spec with the affected URLs, and opens it. On a custom-coded site that means a pull request to your repo. On a CMS it means publishing through that CMS's own MCP server, for example the Sanity MCP. Rampify stays surface-agnostic: it is the decision layer, your agent does the writing. Two things make it dev-first rather than another data layer: It is grounded in your site. The keyword data comes built in (via DataForSEO), and your Search Console performance is a built-in tool, so you do not bolt on separate data servers just to get the inputs. One connection carries the data layer and the action layer. It uses the discipline you already have. Rampify tracks the work as feature specs and links the commits that resolve them, the same spec-and-commit loop a developer already lives in. The work does not evaporate at the end of a chat session; it persists as a spec, survives across tools and teammates, and the commit that closes it is attributable. That is the difference between an SEO suggestion and a tracked, verified change. It works in Claude Code, Cursor, VS Code, and claude.ai / Claude Desktop. It connects over OAuth with zero install, and new tools appear without version updates. You do not need an editor to run a Rampify workflow. A content marketer working in claude.ai or Claude Desktop can connect the same OAuth server and run crawl, synthesize, and spec entirely in chat, then publish through a connected CMS MCP. The dev-first loop is the center of gravity, but the surface is editor-agnostic. What Rampify is not Honesty is the whole point of a category map, so this matters: Rampify is not a backlink database and not a large-scale rank tracker. If you need deep backlink intelligence, reach for Ahrefs. If you need broad competitive data or enterprise rank tracking, reach for Semrush, SE Ranking, or raw DataForSEO. Rampify complements those data layers; it does not replace them. Its job is acting on SEO inside your workflow, not warehousing the world's link graph. Comparison table Server What it does Read or act Best for -------- -------------- ------------- ---------- DataForSEO MCP Raw keyword, SERP, backlink, on-page data via API (pay-per-call, open source) Read A cheap, flexible raw-data primitive Ahrefs MCP Backlinks, rank tracking, keyword research (official, hosted) Read Best-in-class backlink data Semrush MCP Broad competitive and keyword data (official, OAuth) Read One vendor across keywords and competition SE Ranking MCP ~180 tools incl. AI-visibility tracking (broad all-in-one) Read Wide coverage plus LLM-visibility data Google Search Console MCP First-party search performance, URL inspection, sitemaps Read Your own search data, free next-devtools-mcp (Vercel) Routes, metadata, generateMetadata, errors from your running Next.js dev server Read (code-aware) Seeing what your Next.js app actually renders Frase MCP Briefs, content writing/optimization, CMS publish Read-write (content) Producing and publishing articles Rampify Crawl, synthesize, find gaps, write the spec, open a PR or CMS publish, re-verify Read-write (code-aware, dev-first) Acting on SEO inside your repo and workflow How to choose by use case The tool falls out of the job. Match your bottleneck to the bucket. If the thing you lack is data, pick a data layer. If the thing you lack is changes that actually land, pick a server that acts. Most teams need both, and the two compose: a data MCP for the facts, a read-write server for the action. - You need backlink data or large-scale rank tracking. Use Ahrefs (backlinks) or Semrush / SE Ranking / DataForSEO (broad data and tracking). This is squarely the data layer's job, and it is not Rampify's. - You need raw keyword or SERP data on a pay-as-you-go basis. Use the DataForSEO MCP directly. It is the most flexible primitive when you want to control cost per query. - You only need your own Search Console performance. A free GSC MCP is the most direct path. If you also use Rampify, GSC is already built in. - You want to see what your Next.js app actually renders. Add next-devtools-mcp alongside whatever data and action servers you use. - You produce content in a CMS and want to write and publish from chat. Frase is built for exactly that, marketer-first. - You control your codebase and want to act on SEO fixes, not just read about them. This is the read-write, dev-first slot: Rampify crawls, synthesizes (with DataForSEO keywords and GSC built in), writes the spec, opens the PR, and re-verifies, tracking the work as specs and commits. For the backlink and rank-tracking data it deliberately does not own, pair it with a data vendor above. Frequently asked questions What is the best SEO MCP server? There is no single best one, because the servers do different jobs. For raw data, the strong options are DataForSEO, Ahrefs (backlinks), Semrush, and SE Ranking. For your own search performance, a Google Search Console MCP. For producing and publishing content, Frase. For acting on SEO inside your codebase (crawl, synthesize, spec, open a PR), Rampify. Pick by the bottleneck: data layers answer "what is true," and read-write servers change something. What is the best SEO MCP server for Claude Code or Cursor? If you control your codebase and want your agent to act on fixes rather than just surface data, the read-write, dev-first option is Rampify: it crawls your real site, synthesizes the data with built-in keyword and Search Console inputs, writes the fix as a feature spec, and opens a pull request, all inside Claude Code, Cursor, or VS Code. Pair it with a data vendor (Ahrefs, Semrush, DataForSEO) when you need deep backlink or large-scale rank-tracking data. Vercel's next-devtools-mcp is a useful read-only companion for inspecting your Next.js metadata and routes. Is there a read-write SEO MCP server, or are they all read-only? Most SEO MCP servers are read-only data layers: they bring data into your agent and stop there. Two kinds write. Content-focused servers like Frase write and publish articles into a CMS. Codebase-focused servers like Rampify write the fix as a spec and open it as a pull request to your repo (or publish through a CMS's own MCP). If "read-write" means acting on your actual site and code, Rampify is the dev-first option. Do I need DataForSEO and a separate GSC MCP server too? Not necessarily. If you connect Rampify, it already retrieves your Google Search Console performance and provides keyword data (via DataForSEO) as built-in tools, so you do not need separate servers just for those inputs. You would still add a dedicated vendor for the things Rampify does not own: deep backlink databases (Ahrefs) or large-scale rank tracking (Semrush, SE Ranking, raw DataForSEO). Does Rampify replace Ahrefs or Semrush? No. Rampify is not a backlink database or a large-scale rank tracker, and it does not try to be. For those, Ahrefs and Semrush remain the right tools. Rampify is the read-write, dev-first layer that crawls your site, synthesizes the data, opens the fix as a PR, and re-verifies the change; it complements a data vendor rather than replacing one. Can I use an SEO MCP server without an IDE, from claude.ai? Yes. MCP is not editor-only. A server like Rampify connects to claude.ai and Claude Desktop over OAuth, so a content marketer can run the same crawl, synthesize, spec, and publish workflow in chat without an editor. The dev-first loop is the center of gravity, but the surface is editor-agnostic. To connect it to your editor, follow the connecting guide. For the full tool list and how the crawl-to-verify loop works, see the MCP server overview and the product page. ## The Case Against Using a CMS URL: https://www.rampify.dev/blog/case-against-cms The problem has shifted. In 2010, the hard part was publishing content to the web. CMSs like WordPress, Contentful, and Sanity solved this beautifully with visual editors, media libraries, and one-click publishing. Today, publishing is trivial. AI can generate thousands of words in seconds. What's hard now is getting that content found. And CMSs weren't built for that. The Real Bottleneck Today Let's be honest about what's changed: 2010s problem: - Writing and publishing content was time-consuming - Non-technical people needed visual editors - Managing media and formatting was manual - Getting content online required technical knowledge Today's reality: - AI generates content in seconds - Developers write markdown faster than navigating admin panels - Git-based workflows are superior for version control - Deployment is automated via Vercel, Netlify, Cloudflare The new bottleneck isn't publishing—it's discovery: - Is your content indexed by Google? - Does it have proper schema markup? - Are internal links optimized? - Is the title length correct for mobile? - Are there technical SEO issues preventing ranking? CMSs optimized for the wrong problem. What CMSs Promise vs. What You Actually Get The Promise "Use our CMS and you'll publish content faster, easier, and more beautifully." Visual editors. WYSIWYG formatting. Drag-and-drop media. Instant preview. Beautiful admin panels. The Reality You're locked into their paradigm: - Custom field types (can't easily migrate) - Proprietary APIs (vendor lock-in) - Plugin ecosystems (bloat and security risks) - Database schemas (not portable) - Hosting requirements (performance overhead) You optimize for publishing, not discovery: - No built-in SEO intelligence - Schema markup? Install a plugin (maybe) - GSC integration? Third-party service ($$$) - Internal linking? Manual guesswork - Indexing status? Check weeks later You sacrifice developer velocity: - Navigate admin panel → find post → edit → save → preview → publish - No version control (or clunky git integration) - No local development (or slow Docker setups) - No code review workflow - No deterministic builds The Cost of Convenience CMSs sell you on convenience. But what's the actual cost? 1. Vendor Lock-In Your content is trapped in their structure: - WordPress custom fields - Contentful content models - Sanity schemas - Prismic slices Migration is painful. You don't own your data in a portable format—you own it in their format. With code-based content (MDX, markdown): - Plain text files in git - Portable between any framework - No vendor lock-in - No API rate limits - No pricing tiers 2. Optimization Happens After Publishing CMS workflow: Write in CMS → Publish → Wait 2 weeks → Check GSC → Notice issues → Return to CMS → Edit → Republish → Wait again The gap between publishing and optimization is measured in weeks. By the time you discover your blog post isn't indexed (no internal links, missing schema, title too long), you've moved on to other work. Fixing it requires context switching back to the CMS, remembering what you were trying to accomplish, and hoping your changes help. Most issues never get fixed. Not because you don't care, but because the friction is too high. 3. The WYSIWYG Theater Let's talk about visual editors. They promise: "See exactly what your content will look like!" They deliver: A rough approximation that breaks on different screen sizes, doesn't match your production styles, and adds hidden formatting cruft. The reality: - Developers want markdown or MDX (clean, portable, predictable) - LLMs can generate markdown instantly - Code editors have better autocomplete, search, and refactoring than CMS text fields - Git diff shows you exactly what changed (WYSIWYG doesn't) Visual editors optimize for people who don't code. If you're a developer, they slow you down. 4. Scale Without Strategy CMSs make it easy to publish 1,000 blog posts. But if none of them rank, what did you accomplish? The bottleneck today isn't publishing volume—it's optimizing each piece of content to actually get found. Would you rather have: - 1,000 unoptimized posts (2% indexed, no traffic) - 100 optimized posts (95% indexed, consistent traffic) CMSs optimize for the first. Code + LLM + SDD optimizes for the second. Code + LLM + Spec-Driven Development: The Modern Stack Here's the workflow that actually works today: 1. Write Content in Code // content/blog/my-post.mdx --- title: "How to Optimize Images for SEO" description: "Learn image optimization techniques that improve load times and search rankings." date: "2025-01-09" --- Images are critical for user experience, but unoptimized images slow down your site and hurt SEO. Why Image Optimization Matters [Your content here...] Benefits: - Version controlled (git) - Portable (plain text) - Fast to write (no admin panel navigation) - Code review workflow (PRs, diffs, comments) - Local development (instant feedback) 2. Use LLM + MCP for Real-Time Optimization While writing, ask your AI assistant (via Rampify MCP): Developer: "Check this blog post for SEO issues before I publish" AI: calls get page seo() via MCP "Issues found: 1. Title is 68 characters (recommend 50-60 for mobile) 2. No internal links (reduces indexing probability by 70%) 3. Missing Article schema markup Want me to suggest internal links based on your existing content?" Developer: "Yes" AI: calls suggest internal links() "Based on content analysis, link to: 1. 'image compression' → /blog/image-compression-guide 2. 'Core Web Vitals' → /blog/core-web-vitals 3. 'lazy loading' → /blog/lazy-loading-images Want me to add these links to your markdown?" Developer: "Yes, and generate Article schema" AI: calls generate schema() "Added schema to frontmatter. Your post is now optimized. Ready to commit?" What just happened: - Real-time SEO intelligence (no context switching) - Deterministic data from Rampify API (not LLM hallucinations) - Automated optimization (schema, links, meta tags) - Fixed before publishing (not weeks later) Total time: 3 minutes CMS equivalent: 30 minutes (if you even remember to check SEO) 3. Deploy with Confidence git add content/blog/my-post.mdx git commit -m "Add image optimization guide with schema and internal links" git push Vercel auto-deploys Post is optimized from day 1 No post-deployment scramble Your content is: - ✓ Indexed quickly (proper internal links) - ✓ Rich result eligible (schema markup) - ✓ Mobile-optimized (correct title length) - ✓ Version controlled (rollback if needed) - ✓ Portable (not locked in) Real-World Workflow Comparison Writing a Blog Post: CMS vs. Code + SDD WordPress/Contentful Workflow: 1. Open browser 2. Navigate to CMS admin panel 3. Login (or refresh session) 4. Click "New Post" 5. Wait for editor to load 6. Write content in WYSIWYG (fight with formatting) 7. Add featured image (upload, wait, crop) 8. Fill in SEO fields manually (guess at character counts) 9. Preview (wait for preview to generate) 10. Notice formatting issues, fix 11. Preview again 12. Publish 13. Wait 2 weeks 14. Check Google Search Console 15. Notice: not indexed (missing internal links) 16. Go back to CMS admin 17. Add links manually 18. Update post 19. Wait another 2 weeks 20. Check again (maybe it's indexed now) Time: 45 minutes initial + 20 minutes fix = 65 minutes Result: Maybe indexed, maybe not --- Code + SDD Workflow: 1. Open VS Code (already open) 2. Create content/blog/my-post.mdx 3. Write content in markdown (fast, clean) 4. Ask AI: "Check SEO before I publish" 5. AI analyzes via MCP, suggests fixes 6. Accept suggestions (links, schema, meta tags added) 7. git commit -m "Add post" and git push 8. Vercel deploys (optimized from day 1) 9. Post gets indexed within 24 hours Time: 10 minutes total Result: Optimized, indexed quickly When CMSs Still Make Sense Let's be honest—CMSs aren't always wrong. There are legitimate use cases: 1. Large Non-Technical Content Teams If you have 50 writers who don't code and won't learn, a CMS might make sense. But consider: - Do you really need 50 writers publishing unoptimized content? - Or 5 developers publishing optimized content with AI assistance? Today, quality quantity. A smaller technical team with LLM + SDD can outperform a large team with a CMS. 2. Clients Who Demand It If you're an agency and your client insists on a CMS (because that's what they know), fine. But educate them: - Show them the velocity difference - Demonstrate real-time SEO optimization - Prove that code-based publishing ranks better Many clients think they need a CMS because that's what everyone uses. Show them there's a better way. 3. E-Commerce with Thousands of SKUs If you're managing 10,000 products with complex inventory, CMSs (or e-commerce platforms) might be necessary. But for marketing content? Use code + SDD for your blog, guides, and landing pages. Let the CMS handle product data. Hybrid approaches work. The Missing Piece: Spec-Driven Development Here's what makes the code-based approach superior today: CMS Approach: - Publish → Wait → Discover issues → Fix → Republish Spec-Driven Development (SDD): - Get context → Optimize → Publish once → Ranks immediately The difference is when you get feedback. CMSs give you feedback weeks later (when GSC finally indexes your content). SDD gives you feedback before you publish (via deterministic SEO intelligence). That's the paradigm shift. You're not guessing. You're not hoping. You're not scrambling post-deployment. You know your content is optimized because AI verified it against real data from Google Search Console, site crawls, and indexing APIs before you committed. The Technical Stack Here's what the modern code-based content stack looks like: Content Layer - MDX or Markdown - Portable, version-controlled content - Frontmatter - Structured metadata (title, description, date, tags) - Git - Version control, rollback, branching Build Layer - Next.js, Astro, or Remix - Modern React frameworks with static generation - Zod - Type-safe frontmatter validation - Tailwind CSS - Utility-first styling - TypeScript - Type safety across the stack Optimization Layer - Rampify MCP Server - Real-time SEO intelligence in your editor - Google Search Console API - Indexing status, coverage, search analytics - AI Assistant (Claude, GPT) - Natural language interface via MCP Deployment Layer - Vercel, Netlify, or Cloudflare - Automated deployment from git - GitHub Actions - CI/CD for automated checks - Edge CDN - Global distribution, instant cache purging No CMS required. The Future Is Code-Driven Today, the advantages of CMSs have evaporated: Publishing is solved → LLMs generate content instantly Visual editing is obsolete → Developers write markdown faster Version control is critical → Git beats CMS revision history Optimization is the bottleneck → CMSs don't help with this The future is: - Code-based content (portable, version-controlled) - LLM-assisted writing (fast, high-quality) - Spec-Driven Development (optimized before publishing) - Deterministic SEO intelligence (not guesses, real data) CMSs optimized for the publishing bottleneck of 2010. Code + LLM + SDD optimizes for the discovery bottleneck. If you're a developer building a content site, marketing site, or blog today— you don't need a CMS. You need git, markdown, an AI assistant, and real-time SEO intelligence. You need Spec-Driven Development. --- Frequently Asked Questions Don't CMSs have SEO plugins? Yes, but they're reactive, not proactive. Yoast SEO (WordPress) checks your content after you write it and gives you a score. It doesn't connect to Google Search Console. It doesn't know if your page is indexed. It doesn't suggest internal links based on your actual content inventory. SDD tools (like Rampify) connect to authoritative data sources and give you real-time intelligence before you publish. What about non-developers on my team? Teach them markdown (it takes 20 minutes). Or, if they refuse, use a hybrid approach: - Developers write optimized content with SDD - Non-technical writers use a lightweight markdown editor (like Obsidian or Notion) - Content goes through git PR workflow with AI optimization before merging You don't need a full CMS to accommodate non-coders. Isn't this just for developers? Yes—and that's the point. Rampify is built for developers. If you're building modern web apps with Next.js, Remix, or Astro, you already know git, markdown, and TypeScript. Why would you add a CMS layer when you can publish directly from code? CMSs made sense when developers needed to hand off content management to non-technical people. Today, with AI assistance, that handoff isn't necessary. What about collaborative editing? Git PRs are collaborative editing. - Branch for new content - Write in your editor - AI optimizes via MCP - Open PR - Team reviews (inline comments) - Merge when ready - Auto-deploy This is better than CMS collaboration because you get: - Code review - Version history - Rollback capability - Automated checks (via GitHub Actions) How do I migrate from a CMS? From WordPress: 1. Export content to markdown (tools exist) 2. Clean up frontmatter 3. Set up Next.js or Astro 4. Deploy to Vercel From Contentful/Sanity: 1. Export via their API 2. Transform to MDX 3. Commit to git 4. Deploy From Webflow: 1. Export HTML 2. Convert to markdown (Pandoc) 3. Rebuild in code 4. Deploy Yes, it's work. But you're investing in portability, not renting from a vendor. Don't CMSs scale better? Publish volume? CMSs win (you can publish 1,000 bad posts faster). Ranking volume? Code + SDD wins (you publish fewer, better-optimized posts that actually rank). Today, ranking matters more than publishing. Conclusion The problem shifted. Publishing is solved. Discovery is hard. CMSs optimized for a bottleneck that no longer exists. If you're a developer today, choose code over CMSs: - Write content in markdown (portable, version-controlled) - Use AI + MCP for real-time optimization (Rampify) - Deploy with confidence (Vercel, Netlify, Cloudflare) - Ship optimized content from day 1 Spec-Driven Development beats CMS-driven publishing. Because today, getting found matters more than getting published. ## I Tried Using Claude for SEO Audits. Here's What Actually Works. URL: https://www.rampify.dev/blog/claude-seo-audits-manual-vs-systematic I've seen the tweets. The LinkedIn posts. The blog articles. "I used Claude Code to audit my website's SEO and it found 23 issues in 5 minutes!" And yeah, it's pretty cool. You paste your HTML, ask Claude to check for SEO issues, and it highlights missing meta tags, duplicate H1s, broken schema markup—all the usual suspects. But here's what those posts don't tell you: This approach breaks down the moment you scale. Let me show you what I mean. And then I'll give you something better— a free Claude Skill we built that makes single-page audits even easier, plus guidance on when you'll need to level up from there. The Manual Audit: Great for Learning, Terrible for Production When you manually audit a page with Claude, you're typically doing something like this: 1. Visit the page in your browser 2. Copy the HTML source 3. Paste it into Claude Code or Cursor 4. Ask: "What SEO issues does this page have?" 5. Get a detailed analysis with recommendations 6. Fix the issues 7. Move to the next page For a single page? This is fantastic. Claude will catch things you'd miss. It understands context. It can explain why something is an issue, not just flag it. But now try this with: - Your entire blog (50+ posts) - A documentation site (200+ pages) - Multiple client sites (thousands of pages) - Pages that change weekly You'll quickly realize: This doesn't scale. The Problems You Hit at Scale Problem 1: No Historical Context You audit a page today. Claude finds 5 issues. You fix 3 of them. Two weeks later, you audit the same page again. Claude has no memory of: - What issues existed before - What you already fixed - What you chose to ignore - Whether new issues appeared You're starting from scratch every time. Problem 2: No Cross-Page Intelligence You ask Claude to audit /blog/post-1 . It finds a missing canonical tag. You ask Claude to audit /blog/post-2 . It finds a missing canonical tag. You ask Claude to audit /blog/post-3 . Same issue. Claude can't tell you: "All 47 blog posts are missing canonical tags." You discover that pattern manually after checking them one by one. Problem 3: No Data Integration Claude can analyze what it sees in the HTML. But it can't tell you: - Which pages Google actually indexed - What queries are driving traffic - Which pages have coverage errors in Search Console - What your click-through rates are You're auditing in a vacuum, without real-world performance data. Problem 4: No Automation You fix an issue. Deploy. Now what? With manual audits, you have to: - Remember to check again after deployment - Manually verify the fix worked - Hope you didn't introduce new issues - Repeat this process for every change There's no continuous monitoring. No alerts. No safety net. Problem 5: Content Optimization ≠ Complete SEO I've seen folks build impressive Claude workflows that handle: - Keyword research - Meta description optimization - Heading structure - Image alt text - Internal linking suggestions This is great! But it's only ~20% of SEO. What about: - Schema markup validation - Mobile usability issues - Core Web Vitals - Indexing status (is Google actually crawling this?) - Coverage errors - Redirect chains - Sitemap issues - Canonical tag problems - Duplicate content detection - Crawl budget optimization Content optimization gets you better on-page SEO. Technical SEO gets you indexed and ranked. Free Gift: Rampify SEO Audit Skill Before we dive into systematic solutions, let's fix the manual audit problem first. We built a free Claude Skill that automates the single-page SEO audit workflow. You can use it right now, for free, with no signup required. What the Skill Does Comprehensive single-page audits in seconds: - ✅ Meta tags validation (title, description, Open Graph) - ✅ Schema.org structured data checking - ✅ Heading structure analysis (H1-H6 hierarchy) - ✅ Image optimization checks (alt text, file sizes) - ✅ Internal and external link analysis - ✅ Mobile responsiveness indicators - ✅ Content quality metrics (word count, readability) - ✅ Page speed signals How to Use Connect Rampify via MCP (see setup above), then: 1. Open any page file (HTML, JSX, MDX, etc.) 2. Say: "Audit this page for SEO" 3. Get a detailed report with actionable recommendations See how to use Claude as an SEO checker for the full workflow. Example output: SEO Audit Report for /blog/post Critical Issues (2): ❌ Missing meta description ❌ Invalid Article schema (missing datePublished) Warnings (3): ⚠️ Title too short (42 chars, recommend 50-60) ⚠️ No alt text on 2 images ⚠️ H2 appears before H1 Recommendations: 1. Add meta description (150-160 chars) 2. Fix Article schema: add "datePublished": "2025-12-05" 3. Extend title to include target keyword What This Skill Does NOT Do And this is important to understand: - ❌ Track issues across multiple pages - ❌ Monitor for regressions after deployment - ❌ Integrate with Google Search Console data - ❌ Prioritize fixes by traffic impact - ❌ Remember what you've already fixed - ❌ Alert you when new issues appear - ❌ Run automatically on a schedule The Skill is perfect for: - Auditing individual pages before publishing - Learning what good SEO looks like - Spot-checking specific pages - Quick validation during development But if you're managing a production site, you'll quickly hit the same scaling problems we discussed earlier. That's where systematic intelligence comes in. What Systematic SEO Intelligence Looks Like Here's what you actually need when you're serious about SEO: 1. Continuous Monitoring, Not One-Off Checks Manual approach: Developer: "Check this page for SEO issues" Claude: "Found 5 issues" Developer: fixes issues Developer: deploys Developer: forgets to re-check Developer: 3 weeks later "Wait, did I fix that?" Systematic approach: System: crawls site daily System: detects 23 issues across 12 pages System: tracks which are new vs recurring System: prioritizes by severity and impact Developer: Gets weekly report with clear action items 2. Pattern Detection Across Your Entire Site Manual approach: - Check page 1: Missing meta description - Check page 2: Missing meta description - Check page 3: Missing meta description - Eventually realize this is a template issue Systematic approach: - Scan 200 pages in parallel - Detect: "47 blog posts missing meta descriptions" - Identify: "All posts created before Nov 2024" - Recommend: "Update blog post template" 3. Integration with Real Search Performance Manual approach: - Claude analyzes HTML structure - No idea if Google actually cares about this page - No data on whether issues correlate with traffic Systematic approach: - Cross-reference with Google Search Console - See: "Page has 1,200 impressions but 0.3% CTR" - Identify: "Low CTR likely due to weak meta description" - Prioritize: This issue costs you ~15 clicks/day 4. Deployment Safety Net Manual approach: - Deploy changes - Hope everything works - Discover issues weeks later when traffic drops Systematic approach: - Pre-deployment scan: "New commit will break schema on 3 pages" - Post-deployment verification: "Confirm all fixes deployed correctly" - Continuous monitoring: "New issue detected on /pricing 2 hours after deploy" The Bridge: How MCP Tools Enable Systematic Audits You don't have to choose between Claude's intelligence and systematic monitoring. That's where the Model Context Protocol (MCP) comes in. MCP tools extend Claude with persistent data and automation capabilities. Here's what that looks like in practice: Instead of Manual Copy-Paste: # Manual way (doesn't scale) 1. Visit page in browser 2. View source 3. Copy HTML 4. Paste into Claude 5. Ask for analysis You Get Automated Intelligence: # Systematic way (scales to thousands of pages) Developer: "What SEO issues does my site have?" Claude (via Rampify MCP): → Queries database of 200 crawled pages → Cross-references with Google Search Console → Returns prioritized list: "Critical: 12 pages with broken schema Warning: 47 posts missing canonical tags Info: 3 pages slow to load ( 3s)" Instead of No Memory: # Manual way Developer: "Check /blog/post" Claude: "Found 5 issues" (no context) You Get Historical Tracking: # Systematic way Developer: "Check /blog/post" Claude (via Rampify MCP): → Compares to last 10 crawls → Returns: "3 new issues since last week: 1. Missing schema (new) 2. Meta description too short (existing) 3. Slow load time (new)" Instead of Guessing Impact: # Manual way Claude: "This page is missing a meta description" Developer: "Okay... how important is that?" You Get Data-Driven Prioritization: # Systematic way Claude (via Rampify MCP): "This page gets 1,200 impressions/month but only 12 clicks (1% CTR). Average for this position is 5%. Recommendation: Update meta description Expected impact: +48 clicks/month" What About Claude Skills? You might be thinking: "Wait, I can build a Claude Skill to automate SEO audits, right?" Yes! And that's actually a step in the right direction. Claude Skills let you package your SEO audit process into a reusable workflow. Some folks are building "SEO Content Optimizer" Skills that handle keyword research, meta description optimization, and heading structure checks. But here's where Skills still hit the same scaling wall: Claude Skills Are Great For: - ✅ Automating repetitive content optimization (meta tags, headings, alt text) - ✅ Standardizing your SEO checklist - ✅ Reducing manual copy-paste work - ✅ Ensuring consistent methodology But Skills Still Require: - ❌ You to trigger them manually for each page - ❌ You to remember which pages need checking - ❌ You to track what's been fixed vs what's still broken - ❌ You to integrate external data (GSC, indexing status) - ❌ You to monitor for regressions after deployment Think of it this way: Claude Skill approach: You: "Run my SEO audit Skill on /blog/post-1" Skill: generates optimization report You: applies fixes You: "Now run it on /blog/post-2" Skill: generates optimization report You: applies fixes ... repeat 47 more times Rampify + MCP approach: System: continuously monitors all 49 posts System: "12 posts need optimization" You: "What should I prioritize?" System: shows impact-based ranking You: "Fix the top 3" Claude (via MCP): applies fixes with your Skill logic System: verifies fixes, tracks completion You can use both! In fact, the ideal setup is: 1. Build Claude Skills for your optimization workflows 2. Use Rampify to know WHEN and WHERE to run them 3. Let Rampify track the before/after state Skills are your execution layer. Rampify is your intelligence layer. When to Use Manual Audits vs Skills vs Systematic Intelligence Use Manual Claude Audits When: - ✅ Learning SEO concepts - ✅ Auditing a single page before launch - ✅ Investigating a specific issue - ✅ One-off client review - ✅ Testing new content types Use Claude Skills When: - ✅ You have a repeatable optimization process - ✅ You're optimizing content frequently (blog posts, product pages) - ✅ You want consistent methodology across pages - ✅ You're okay manually triggering the workflow Use Systematic Intelligence (Rampify) When: - ✅ Managing a production site with 20+ pages - ✅ Running an agency with multiple clients - ✅ Deploying changes weekly - ✅ Tracking SEO performance over time - ✅ Integrating with Google Search Console - ✅ Preventing SEO regressions - ✅ Automating pre-deployment checks - ✅ You want to know WHAT to optimize, not just HOW The Evolution: Start Simple, Scale Smart Here's the realistic path most developers take: Phase 1: Discovery (Manual) "Wow, Claude can audit SEO? Let me try this on my homepage." → You learn what good SEO looks like → You fix obvious issues → You feel productive Phase 2: Scale Wall (Still Manual) "Okay, now let me check all my blog posts..." → You check 5 posts manually → You realize you have 47 posts → You recognize this is tedious → You start skipping pages Phase 3: The Realization "I need this to be automated. I need to track changes. I need real data, not just one-off audits." Phase 4: Systematic Approach → Set up Rampify with MCP integration → One-time crawl of entire site → Continuous monitoring → Pre-deployment validation → Google Search Console integration → Prioritized action items You still use Claude. But now Claude has persistent memory, real data, and automation capabilities. Getting Started: From Manual to Systematic If you're currently doing manual SEO audits with Claude and want to level up: Step 1: Connect the Rampify MCP Server For Claude Code : claude mcp add --transport http rampify https://www.rampify.dev/api/mcp For Cursor , add to .cursor/mcp.json : { "mcpServers": { "rampify": { "type": "http", "url": "https://www.rampify.dev/api/mcp" } } } Authentication happens automatically via OAuth — no API keys to manage. See all setup options for your editor. Step 3: Initial Crawl Instead of manually checking pages: You: "Crawl my site and find all SEO issues" Claude (via MCP): → Discovers 200 URLs from sitemap → Checks each for common issues → Stores results in database → Returns prioritized list "Found 23 issues across 12 pages: - 8 critical (broken schema, 404s) - 12 warnings (missing meta, slow pages) - 3 info (optimization opportunities)" Step 4: Connect Google Search Console Get real performance data integrated with technical audits: You: "What should I optimize first?" Claude (via MCP): → Analyzes GSC performance data → Cross-references with technical issues → Prioritizes by traffic impact "Top 3 priorities: 1. /blog/post-42 - 1,200 impressions, 0.3% CTR → Fix: Update meta description → Impact: +48 clicks/month 2. /docs/api - Position 5.2 for 'api documentation' → Fix: Add FAQ schema → Impact: Could reach position 3 3. /pricing - Broken schema detected → Fix: Correct Product schema syntax → Impact: Restore rich snippets" Step 5: Continuous Monitoring Set up automatic daily or weekly crawls. Get alerts when new issues appear: System: Detects new deployment System: Runs post-deploy scan System: "⚠️ New issue detected 2 hours after deploy: /blog/new-post missing canonical tag" You: "Fix the canonical tag issue on /blog/new-post" Claude: generates fix, applies to code The Bottom Line Manual SEO audits with Claude are powerful for learning and one-off checks. But when you're managing a real site—especially one that changes frequently—you need: - Historical tracking (what changed?) - Pattern detection (what's broken everywhere?) - Real data (what actually impacts traffic?) - Automation (can I prevent issues before deploy?) That's the difference between a cool demo and a production system. You don't stop using Claude. You give Claude superpowers. --- Get Started: Use Claude as Your SEO Checker Ready to go from manual audits to systematic SEO intelligence? Here's how to set up based on your workflow: Use Claude as an SEO Checker Connect Rampify via MCP and Claude becomes a full Claude SEO checker — auditing pages, researching keywords, and tracking rankings from any conversation. Works in claude.ai, Claude Code, Cursor, VS Code, and Windsurf. For MDX & Markdown Content If your content lives in MDX or Markdown files, the MDX SEO Validator validates meta tags, schema markup, and keyword placement before you deploy — like a linter for your content's search performance. For Static Sites & Modern Frameworks Building with Next.js, Astro, or another modern framework without a CMS? See Static Site SEO for how Rampify fills the SEO gaps that appear when you skip the CMS. ## Connecting Google Search Console to Your AI Coding Tools via MCP URL: https://www.rampify.dev/blog/google-search-console-mcp-ai-coding Every developer who cares about SEO has the same workflow problem: the data is in one place (Google Search Console), and the code is in another (your editor). You context-switch between browser tabs, try to remember what you read in the dashboard, and hope you correctly translate "Crawled - currently not indexed" into the right code change. MCP (Model Context Protocol) eliminates this gap. It lets your AI coding tools — Claude Code, Cursor, Windsurf — call external services directly. With the Rampify MCP server, your AI assistant can query Google Search Console data, scan your site for issues, and create structured specs without you ever opening a browser tab. This guide covers what MCP is, how to set it up, and what becomes possible when your AI has access to real search data. What Is MCP? Model Context Protocol (MCP) is an open standard created by Anthropic that lets AI models interact with external tools and data sources. Think of it as an API layer between your AI assistant and the outside world. Without MCP, your AI operates in a sandbox. It can read your files and write code, but it can't check if your pages are indexed, pull your search performance data, or verify that your schema markup is valid. It works from memory and assumptions. With MCP, the AI calls tools that return real data. Instead of guessing what your SEO issues might be, it calls get issues() and knows exactly what's broken. MCP is a general protocol. There are MCP servers for databases, APIs, file systems, and more. The Rampify MCP server specifically connects your AI to SEO intelligence — Google Search Console data, site crawl results, issue detection, and structured specifications. The GSC Workflow Problem (And the Fix) The difference isn't just speed. It's accuracy. When the AI has access to real data, it doesn't hallucinate SEO advice. It tells you exactly which pages have issues, what the issues are, and which files in your codebase need to change. Setting Up the Rampify MCP Server Claude Code Setup (Detailed) # Connect the remote MCP server claude mcp add --transport http rampify \ https://www.rampify.dev/api/mcp \ --header "Authorization: Bearer sk live your api key here" Verify it's registered claude mcp list Cursor / Windsurf Setup (Detailed) // .cursor/mcp.json (or ~/.codeium/windsurf/mcp server config.json) { "mcpServers": { "rampify": { "type": "http", "url": "https://www.rampify.dev/api/mcp", "headers": { "Authorization": "Bearer sk live your api key here" } } } } After adding the configuration, restart your editor. See the MCP Server docs for all supported editors. Example Queries and Responses Here's what real interactions look like. These aren't hypothetical — they show actual tool calls and the kind of data returned. "Which pages aren't indexed?" You: "Which of my pages have Google indexing issues?" AI calls: get search performance() AI: "Based on your GSC data, 12 pages have indexing issues: Critical (not indexed): - /blog/advanced-patterns — Crawled, currently not indexed Likely cause: thin content (342 words, no images) Recommendation: expand content, add internal links - /docs/api/webhooks — Discovered, not crawled Likely cause: low internal link equity (1 incoming link) Recommendation: add links from /docs/api and /docs/overview Warning (declining): - /blog/getting-started — impressions down 34% (last 28 days) Position moved from 5.2 to 8.7 Recommendation: update content, check for competing pages Want me to create specs for these fixes?" "What should I write next?" You: "Based on my search data, what content should I create next?" AI calls: get search performance() AI: "Based on your GSC data (last 28 days): Top content opportunities: 1. 'nextjs metadata api' — position 11.3, 2,400 impressions, 0.8% CTR You're on page 2. A dedicated guide could push this to page 1. Estimated traffic gain: 120-200 clicks/month 2. 'react server components seo' — position 14.7, 890 impressions No existing page targets this. New content opportunity. 3. 'nextjs sitemap' — position 6.1, 3,100 impressions, 3.2% CTR Your existing /blog/nextjs-setup mentions sitemaps briefly. Recommendation: dedicated sitemap guide, link from existing post. Want me to create a feature spec for any of these?" "Scan for issues" You: "Scan my site for SEO issues" AI calls: get issues() AI: "Found 23 issues across your site: Critical (4): - /pricing: missing JSON-LD schema (SoftwareApplication recommended) - /blog/old-post: canonical points to deleted URL - /docs/setup: returns 301 → /docs/getting-started (redirect chain) - /api/health: accidentally indexable (missing noindex) Warnings (11): - 7 pages missing Open Graph images - 3 pages with duplicate meta descriptions - 1 page with title 60 characters Info (8): - 8 images missing alt text Should I create a spec to fix the critical issues first?" "How is this page performing?" You: "How is /blog/spec-driven-development performing in search?" AI calls: get page seo("/blog/spec-driven-development") AI calls: get search performance() AI: "Page analysis for /blog/spec-driven-development: Search performance (last 28 days): - 4,200 impressions, 189 clicks, 4.5% CTR - Average position: 5.8 - Top queries: 'spec driven development' (pos 3.1), 'ai coding methodology' (pos 8.4) Technical SEO: ✓ Meta title: 58 chars (good) ✓ Meta description: 155 chars (good) ✓ Canonical: correct ✓ JSON-LD: Article schema present ✗ Missing: FAQ schema (could improve rich results) ✗ Internal links: only 2 incoming (below average for your site) Recommendation: Add FAQ schema for the definition section and add internal links from /docs/overview and /blog/getting-started." From Data to Specs The real power of MCP isn't just reading data — it's turning data into structured action. When the AI identifies an issue, it can call create feature spec() to create a specification in Rampify with: - Title and description — What needs to be done - Acceptance criteria — How you'll verify the fix - Affected files — Exactly which files to change - Implementation tasks — Step-by-step plan That spec persists. It survives across sessions, tools, and team members. When you come back tomorrow, the AI queries the spec and picks up where you left off. When a teammate opens the project, they see the spec and understand the context. This is spec-driven development — structured specifications driving AI-assisted development instead of ad-hoc prompts. You: "Create a spec for fixing the indexing issues you found" AI calls: create feature spec({ title: "Fix 4 critical indexing issues", description: "Address indexing problems identified from GSC data...", acceptance criteria: [ "All 4 pages return correct indexing signals", "No redirect chains exceed 1 hop", "All public pages have JSON-LD schema", "Scan shows 0 critical issues" ], tasks: [ "Add SoftwareApplication schema to /pricing", "Fix canonical URL on /blog/old-post", "Resolve redirect chain for /docs/setup", "Add noindex to /api/health" ] }) AI: "Spec created: 'Fix 4 critical indexing issues' (ID: spec-42) Ready to implement when you give the go-ahead." Available MCP Tools The Rampify MCP server provides these tools: Tool Purpose ------ --------- get issues Scan a site for SEO issues (meta tags, schema, links, indexing signals) get page seo Detailed SEO analysis of a single page get search performance Google Search Console performance data and content opportunities generate meta Generate optimized meta titles and descriptions based on page content generate schema Generate JSON-LD structured data for a page crawl site Crawl a site and analyze its structure create feature spec Create a structured feature specification get feature spec Retrieve an existing spec by ID Each tool returns structured data that the AI interprets in context. When get issues returns a missing canonical URL, the AI knows to look at your generateMetadata export in the relevant page file. When get search performance shows a ranking drop, the AI cross-references with get page seo to identify potential causes. The real value is in tool composition. A single user question like "why did my traffic drop?" might trigger get search performance() to identify which pages dropped, get page seo() on those pages to check technical SEO, and get issues() for a broader site scan. The AI orchestrates these calls automatically. What Changes When Your AI Has Search Data Without MCP, AI coding assistants give SEO advice based on general knowledge. "You should add meta descriptions." "Consider adding schema markup." Generic, context-free suggestions that may or may not apply to your specific situation. With MCP, the advice is grounded in your actual data: - "Your /pricing page has 8,200 monthly impressions but no SoftwareApplication schema. Adding it could qualify you for rich results and improve CTR." - "Your /blog/react-tutorial dropped from position 4.1 to 7.3 in the last two weeks. The content was last updated 8 months ago. Your competitor's version was updated last month." - "You have 23 pages returning 200 but with noindex — if any of these should be indexed, that's suppressing 4,500 monthly impressions." This is the difference between advice and intelligence. Advice is generic. Intelligence is specific, data-backed, and actionable. ## Google Indexing for Next.js and React: A Developer's SEO Guide URL: https://www.rampify.dev/blog/google-indexing-nextjs-react Next.js gives you the tools to build indexable sites. But having the tools and using them correctly are different things. A surprising number of Next.js applications have indexing problems — dynamic routes missing from sitemaps, client-side navigation that doesn't update metadata, Suspense boundaries that get indexed as loading states. This guide covers how Google actually crawls JavaScript applications, which Next.js rendering strategies work best for SEO, and the specific configuration patterns that prevent indexing problems. If you're building with React and want your pages in Google's index, this is the technical reference. How Google Crawls JavaScript: Two-Phase Indexing Google doesn't just fetch your HTML and call it done. For JavaScript applications, indexing happens in two phases: Phase 1: HTML Crawl. Googlebot fetches the initial HTML response — exactly what curl would return. For server-rendered pages (SSG/SSR), this HTML contains your content. For client-side rendered (CSR) pages, this HTML is often an empty with script tags. Phase 2: JavaScript Rendering. Google places your page in a rendering queue and runs it through a headless Chromium instance (WRS — Web Rendering Service). This executes your JavaScript, waits for the page to settle, and captures the final DOM. The gap between Phase 1 and Phase 2 can be seconds to days . Google prioritizes rendering based on perceived page importance. New pages on low-authority sites may wait in the rendering queue for an extended period. During this time, only the initial HTML is evaluated for indexing decisions. This two-phase process is why rendering strategy matters for SEO. If your critical content is in the initial HTML (SSG/SSR), Google can evaluate it immediately. If it requires JavaScript execution (CSR), Google has to wait for Phase 2 — and might make a preliminary indexing decision based on the empty Phase 1 HTML. Rendering Strategies and SEO Impact Static Site Generation (SSG) — Best for SEO Pages generated at build time. The HTML is complete before any user (or bot) requests it. Google gets the full page on the first fetch. // app/blog/[slug]/page.tsx — SSG with generateStaticParams const posts = await getAllPosts(); return posts.map(post = ({ slug: post.slug })); } const { slug } = await params; const post = await getPost(slug); return ; } SEO advantage: The HTML contains everything. No rendering delay. No JavaScript dependency. Google indexes what it fetches. Server-Side Rendering (SSR) — Good for SEO Pages rendered on each request. Same SEO benefit as SSG (full HTML), but with a response time cost. Use for pages with frequently changing data. // app/dashboard/page.tsx — SSR (dynamic by default when using cookies/headers) const data = await fetchLatestData(); return ; } SEO advantage: Same as SSG for indexing purposes. The trade-off is server cost and TTFB. For pages where freshness matters more than performance (stock prices, inventory counts), SSR is the right choice. Client-Side Rendering (CSR) — Worst for SEO Content loaded via JavaScript after the initial HTML. Requires Google's Phase 2 rendering to see any content. // This pattern is problematic for SEO 'use client'; const [product, setProduct] = useState(null); useEffect(() = { fetch('/api/product/123').then(r = r.json()).then(setProduct); }, []); if (!product) return Loading... ; return {product.name} ; // Google's Phase 1 sees: Loading... // Google's Phase 2 sees: Product Name // If Phase 2 is delayed, Google may index the loading state } Google can render JavaScript. CSR pages do get indexed. But they're indexed less reliably and less quickly than server-rendered pages. For pages where search visibility matters — blog posts, product pages, landing pages — never rely on CSR alone. Next.js App Router SEO Checklist 1. Metadata API Next.js 13+ provides a built-in Metadata API. Use it for every page that should be indexed. // app/blog/[slug]/page.tsx { params }: { params: Promise } ): Promise { const { slug } = await params; const post = await getPost(slug); return { title: post.title, description: post.description, alternates: { canonical: https://example.com/blog/${slug} }, openGraph: { title: post.title, description: post.description, type: 'article', publishedTime: post.date, url: https://example.com/blog/${slug} , images: [{ url: post.ogImage, width: 1200, height: 630 }] }, twitter: { card: 'summary large image', title: post.title, description: post.description, images: [post.twitterImage] } }; } 2. sitemap.ts Dynamic sitemap generation ensures every published page is discoverable: // app/sitemap.ts const posts = await getPublishedPosts(); const docs = await getDocPages(); return [ { url: 'https://example.com', lastModified: new Date(), priority: 1.0 }, { url: 'https://example.com/pricing', lastModified: new Date(), priority: 0.9 }, ...posts.map(post = ({ url: https://example.com/blog/${post.slug} , lastModified: new Date(post.updatedAt), priority: 0.7 })), ...docs.map(doc = ({ url: https://example.com/docs/${doc.slug} , lastModified: new Date(doc.updatedAt), priority: 0.6 })) ]; } 3. robots.ts Control what Google can and can't crawl: // app/robots.ts return { rules: [ { userAgent: ' ', allow: '/', disallow: ['/api/', '/dashboard/', '/settings/'] } ], sitemap: 'https://example.com/sitemap.xml' }; } 4. Canonical URLs Every indexable page needs a canonical URL. In Next.js, use the alternates field in Metadata: // This prevents duplicate content issues from: // - www vs non-www // - Trailing slash variations // - Query parameter variations // - HTTP vs HTTPS alternates: { canonical: 'https://example.com/blog/my-post' // always absolute, always HTTPS } }; 5. JSON-LD Structured Data Add schema markup for rich results in Google Search: // app/blog/[slug]/page.tsx const { slug } = await params; const post = await getPost(slug); const jsonLd = { '@context': 'https://schema.org', '@type': 'Article', headline: post.title, description: post.description, datePublished: post.date, dateModified: post.updatedAt, author: { '@type': 'Organization', name: 'Your Team' }, publisher: { '@type': 'Organization', name: 'Your Company', logo: { '@type': 'ImageObject', url: 'https://example.com/logo.png' } }, image: https://example.com${post.ogImage} , mainEntityOfPage: https://example.com/blog/${slug} }; return ( < {post.title} ); } Common Next.js Indexing Problems Problem 1: Dynamic Routes Not in Sitemap If you use dynamic routes ( [slug] , [id] ) but don't implement generateStaticParams or include them in your sitemap, Google has to discover these URLs through crawling alone. Newly added pages may take weeks to be found. Fix: Always pair dynamic routes with either generateStaticParams (for SSG) or explicit sitemap inclusion: // If you can't use generateStaticParams (too many pages, data changes too often), // at least include all URLs in sitemap.ts const allProducts = await getAllProductSlugs(); // even dynamic ones return allProducts.map(slug = ({ url: https://example.com/products/${slug} , lastModified: new Date() })); } Problem 2: Client-Side Navigation Without Metadata Updates Next.js client-side navigation (via ) doesn't trigger a full page load. If your metadata relies on client-side state rather than the Metadata API, Google won't see updated titles and descriptions when crawling. Fix: Always use the server-side Metadata API ( generateMetadata or metadata export). Never rely on useEffect to set document.title for pages that need to be indexed. // BAD: Client-side title update 'use client'; useEffect(() = { document.title = product.name; }, [product]); // GOOD: Server-side metadata const { id } = await params; const product = await getProduct(id); return { title: product.name, description: product.description }; } Problem 3: Suspense Loading States Getting Indexed Next.js Suspense boundaries render a fallback while data loads. If Google's renderer encounters a Suspense boundary that hasn't resolved, it may index the fallback content instead of the actual content. // RISKY: If Google renders before Suspense resolves Loading product details... } // SAFER: Move the data fetch to the page level (server component) const { id } = await params; const product = await getProduct(id); // resolves before HTML is sent return ; } Use URL Inspection in Google Search Console to see exactly what Google rendered. Click "View Crawled Page" then "Screenshot" to see Google's view. If you see loading spinners or skeleton screens, your Suspense boundaries are being indexed before resolving. Problem 4: Redirect Chains from Trailing Slashes Next.js can be configured to add or remove trailing slashes. If your configuration doesn't match your canonical URLs and internal links, you get redirect chains that waste crawl budget. // next.config.ts const nextConfig = { trailingSlash: false, // or true — pick one and be consistent // If trailingSlash: false, ensure: // - Canonical URLs don't have trailing slashes // - Internal hrefs don't have trailing slashes // - Sitemap URLs don't have trailing slashes }; The redirect chain problem: /blog/my-post/ → 308 → /blog/my-post → 200 Google follows the redirect, but each hop costs crawl budget. If you have thousands of pages with trailing slash mismatches, the wasted budget adds up. Problem 5: Missing Image Alt Text and Dimensions Images without alt text miss an indexing signal, and images without width / height cause layout shift (hurting Core Web Vitals): // BAD // GOOD — Next.js Image component handles this React SPAs: Hard Mode If you're building a pure React SPA (Create React App, Vite, etc.) without a server-rendering framework, SEO is significantly harder. The core problem: Your initial HTML is an empty shell. Google must render JavaScript to see any content. While Google can do this, it's slower and less reliable than server-rendered HTML. Options for React SPAs: 1. Migrate to Next.js — The most reliable solution. Next.js gives you SSG/SSR with minimal changes to your React components. 2. Pre-rendering service — Tools like Prerender.io serve a cached, rendered version of your page to bots. Adds latency and a dependency. 3. Static pre-rendering at build time — Tools like react-snap crawl your SPA at build time and save the rendered HTML. Works for content that doesn't change per-user. 4. Accept the limitation — For internal dashboards and authenticated apps, SEO doesn't matter. Use CSR without guilt. Not every page needs to be indexed. Authenticated dashboards, admin panels, user settings — these should be behind a login and excluded from indexing via noindex or robots.txt . Don't add SSR complexity for pages that search engines shouldn't see. Monitoring with Rampify Rampify's MCP tools are built for exactly this workflow — catching Next.js indexing problems from your editor: # In Claude Code or Cursor "Scan my Next.js site for SEO issues" AI calls get issues() → returns: - Pages missing metadata - Missing canonical URLs - Pages not in sitemap - Broken internal links - Missing JSON-LD schema - Missing image alt text "Check my GSC data for indexing problems" AI calls get search performance() → returns: - Pages crawled but not indexed - Rendering issues detected - Pages with declining impressions - Opportunities based on search data The MCP server knows your codebase structure. When it identifies a missing generateMetadata export, it can tell you the exact file path and show you the implementation pattern. No context-switching to a dashboard. No guessing which files to change. For the complete MCP setup, see Connecting GSC to Your AI Coding Tools via MCP. For understanding the broader indexing landscape, start with our Google Indexing developer guide. ## Submit URL to Google: Indexing API, IndexNow, and What Actually Works URL: https://www.rampify.dev/blog/submit-url-to-google You published a new page. You want it in Google's index. The question is: how do you tell Google it exists, and how fast will it actually get indexed? There are three mechanisms for notifying search engines about new or updated URLs: sitemaps (passive), the Google Indexing API (active, limited), and IndexNow (active, broad). Each has trade-offs in speed, reliability, scope, and implementation complexity. This guide covers all three with honest assessments. No "just submit your sitemap and wait" hand-waving. If you need a page indexed fast, you need to understand what actually works and what's marketing. The Three Submission Methods Sitemaps: The Foundation Every site should have a sitemap. It's the baseline that makes everything else work better. How Sitemaps Work An XML sitemap lists your URLs with optional metadata (last modified date, change frequency, priority). Search engines discover your sitemap through robots.txt or direct submission in their webmaster tools. https://example.com/blog/new-post 2026-04-05 monthly 0.8 Dynamic Sitemaps in Next.js If you're using Next.js App Router, generate your sitemap dynamically: // app/sitemap.ts // Fetch all published blog posts from your CMS or database const posts = await getPublishedPosts(); const blogUrls = posts.map(post = ({ url: https://example.com/blog/${post.slug} , lastModified: new Date(post.updatedAt), changeFrequency: 'monthly' as const, priority: 0.7 })); const staticPages = [ { url: 'https://example.com', lastModified: new Date(), priority: 1.0 }, { url: 'https://example.com/pricing', lastModified: new Date(), priority: 0.9 }, { url: 'https://example.com/docs', lastModified: new Date(), priority: 0.8 }, ]; return [...staticPages, ...blogUrls]; } Google uses lastmod to prioritize which URLs to re-crawl. If you update a page but don't update lastmod , Google may not re-crawl it for weeks. changefreq and priority are largely ignored by Google — focus on accurate lastmod dates. Sitemap Limitations Sitemaps are a hint , not a directive. Google is not obligated to crawl URLs in your sitemap, and having a URL in your sitemap doesn't guarantee indexing. Sitemaps help Google discover URLs more efficiently, but the decision to crawl and index is still based on Google's assessment of quality and crawl budget. Time to crawl after sitemap update: Minutes to weeks, depending on your site's crawl frequency. High-authority sites see sitemap changes processed within hours. New or low-authority sites may wait days. Google Indexing API: Fast but Limited The Google Indexing API was designed for job posting and livestream content . Google explicitly states this in their documentation. However, many developers use it for general content — with mixed results. What the Indexing API Does You send a URL to Google with a notification type ( URL UPDATED or URL DELETED ), and Google adds it to a priority crawl queue. const auth = new google.auth.GoogleAuth({ keyFile: './service-account.json', scopes: ['https://www.googleapis.com/auth/indexing'] }); const indexing = google.indexing({ version: 'v3', auth }); async function notifyGoogle(url: string) { const response = await indexing.urlNotifications.publish({ requestBody: { url, type: 'URL UPDATED' } }); return response.data; // { urlNotificationMetadata: { url, latestUpdate: { type, notifyTime } } } } Setup Requirements Service Accounts. Download the JSON key file. This is different from OAuth2 — no user interaction required." }, { title: "Enable the Indexing API", description: "Under APIs & Services Library, search for 'Indexing API' and enable it for your project." }, { title: "Add the service account to GSC", description: "Copy the service account email (ends in @...iam.gserviceaccount.com). In Search Console, go to Settings Users and permissions, and add it as an Owner. Yes, it must be Owner — Contributor isn't sufficient." }, { title: "Submit URL notifications", description: "Use the API to send URL UPDATED notifications. Google places these URLs in a priority crawl queue, typically processing them within minutes to hours." } ]} / The Honest Assessment Google's documentation states the Indexing API is for pages with JobPosting or BroadcastEvent schema. Using it for other content types works (Google will crawl the URL), but there's no guarantee of faster indexing than sitemaps for non-job-posting content. Some SEOs report significantly faster indexing; others see no difference. Your mileage will vary based on your site's authority and Google's current prioritization. Rate limits: 200 URL notifications per day. Batch requests can submit up to 100 URLs per call, but the daily limit still applies. Speed: For job postings, indexing typically happens within minutes. For other content types, it ranges from hours to days — sometimes no faster than a sitemap update. Risk: Using the API for non-supported content types doesn't violate any TOS, but Google could tighten enforcement at any time. Don't build a critical workflow that depends on this working for blog posts. IndexNow: The Open Alternative IndexNow is an open protocol supported by Bing, Yandex, Seznam.cz, Naver, and Yep . Google does not participate. How IndexNow Works You generate a key, host it as a text file on your site, and send HTTP POST requests to notify engines about URL changes. // Generate a key (any UUID-like string works) const INDEXNOW KEY = 'a1b2c3d4e5f6g7h8'; // Host the key file at: https://example.com/a1b2c3d4e5f6g7h8.txt // The file should contain just the key: a1b2c3d4e5f6g7h8 async function submitToIndexNow(urls: string[]) { const response = await fetch('https://api.indexnow.org/indexnow', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ host: 'example.com', key: INDEXNOW KEY, keyLocation: https://example.com/${INDEXNOW KEY}.txt , urlList: urls // up to 10,000 URLs per request }) }); return response.status; // 200 = accepted, 202 = accepted (async) } IndexNow in Next.js Create an API route that fires IndexNow on publish: // app/api/indexnow/route.ts const INDEXNOW KEY = process.env.INDEXNOW KEY!; const SITE HOST = 'example.com'; const { urls } = await request.json(); if (!urls?.length) { return NextResponse.json({ error: 'No URLs provided' }, { status: 400 }); } const response = await fetch('https://api.indexnow.org/indexnow', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ host: SITE HOST, key: INDEXNOW KEY, keyLocation: https://${SITE HOST}/${INDEXNOW KEY}.txt , urlList: urls }) }); return NextResponse.json({ status: response.status, submitted: urls.length, message: response.status === 200 ? 'Accepted' : 'Queued' }); } IndexNow Advantages - No rate limits for practical purposes (10,000 URLs per request) - Multi-engine — One submission notifies all participating engines - Free — No API costs, no OAuth setup - Simple — Just an HTTP POST with a key file for verification IndexNow Limitations - Google doesn't support it. This is the biggest limitation. If Google is your primary traffic source, IndexNow doesn't help with Google indexing. - Bing's market share is ~3% in most markets. IndexNow is valuable for Bing SEO, but the traffic impact is smaller than Google. - No feedback — IndexNow returns 200 (accepted) but doesn't tell you if the URL was actually crawled or indexed. URL Inspection: The Manual Override For individual URLs, the URL Inspection tool in Google Search Console remains the most reliable way to request indexing from Google. 1. Open Search Console for your property 2. Enter the URL in the inspection bar at the top 3. Wait for the live test to complete 4. Click "Request Indexing" Speed: Typically processed within 24-48 hours. Sometimes faster for high-authority sites. Limit: Approximately 10 requests per day per property. This is a manual tool, not a programmatic one (though the URL Inspection API exists for checking status — it does not support requesting indexing). The URL Inspection API lets you check a URL's indexing status, but it does not have an endpoint for requesting indexing. The "Request Indexing" action is only available through the GSC web interface. This is a common misconception. Honest Speed Comparison Based on real-world testing across sites of varying authority: Method Time to Crawl Time to Index Google? Bing? -------- -------------- --------------- --------- ------- Sitemap (new site) 3-14 days 7-21 days Yes Yes Sitemap (established site) 1-24 hours 1-7 days Yes Yes URL Inspection 1-48 hours 1-7 days Yes No Google Indexing API (job posting) 5-60 minutes 1-24 hours Yes No Google Indexing API (other content) 1-48 hours 1-7 days Yes No IndexNow 5 seconds-1 hour 1-24 hours No Yes The takeaway: There's no instant indexing for Google. The fastest reliable path is a combination of an up-to-date sitemap, URL Inspection for priority pages, and patience. For Bing and other engines, IndexNow is dramatically faster. The Optimal Submission Strategy For most sites, the right approach is layered: Automating Submission with Rampify Instead of building and maintaining separate integrations for sitemaps, IndexNow, and indexing monitoring, Rampify handles the pipeline: # In your AI coding tool (Claude Code, Cursor, Windsurf) "I just published a new blog post at /blog/google-indexing-guide. Make sure it's set up for indexing." AI calls get page seo() to verify: - Meta tags are present and optimized - Canonical URL is correct - Page is not accidentally noindexed - JSON-LD schema is valid - Internal links exist from other pages - Page is in the sitemap AI calls get issues() to check for problems: - Missing meta description - Duplicate title tag - Broken internal links - Missing alt text on images If issues are found, AI creates a spec with fixes The key insight: submission is only half the problem. The other half is making sure the page is actually worth indexing before you submit it. A technically perfect submission of a page with missing meta tags, no internal links, and thin content is still going to result in "Crawled - currently not indexed." Rampify's approach combines submission awareness with content quality checks, so you catch problems before Google does. For more on monitoring indexing status programmatically, see our GSC API guide. For fixing pages that were crawled but not indexed, see the dedicated troubleshooting guide. ## Google Search Console API: From Calls to SEO Intelligence URL: https://www.rampify.dev/blog/google-search-console-api-guide The Google Search Console API gives you programmatic access to the same data you see in the GSC dashboard — clicks, impressions, CTR, average position, and indexing status. For developers, this means you can build automated monitoring, regression detection, and content intelligence instead of manually checking a dashboard. But the API has real limitations that Google's documentation glosses over. This guide covers what the API actually gives you, how to set it up with TypeScript, and how to turn raw data into decisions — including when the API isn't enough and what to use instead. What the API Gives You The GSC API exposes two services: Search Analytics API Query performance data for your site across Google Search. Every row represents a combination of dimensions (query, page, country, device, date) with metrics (clicks, impressions, CTR, position). interface SearchAnalyticsRow { keys: string[]; // dimension values clicks: number; // total clicks impressions: number; // total impressions ctr: number; // click-through rate (0.0–1.0) position: number; // average position (1 = top) } What you can query: - Performance by search query ("what keywords bring traffic?") - Performance by page ("which pages are performing?") - Performance by country, device, search type - Date ranges up to 16 months of historical data - Combined dimensions (query + page, page + country, etc.) What you can't query: - Core Web Vitals data (separate API) - Coverage/indexing report data (UI only) - Sitemap status (UI only) - Manual actions (UI only) - Links report (UI only) URL Inspection API Inspect individual URLs to check their indexing status, crawl details, and mobile usability. interface URLInspectionResult { inspectionResult: { indexStatusResult: { verdict: 'PASS' 'PARTIAL' 'FAIL' 'NEUTRAL'; coverageState: string; // "Submitted and indexed", etc. robotsTxtState: 'ALLOWED' 'BLOCKED'; indexingState: 'INDEXING ALLOWED' 'BLOCKED BY META TAG' 'BLOCKED BY HTTP HEADER'; lastCrawlTime: string; pageFetchState: 'SUCCESSFUL' 'SOFT 404' 'BLOCKED ROBOTS TXT'; googleCanonical: string; userCanonical: string; }; mobileUsabilityResult: { verdict: 'PASS' 'FAIL'; issues: Array ; }; }; } URL Inspection is the only API that tells you whether a specific page is indexed and why. Use it for automated monitoring of critical pages. If a page's verdict changes from PASS to FAIL, you know something broke — and the response tells you what. API Limitations You Need to Know Before building anything, understand the constraints: The 2-3 day data lag is the biggest limitation. If you deploy a site change and want to see its impact on search performance, you're waiting at least 48 hours. There's no way around this — Google processes search data in batches. 500 requests per day sounds limiting, but each request returns up to 25,000 rows. If you're strategic about your queries, 500 is plenty for most sites. Sites with 100,000+ pages may need to paginate across days. URL Inspection at 2,000 per day means you can't inspect every page on a large site daily. Prioritize: monitor your top 100 pages by traffic and any recently published content. OAuth2 Setup with TypeScript The GSC API requires OAuth2 authentication. Here's the complete setup: Library." }, { title: "Create OAuth2 credentials", description: "Under APIs & Services Credentials, create an OAuth 2.0 Client ID. Choose 'Web application' type. Add http://localhost:3000/callback as an authorized redirect URI for development." }, { title: "Download the credentials file", description: "Download the JSON credentials file. It contains your client id and client secret. Store these in environment variables, never in source code." }, { title: "Install the googleapis package", description: "Run npm install googleapis to install Google's official Node.js client library. It includes TypeScript definitions." }, { title: "Implement the auth flow", description: "Use the OAuth2 client to generate an auth URL, handle the callback, and exchange the code for tokens. Store the refresh token securely for subsequent requests." } ]} / The Auth Code // lib/gsc-client.ts const oauth2Client = new google.auth.OAuth2( process.env.GOOGLE CLIENT ID, process.env.GOOGLE CLIENT SECRET, process.env.GOOGLE REDIRECT URI // e.g., http://localhost:3000/callback ); // Step 1: Generate the auth URL (send user here) return oauth2Client.generateAuthUrl({ access type: 'offline', // gets a refresh token scope: ['https://www.googleapis.com/auth/webmasters.readonly'], prompt: 'consent' // force consent to always get refresh token }); } // Step 2: Exchange the auth code for tokens (in your callback handler) const { tokens } = await oauth2Client.getToken(code); oauth2Client.setCredentials(tokens); // Store tokens.refresh token securely (database, encrypted env var, etc.) // You'll use this to authenticate future requests without user interaction return tokens; } // Step 3: Create an authenticated client for API calls oauth2Client.setCredentials({ refresh token: refreshToken }); return google.searchconsole({ version: 'v1', auth: oauth2Client }); } The refresh token provides long-lived access to the user's GSC data. Store it encrypted in your database, not in plain text environment variables. If compromised, revoke it immediately at myaccount.google.com/permissions. Practical Use Cases 1. Weekly Performance Report Pull a summary of your site's search performance for the past 7 days vs. the previous 7 days: async function weeklyReport(siteUrl: string, refreshToken: string) { const searchconsole = getSearchConsole(refreshToken); const today = new Date(); // Account for 3-day data lag const endDate = new Date(today.setDate(today.getDate() - 3)); const startDate = new Date(endDate); startDate.setDate(startDate.getDate() - 7); const prevEndDate = new Date(startDate); prevEndDate.setDate(prevEndDate.getDate() - 1); const prevStartDate = new Date(prevEndDate); prevStartDate.setDate(prevStartDate.getDate() - 7); const [current, previous] = await Promise.all([ searchconsole.searchanalytics.query({ siteUrl, requestBody: { startDate: formatDate(startDate), endDate: formatDate(endDate), dimensions: ['page'], rowLimit: 100, type: 'web' } }), searchconsole.searchanalytics.query({ siteUrl, requestBody: { startDate: formatDate(prevStartDate), endDate: formatDate(prevEndDate), dimensions: ['page'], rowLimit: 100, type: 'web' } }) ]); // Compare and identify changes const currentPages = new Map( current.data.rows?.map(r = [r.keys![0], r]) ?? [] ); const previousPages = new Map( previous.data.rows?.map(r = [r.keys![0], r]) ?? [] ); const regressions = []; for (const [page, row] of currentPages) { const prev = previousPages.get(page); if (prev && row.clicks! [ ${r.keys![0]} ${r.keys![1]} , r]) ?? [] ); for (const row of baseline.data.rows ?? []) { const key = ${row.keys![0]} ${row.keys![1]} ; const current = recentMap.get(key); if (current && current.position! - row.position! threshold) { drops.push({ query: row.keys![0], page: row.keys![1], oldPosition: Math.round(row.position! 10) / 10, newPosition: Math.round(current.position! 10) / 10, drop: Math.round((current.position! - row.position!) 10) / 10, impressions: current.impressions }); } } // Sort by impressions (highest impact first) return drops.sort((a, b) = b.impressions! - a.impressions!); } async function queryPeriod( client: any, siteUrl: string, daysAgoStart: number, daysAgoEnd: number ) { const end = new Date(); end.setDate(end.getDate() - daysAgoStart); const start = new Date(); start.setDate(start.getDate() - daysAgoEnd); return client.searchanalytics.query({ siteUrl, requestBody: { startDate: formatDate(start), endDate: formatDate(end), dimensions: ['query', 'page'], rowLimit: 5000, type: 'web' } }); } 3. Content Opportunity Finder Identify keywords where you're ranking on page 2 (positions 11-20) — the closest opportunities to drive new traffic: async function findContentOpportunities( siteUrl: string, refreshToken: string ) { const searchconsole = getSearchConsole(refreshToken); const response = await searchconsole.searchanalytics.query({ siteUrl, requestBody: { startDate: formatDate(daysAgo(30)), endDate: formatDate(daysAgo(3)), dimensions: ['query', 'page'], rowLimit: 10000, dimensionFilterGroups: [{ filters: [{ dimension: 'query', operator: 'excludes', expression: 'brand-name' // exclude branded queries }] }], type: 'web' } }); const opportunities = (response.data.rows ?? []) .filter(row = row.position! = 8 && // page 1 bottom or page 2 row.position! = 100 // enough volume to matter ) .map(row = ({ query: row.keys![0], page: row.keys![1], position: Math.round(row.position! 10) / 10, impressions: row.impressions, clicks: row.clicks, potentialClicks: Math.round(row.impressions! 0.05) // conservative est. })) .sort((a, b) = b.impressions! - a.impressions!); return opportunities.slice(0, 20); } function daysAgo(n: number): Date { const d = new Date(); d.setDate(d.getDate() - n); return d; } 4. Indexing Status Monitor Check the indexing status of your most important pages: async function monitorIndexing( siteUrl: string, urls: string[], refreshToken: string ) { const searchconsole = getSearchConsole(refreshToken); const results = []; // URL Inspection is 1 URL per request, rate limited at 2,000/day for (const url of urls) { try { const result = await searchconsole.urlInspection.index.inspect({ requestBody: { inspectionUrl: url, siteUrl } }); const status = result.data.inspectionResult?.indexStatusResult; results.push({ url, indexed: status?.verdict === 'PASS', coverageState: status?.coverageState, lastCrawl: status?.lastCrawlTime, canonical: status?.googleCanonical }); } catch (error) { results.push({ url, error: (error as Error).message }); } // Respect rate limits — small delay between requests await new Promise(resolve = setTimeout(resolve, 200)); } return results; } From Raw Data to Actionable Intelligence Raw API data tells you what happened. Intelligence tells you what to do about it. The gap between data and action is where most developers get stuck. You can pull 25,000 rows of search analytics, but turning that into "update the meta description on /blog/nextjs-tutorial because CTR is 40% below average for its position range" requires interpretation logic. This is where the API-only approach starts to break down. You need: - Benchmarks — Is a 2.1% CTR good or bad for position 4.5? (It's below average — position 4-5 typically sees 5-7% CTR.) - Historical context — Is this week's performance normal or a regression? - Cross-referencing — A page losing clicks AND dropping in position is different from a page losing clicks at the same position (seasonal vs. ranking issue). - Site-specific patterns — Blog posts behave differently from product pages. Generic benchmarks can mislead. Rampify's MCP server handles the OAuth flow, rate limiting, data normalization, and interpretation layer. Instead of building a custom GSC client, you ask your AI "what should I write next based on search data?" and get an answer with specific page paths and recommendations. See the MCP setup guide for details. Building a GSC Monitoring Pipeline If you want to build your own monitoring on the raw API, here's the architecture: // cron job — runs daily at 6 AM // 1. Pull Search Analytics for the past 7 days // 2. Compare against previous 7 days // 3. Detect regressions (position drops, click drops) // 4. Check indexing status of top 100 pages // 5. Alert on issues (Slack, email, etc.) // Cost: ~110 API calls per day // - 2 Search Analytics queries (current + previous period) // - 100 URL Inspection calls (top pages) // - 8 queries for dimensional breakdowns (device, country, etc.) This works, but it requires maintaining the cron job, the OAuth tokens, the comparison logic, and the alerting pipeline. For a team building an SEO tool, this is core product work. For a developer who wants search visibility into their project, it's overhead. The alternative is to use a service that handles the pipeline and exposes the results through an interface you already use — like your AI coding tool. What the API Doesn't Cover Several important GSC features have no API equivalent: - Page Indexing report — The dashboard view of indexed vs. excluded URLs. No API. - Core Web Vitals — Available through the Chrome UX Report API (separate service), not the GSC API. - Manual actions — Must be checked in the UI. - Sitemaps report — Submission status, error counts — UI only. - Links report — Internal and external links — UI only. - Rich results status — Which pages have valid structured data — UI only. This means even with full API access, you still need to check the GSC dashboard for some things. Rampify supplements the API data with crawl-based analysis to fill some of these gaps — checking structured data validity, internal link structure, and technical SEO issues that the API doesn't expose. ## Crawled Currently Not Indexed: How to Fix Google Indexing Issues URL: https://www.rampify.dev/blog/crawled-currently-not-indexed You open Google Search Console. Navigate to Page Indexing. And there it is: dozens — maybe hundreds — of pages stuck in "Crawled - currently not indexed." Google visited your page. It fetched the HTML. It rendered the JavaScript. And then it decided: not worth indexing. This is the most frustrating status in GSC because it's not a technical error. It's a quality judgment. Google looked at your content and said "no." Understanding why — and what to do about it — is the difference between pages that rank and pages that don't exist in search. What "Crawled - Currently Not Indexed" Actually Means Google's indexing pipeline has distinct stages. When a page is crawled but not indexed , it means: 1. Googlebot discovered the URL (via sitemap, internal link, or external link) 2. Googlebot fetched and rendered the page successfully 3. Google's indexing system evaluated the content 4. The system decided not to add it to the index This is different from technical failures. The page loaded fine. Google just didn't think it was worth storing. "Currently not indexed" includes the word "currently" for a reason. Google re-evaluates pages over time. Improving your content quality, internal linking, or site authority can cause previously skipped pages to be indexed on a subsequent crawl. But waiting passively is rarely the best strategy. Crawled vs. Discovered: Two Different Problems GSC shows two similar-sounding statuses that have very different implications: Discovered - currently not indexed is a resource allocation problem. Google knows about the page but hasn't spent the resources to fetch it. This typically affects large sites (50,000+ URLs) where Google can't justify crawling everything. Crawled - currently not indexed is a quality signal problem. Google spent the resources to fetch your page and decided it wasn't worth indexing. This affects sites of all sizes and is the harder problem to solve. Why Google Refuses to Index Your Pages Google doesn't publish the exact algorithm, but the signals are well-understood from testing and Google's own documentation: Thin content — Pages with little substantive content. Tag pages with 3 posts, empty category pages, stub articles, auto-generated pages with template text but no real information. Duplicate or near-duplicate content — Content that's too similar to another page on your site or elsewhere on the web. Google picks one version to index and skips the rest. Low perceived value — Content that doesn't add anything new to the web. If 50 other pages cover the same topic with the same depth, Google doesn't need yours. Poor internal linking — Pages that are orphaned or only linked from deep navigation. Google interprets link equity as a quality signal. Pages with few internal links are perceived as less important. Site-wide quality issues — If Google's overall assessment of your site quality is low, it raises the bar for individual pages. A site with 80% thin content makes it harder for the remaining 20% to get indexed. Crawl signals — Slow server response times, frequent timeouts, and large page sizes can cause Google to deprioritize your site's crawl. 10 Fixes That Actually Work Fix 1: Content Audit — Be Honest Before trying to force-index pages, ask whether they should be indexed at all. // Common pattern: auto-generated pages with no real content // These tag pages have 0-2 posts each — Google won't index them // BAD: /blog/tags/miscellaneous (1 post, no description) // BAD: /blog/tags/draft-ideas (0 posts) // GOOD: /blog/tags/nextjs (15 posts, custom description, curated order) Action: Export your not-indexed URLs from GSC. Categorize them: - Should be indexed — Has unique content, serves user intent. Fix it. - Should be consolidated — Similar to another page. 301 redirect to the better version. - Should be removed — Thin, auto-generated, no value. Add noindex or delete. Reducing the total number of low-quality pages improves Google's quality assessment of your entire site. Sometimes the best fix for indexing problems is removing pages, not adding content. Fix 2: Add Substantive Content For pages that should be indexed but lack depth: // Example: A product comparison page that's just a table // Google sees a table with no context — not worth indexing // BEFORE: Just a feature comparison table // AFTER: Add 300+ words of context // - What problem does each tool solve? // - Who should use which option? // - Real-world scenarios with recommendations // - Your analysis, not just a data dump Google's helpful content system specifically penalizes pages that pad word count without adding value. 500 words of genuine insight beats 2,000 words of rewritten Wikipedia. Focus on what you uniquely know or can uniquely analyze. Fix 3: Internal Linking Strategy Internal links are the single strongest signal you directly control. Here's a practical approach: // Find your most authoritative pages (highest impressions in GSC) // Link FROM those pages TO your not-indexed pages // Example: Your /blog/nextjs-tutorial page gets 5,000 impressions/month // Add a contextual link: "For production deployments, you'll also want // to configure proper indexing for dynamic routes" // The link passes authority from the high-traffic page to the not-indexed page Rules for effective internal linking: - Link from high-authority pages (check impressions in GSC) - Use descriptive anchor text (not "click here") - Make the link contextually relevant (not forced) - Aim for 3-5 internal links to each not-indexed page Fix 4-6: Technical Checks These are binary — either they're blocking indexing or they're not. Canonical tags: Noindex tags: Robots.txt: # This blocks crawling of the entire /api/ path User-agent: Disallow: /api/ But if you have public API docs at /api/docs, they're blocked too Fix: add an Allow rule above the Disallow Allow: /api/docs Disallow: /api/ Fix 7: URL Inspection — The Manual Override URL Inspection is your direct line to Google's indexing system: 1. Go to GSC and enter the URL in the top search bar 2. Review the current status (live test vs. cached version) 3. Click "Request Indexing" 4. Google adds the URL to a priority crawl queue You can request indexing for approximately 10 URLs per day per property. This is a manual tool, not a bulk solution. For bulk indexing needs, focus on the structural fixes (content, internal links, sitemaps) and let Google's normal crawling handle the rest. For programmatic submission, see our guide to URL submission methods. Fix 8-9: IndexNow and Structured Data IndexNow won't help with Google specifically (Google doesn't participate in the protocol), but it covers Bing and other engines. See our full guide to URL submission for implementation details. Structured data helps Google understand your content's type and purpose: // Next.js App Router — add JSON-LD to your blog layout const jsonLd = { '@context': 'https://schema.org', '@type': 'Article', headline: post.title, description: post.description, datePublished: post.date, author: { '@type': 'Organization', name: 'Your Team' } }; return ( < ); } Monitoring Programmatically Manually checking GSC every week doesn't scale. Here's how to automate it: Option 1: GSC API + URL Inspection const searchconsole = google.searchconsole('v1'); async function checkIndexingStatus(url: string) { const result = await searchconsole.urlInspection.index.inspect({ requestBody: { inspectionUrl: url, siteUrl: 'sc-domain:example.com' } }); const { inspectionResult } = result.data; return { url, verdict: inspectionResult?.indexStatusResult?.verdict, coverageState: inspectionResult?.indexStatusResult?.coverageState, lastCrawlTime: inspectionResult?.indexStatusResult?.lastCrawlTime, robotsTxtState: inspectionResult?.indexStatusResult?.robotsTxtState }; } // Check your critical pages daily const criticalPages = ['/blog/important-post', '/products/main', '/pricing']; for (const page of criticalPages) { const status = await checkIndexingStatus( https://example.com${page} ); if (status.verdict !== 'PASS') { console.warn( Indexing issue: ${page} — ${status.coverageState} ); // Send alert to Slack, email, etc. } } Option 2: Rampify MCP Server # In your AI coding tool "Check which of my pages have indexing issues" AI calls get search performance() and get issues() Returns structured data about: - Pages not indexed - Indexing status changes - Recommended fixes with specific file paths - Option to create a spec for the fix The MCP approach eliminates the boilerplate. No OAuth setup, no API client, no cron job. Ask the question, get the answer, fix the problem — all in your editor. For more on the GSC API, see our complete API guide. For the MCP setup, see Connecting GSC to Your AI Coding Tools. When to Stop Trying Not every page deserves to be indexed. If you've: - Added substantial, unique content - Built internal links from authoritative pages - Fixed all technical issues (canonical, noindex, robots.txt) - Submitted via URL Inspection - Waited 4+ weeks ...and the page is still not indexed, Google has made a judgment about its value. At that point, your options are: 1. Consolidate — Merge the content into a stronger, related page 2. Differentiate — Rewrite with a unique angle that doesn't exist elsewhere 3. Accept — Some pages (pagination, filters, thin archives) aren't meant to be indexed The healthiest sites don't try to index everything. They index their best content and use noindex intentionally on the rest. ## Google Indexing: The Developer's Guide to Search Console URL: https://www.rampify.dev/blog/google-indexing-developer-guide You shipped a feature. The deploy succeeded. Users can reach the page. But Google doesn't know it exists. Google indexing is the process by which Googlebot discovers, crawls, renders, and stores your pages in its search index. If a page isn't indexed, it doesn't rank. It doesn't appear in search results. It might as well not exist for the 8.5 billion daily searches happening on Google. Most developers ignore indexing until something breaks. By then, pages have been invisible for weeks. This guide treats Google Search Console (GSC) like what it actually is: a monitoring system for your site's search infrastructure. We'll cover the data model, the common failure modes, and how to pull GSC data directly into your development workflow. Why Developers Should Care About Indexing Here's the uncomfortable truth: your framework doesn't guarantee indexing. Next.js with SSG? Pages can still be stuck in "Discovered - currently not indexed." A perfectly valid React SPA? Google might render it, or it might not. A site with 10,000 pages? Google's crawl budget means some pages will never be crawled at all. Indexing is a distributed systems problem . Google allocates finite resources (crawl budget) across billions of pages. Your site competes for those resources. The quality of your technical implementation directly affects how much budget Google allocates to you — and whether crawled pages make it into the index. Indexing and ranking are separate processes. A page must be indexed before it can rank, but being indexed doesn't guarantee a good position. Think of indexing as getting your data into the database. Ranking is the query that retrieves it. The Google Search Console Data Model If you think about GSC like a database, the mental model clicks immediately. The Core Tables URL Inspection is the single-row lookup. Given a URL, it returns: interface URLInspectionResult { indexingState: 'INDEXED' 'NOT INDEXED'; crawlState: 'CRAWLED' 'DISCOVERED' 'NOT FOUND'; lastCrawlTime: string; // ISO timestamp canonicalUrl: string; // what Google chose as canonical userCanonical: string; // what you declared robotsTxtState: 'ALLOWED' 'BLOCKED'; pageFetchState: 'SUCCESSFUL' 'SOFT 404' 'REDIRECT' 'NOT FOUND'; verdict: 'PASS' 'PARTIAL' 'FAIL' 'NEUTRAL'; coverageState: string; // "Submitted and indexed", "Crawled - currently not indexed", etc. } Search Analytics is the aggregated query table. It stores impressions, clicks, CTR, and average position — grouped by query, page, country, device, date, or any combination: interface SearchAnalyticsRow { keys: string[]; // dimension values, e.g. ["nextjs seo", "/blog/nextjs-seo"] clicks: number; impressions: number; ctr: number; // 0.0 to 1.0 position: number; // average position in search results } Sitemaps is the registration table. It tracks which sitemaps you've submitted, how many URLs each contains, and when Google last processed them. Coverage (Page Indexing) is the status report. It categorizes every known URL into one of these buckets: - Valid — Indexed and available in search - Valid with warnings — Indexed but with issues - Excluded — Intentionally or unintentionally not indexed - Error — Something is broken The Relationships These tables interconnect. A URL that shows "Crawled - currently not indexed" in Coverage will show indexingState: 'NOT INDEXED' in URL Inspection. A page receiving impressions in Search Analytics is necessarily in the Valid bucket of Coverage. Sitemaps → Coverage → URL Inspection ↘ Search Analytics (only for indexed pages) The Search Console API gives you programmatic access to Search Analytics and URL Inspection. Coverage and Sitemaps are UI-only — you can't query them via API. This limitation is why most automated SEO workflows only operate on partial data. The Five Indexing States (And What Causes Each) Every URL Google knows about exists in one of these states. Understanding them is like understanding HTTP status codes — you need to know what each means to debug problems. 1. Discovered, Not Crawled Google found the URL (via sitemap, internal link, or external link) but hasn't fetched it yet. This is a queue state . Common on large sites where crawl budget is constrained. Fix: Improve crawl budget by fixing broken links, reducing redirect chains, and ensuring your server responds quickly. 2. Crawled, Currently Not Indexed Google fetched the page but decided not to add it to the index. This is the most frustrating state because it means Google evaluated your content and said "no." Thin content, duplicate content, and low perceived value are the usual causes. Fix: See our dedicated guide on fixing crawled-not-indexed issues. 3. Indexed, Not Submitted in Sitemap The page is indexed and appearing in search, but it wasn't in your sitemap. Not an error, but it means your sitemap is incomplete. Google found the page through crawling. Fix: Add the URL to your sitemap. Accurate sitemaps help Google crawl more efficiently. 4. Submitted and Indexed The ideal state. The page is in your sitemap and in Google's index. 5. Excluded (Intentional) Pages excluded by noindex , robots.txt , canonical pointing elsewhere, or redirect. If intentional, no action needed. If accidental, you've found a bug. The Workflow Problem: Dashboard Context-Switching Here's how most developers interact with GSC today: 1. Open search.google.com/search-console 2. Navigate to the right property 3. Click through to Page Indexing 4. Find the problem URL 5. Read the status 6. Switch to your editor 7. Try to remember what you just read 8. Make a fix 9. Go back to GSC 10. Request re-indexing 11. Wait 2-14 days 12. Check again This is the same anti-pattern as checking your database by logging into phpMyAdmin instead of querying it from your application. The data exists. It's just trapped behind a GUI you have to manually operate. The GSC API: Programmatic Access Google exposes two API endpoints that matter: Search Analytics API — Query performance data (clicks, impressions, CTR, position) with filters and grouping. Limited to 25,000 rows per request, 500 requests per day, and data has a 2-3 day lag. URL Inspection API — Check the indexing status of individual URLs. Limited to 2,000 inspections per day per property. // Search Analytics query — TypeScript with googleapis const searchconsole = google.searchconsole('v1'); const response = await searchconsole.searchanalytics.query({ siteUrl: 'sc-domain:example.com', requestBody: { startDate: '2026-03-01', endDate: '2026-03-31', dimensions: ['page', 'query'], rowLimit: 1000, dimensionFilterGroups: [{ filters: [{ dimension: 'page', operator: 'contains', expression: '/blog/' }] }] } }); // response.data.rows contains SearchAnalyticsRow[] For a deep dive into the API, including OAuth2 setup and practical use cases, see our GSC API guide. Bringing GSC Data Into Your Editor via MCP The Model Context Protocol (MCP) lets AI coding tools call external services. Instead of copy-pasting data from dashboards, your AI assistant queries GSC data directly. Rampify's MCP server exposes GSC data through tools your AI can call: # In Claude Code or Cursor "Which of my pages aren't indexed?" AI calls get search performance() → returns: - Pages with indexing issues - Performance trends (clicks, impressions, position) - Content opportunities based on search data - Specific recommendations with file paths This eliminates the context-switching problem. The AI has the data. It knows your codebase. It can suggest specific fixes in specific files. No dashboard tab required. For the complete setup guide, see Connecting GSC to Your AI Coding Tools via MCP. The real power isn't just reading GSC data — it's turning it into structured feature specs. When the AI identifies an indexing issue, it can create a spec with acceptance criteria, affected files, and implementation tasks. That spec persists across sessions and tracks resolution. See spec-driven development for the full methodology. Common Indexing Problems (And Where to Start) JavaScript Rendering Issues Google uses a headless Chromium instance to render JavaScript, but it's not instantaneous. Pages that rely heavily on client-side rendering may be indexed with incomplete content — or not indexed at all. Check: Use URL Inspection in GSC to compare the "Google's view" rendered HTML against your source. If critical content is missing from the rendered version, you have a JS rendering problem. Framework-specific guidance: See Google Indexing for Next.js and React. Crawl Budget Waste Every redirect chain, broken link, and duplicate URL eats crawl budget without adding indexed pages. On large sites (10,000+ URLs), this directly reduces how many of your important pages get crawled. Check: Look at the Coverage report's "Excluded" section. High numbers of "Page with redirect," "Duplicate without user-selected canonical," or "Crawled - currently not indexed" indicate budget waste. Sitemap Problems An outdated or malformed sitemap is like a table of contents that points to the wrong pages. Google trusts your sitemap as a signal of what matters — if it's wrong, crawl priorities are wrong. Check: Verify your sitemap in GSC under Sitemaps. Look for high "Discovered" counts with low "Indexed" counts — that gap represents pages Google found via your sitemap but chose not to index. Forcing Indexing When you need a page indexed now, you have three options: URL Inspection (manual, one-at-a-time), the Google Indexing API (limited to specific schema types), and IndexNow (not supported by Google, but covers Bing and others). Details: See Submit URL to Google: What Actually Works. Monitoring Indexing Health Over Time Indexing isn't a one-time fix. It's an ongoing process that requires monitoring, just like uptime or error rates. Key metrics to track: Index coverage ratio — What percentage of your submitted URLs are actually indexed? A declining ratio means new pages are being excluded faster than old ones are being added. Crawl frequency — How often is Googlebot visiting your site? A drop in crawl frequency can precede indexing problems by weeks. Time to index — How long after publishing does a new page appear in search results? If this increases, something has changed in Google's evaluation of your site quality. Impression trends — Declining impressions for previously stable pages can indicate de-indexing or ranking drops. Rampify tracks these metrics automatically and surfaces them through the MCP server, so your AI assistant can flag regressions before they become traffic problems. Next Steps Google indexing is the foundation that determines whether your pages appear in search. Understanding the data model, the failure modes, and the monitoring strategy gives you the same visibility into search infrastructure that you already have into your application infrastructure. The guides in this series go deeper on each topic: - Crawled Currently Not Indexed: How to Fix It — The most common indexing problem and 10 specific fixes - Google Search Console API Guide — Programmatic access with TypeScript examples - Submit URL to Google — Indexing API, IndexNow, and what actually works - Google Indexing for Next.js and React — Framework-specific SEO guide - Connecting GSC to AI Coding Tools via MCP — Bring search data into your editor ## Spec-Driven Development with Real Data for AI Coding Tools URL: https://www.rampify.dev/blog/data-informed-spec-driven-development There's a pattern emerging in AI-assisted development that nobody has fully named yet. The best AI coding sessions — the ones where the agent produces exactly what you need, first try, with no back-and-forth — share a common trait. They don't start with a vague prompt typed from memory. They start with structured direction grounded in real data. Not "add schema markup to the blog." Instead: "Blog pages at /blog/[slug] are missing Article schema. Google Search Console shows these pages receive 12,000 monthly impressions but have declining CTR. Here's the exact JSON-LD structure needed, the affected files, and the acceptance criteria for verification." The difference in output quality is enormous. And it points to something bigger than a productivity tip. It points to a methodology. The Prompt Problem Today, the standard AI-assisted development workflow looks like this: 1. Developer thinks about what needs to happen 2. Developer types a prompt from memory 3. Agent implements based on that prompt 4. Developer reviews the output 5. Repeat until it looks right Every step depends on the developer's memory, intuition, and attention in that moment. The prompt is improvised. The review criteria are subjective. "Looks right" is the definition of done. This works for simple tasks. It falls apart for anything that requires domain expertise, project-specific context, or verification against external standards. Consider: a developer prompting an agent to "improve the SEO" on a Next.js site. What does the agent do? It adds generic meta descriptions, maybe throws in some Open Graph tags, possibly generates some schema markup. It looks reasonable. It might even pass a Lighthouse audit. But is it right ? Does the schema match Google's current validation requirements? Are the meta descriptions targeting queries that people actually search for? Are the pages even indexed? The agent doesn't know. The developer probably doesn't know either. And neither of them has the data to find out within the context of a coding session. This is the prompt problem: the quality ceiling of AI-generated code is determined by the quality floor of human-provided direction. From Prompts to Specs The first evolution is moving from improvised prompts to structured specifications. Instead of typing what you remember, you create a spec with: - A clear description of what to build and why - Acceptance criteria that define "done" in verifiable terms - Technical constraints and affected files - Version history that preserves original intent This is a significant improvement. The agent receives unambiguous direction. The reviewer has criteria to check against. The spec persists across sessions, so any agent can pick up the work later. But there's a question that specs alone don't answer: where do the specs come from? If the developer writes the spec from memory and intuition, you've formalized the direction but not improved it. You've structured the guess. The acceptance criteria are only as good as the developer's understanding of the domain — which, for specialized areas like SEO, performance, accessibility, or security, may be incomplete. The Data-Informed Leap The real shift happens when specs are informed by — or generated from — actual data. Not data in the abstract sense. Specific, deterministic data about your project: First-party data (your own site): - What pages exist and their current state (crawl data) - HTTP status codes, redirect chains, response times - Schema markup present or missing on each page - Heading structure, meta tags, Open Graph tags - Internal linking patterns - Accessibility violations - Security headers External platform data (how the world sees your site): - Which pages Google has indexed and which it refuses to (Google Search Console) - What queries drive traffic to which pages, with actual click-through rates (GSC Search Analytics) - Which pages lost indexing status this week (GSC state changes) - Keyword search volumes and competitive difficulty (keyword research APIs) - How your content ranks relative to competitors Runtime data (how your site performs): - Core Web Vitals scores per page - Error rates from monitoring - User behavior patterns from analytics Each of these data sources contains signals that should influence development decisions. But traditionally, they sit in separate dashboards that developers rarely check. The data exists. The connection to the development workflow doesn't. Data-informed spec-driven development closes that connection: Data sources → Analysis & prioritization → Structured spec → Agent implementation → Verification against data → Updated spec The spec isn't written from memory. It's generated from evidence. The acceptance criteria aren't subjective. They're derived from the same data that identified the issue. And verification isn't "looks right" — it's a re-check against the data source that confirms the problem is actually resolved. How This Works: A Concrete Example Let's trace the full loop for a real scenario. Step 1: Data collection Rampify crawls your Next.js site and discovers 47 blog posts. It checks each page's HTML structure, schema markup, meta tags, and internal links. Separately, it syncs with Google Search Console and pulls indexing verdicts, coverage states, and search analytics for every URL. Step 2: Analysis and prioritization The system cross-references crawl data with GSC data and identifies: - 12 blog posts have no Article schema (deterministic check) - 8 of those 12 receive more than 1,000 monthly impressions (GSC data) - 3 of the 8 have declining click-through rates over the past 90 days (GSC trend) - Those 3 pages target queries where rich results appear in the SERP (keyword data) Adding Article schema to those 3 pages is the highest-impact action. Not because a developer guessed it — because the data shows it. Step 3: Spec generation A structured specification is created: Title: Add Article schema to high-impression blog posts with declining CTR Description: Three blog posts receive significant search traffic but have declining CTR, likely due to missing rich result eligibility. Adding valid Article schema with the required properties will make these pages eligible for rich results in Google Search. Acceptance criteria: - Each page renders valid JSON-LD with @type: "Article" - Required properties present: headline, datePublished, dateModified, author, image - Schema passes Google's Rich Results Test validation - No existing structured data is broken or duplicated Affected files: app/(marketing)/blog/[slug]/page.tsx , lib/blog/schema.ts Priority: High (data-backed: 3 pages × 1,000+ impressions × declining CTR) The developer didn't write this. They didn't need domain expertise in schema markup requirements. The data identified the issue, the analysis prioritized it, and the spec captured the solution in structured, actionable terms. Step 4: Agent implementation An AI agent reads this spec via MCP. It knows exactly which files to modify, what schema properties are required, and what validation the output needs to pass. It implements the Article schema, runs the rich results test against the output, and commits. Step 5: Verification The system re-crawls the affected pages. It confirms the JSON-LD is present, parses it, validates the required properties, and checks against Google's schema requirements. Acceptance criteria: met. Spec status: verified. If a future code change removes or breaks the schema — a layout refactor, a component migration, a well-meaning agent that "cleans up" the page — the next crawl detects the regression, flags the spec as drifted, and the loop starts again. No step in this process required the developer to have SEO expertise. The data provided the intelligence. The spec provided the direction. The agent provided the implementation. The verification loop provided the quality assurance. The Data Layer Pattern This example uses SEO data, but the pattern is domain-agnostic. Any domain where external data should inform development decisions follows the same structure: Domain Data Sources Example Spec --- --- --- SEO Crawl data, GSC, keyword APIs "Add Article schema to high-impression blog posts" Accessibility axe-core scans, WCAG rules "Fix 23 color contrast violations on checkout flow" Performance Lighthouse, CrUX, RUM data "Reduce LCP on product pages from 4.2s to under 2.5s" Security Dependency scans, header checks "Update 3 critical dependencies with known CVEs" Content Analytics, search intent data "Create hub page for 'deployment guide' cluster — 12 related queries, no existing page" In each case: 1. Data identifies the issue and quantifies its impact 2. Analysis prioritizes based on evidence, not intuition 3. Specs capture the solution in structured, verifiable terms 4. Agents implement with full context 5. Verification confirms against the original data source The developer's role shifts from "know everything about every domain" to "review specs generated from data and approve the ones that matter." This is a fundamentally different — and more scalable — way to build software. Why Data Changes Everything About Specs Without data, a spec is structured intuition. Better than a prompt, but still dependent on what the human knows and remembers. Data transforms specs in four ways: 1. Discovery becomes automatic You don't need to know that Article schema is missing from your blog posts. You don't need to remember to check your GSC coverage states. You don't need to run Lighthouse manually every sprint. The data surfaces issues you didn't know existed — and quantifies ones you vaguely suspected. 2. Prioritization becomes evidence-based Not all issues are equal. A missing meta description on a page with zero traffic is noise. A missing meta description on a page with 10,000 monthly impressions is urgent. Data turns a flat list of issues into a ranked action plan where the most impactful work rises to the top. 3. Acceptance criteria become objective "Improve the SEO" is subjective. "All blog posts render valid Article schema with required properties, verified by Google's Rich Results Test" is objective. When specs are derived from data, the acceptance criteria inherit that objectivity. Verification becomes a data check, not a human judgment call. 4. The feedback loop closes The most powerful property of data-informed specs is that they create a closed loop . The same data source that identified the issue can verify whether the fix worked. Crawl data found missing schema → agent adds schema → crawl data confirms schema is present. No human verification required for the mechanical check. This is what makes the system self-maintaining. Specs don't just capture a point-in-time decision — they establish an ongoing contract between the codebase and the data. When the data says the contract is violated, the system responds. The Three Data Tiers Not all data is equal. There's a natural hierarchy of data sources that informs spec quality: Tier 1: Deterministic first-party data Data you can collect by examining your own site. Crawling pages, parsing HTML, checking HTTP responses. This data is deterministic — it's the same every time you check, and it's unambiguous. A page either has schema markup or it doesn't. A link either returns 200 or it doesn't. This is the foundation. It requires no external accounts, no API keys, no third-party dependencies. Any site can be crawled and analyzed deterministically. Tier 2: Authenticated platform data Data from platforms that see your site from the outside — primarily Google Search Console. This data tells you things you can't learn from crawling alone: how Google interprets your pages, which queries drive traffic, which pages are indexed, which are rejected and why. This is where the intelligence gets powerful. GSC data is authoritative — it's Google telling you directly how it sees your site. But it requires authentication, has API rate limits, and the data needs to be synced and stored to be useful over time. Tier 3: Market and competitive data Data from keyword research APIs, competitor analysis tools, and market intelligence platforms. This data contextualizes your site within the broader landscape — what people search for, how competitors rank, where content gaps exist. This is the strategic layer. It informs not just "fix what's broken" but "build what's missing." It turns specs from reactive (fix this issue) to proactive (capture this opportunity). Each tier builds on the previous: Tier 1: "Your blog posts are missing Article schema" + Tier 2: "...and 8 of them get 1,000+ monthly impressions from Google" + Tier 3: "...and the top queries trigger rich results that competitors have" The spec generated from all three tiers is dramatically more valuable than one generated from any single tier. The data compounds. Building Toward This If this approach resonates, the practical question is: how do you start? Start with Tier 1 data. Crawl your own site. Check for basic issues — missing meta tags, broken links, missing schema, heading structure problems. These are deterministic checks that require no external dependencies and produce immediately actionable specs. Add Tier 2 when you're ready. Connect Google Search Console. Sync indexing data. Cross-reference crawl findings with actual search performance. The prioritization jump from "missing schema on blog posts" to "missing schema on high-traffic blog posts" is where the real value appears. Layer in Tier 3 for strategic work. Keyword data and competitive analysis inform content strategy and opportunity identification. This is less about fixing what's broken and more about building what's missing. At each tier, the workflow is the same: data → analysis → spec → agent implements → verify. The data sources change, the domain expertise deepens, but the pattern holds. The Methodology Data-informed spec-driven development isn't a tool. It's a methodology. The principles: 1. Direction should come from data, not memory. The developer's job is to choose which data-informed specs to pursue, not to generate direction from scratch. 2. Specs should be generated, not written. A conversation between you and your AI agent — informed by actual data — produces a spec. You refine and approve it. You don't start from a blank document. 3. Acceptance criteria should be verifiable against data. If the data source that identified the issue can confirm the fix, the criteria is objective. If it requires human judgment, it should be flagged as such. 4. The loop should be continuous. Verification isn't a one-time step. It's an ongoing process. Data collection runs continuously, specs are monitored for drift, and regressions are caught automatically. 5. Domain expertise is encoded in the system, not required of the developer. The developer doesn't need to know Google's schema requirements, WCAG color contrast ratios, or CVE severity scores. The intelligence layer knows, and the specs it generates reflect that knowledge. This is the evolution of spec-driven development. Spec-driven development brought structured specifications into AI coding workflows. Data-informed specs take the next step: that direction isn't just structured — it's generated from evidence, prioritized by impact, and verified against the same data source that identified the issue. Where This Fits in the Stack In the emerging agentic coding stack, this methodology occupies the intelligence layer — the layer between "manage agents" and "agents write code" that provides structured direction and verification. The layers below (agents, editors, infrastructure) are maturing rapidly and commoditizing. The layer above (developer planning and review) is inherently human. The intelligence layer — where data becomes specs, and specs become verified implementations — is where the leverage is highest and the tooling is least developed. This is also why living specifications matter. A data-informed spec that goes stale is just a better-sourced document that nobody trusts. Living specs — specs that detect drift, update from code changes, and re-verify against data — are what make the methodology sustainable. Data-informed specs aren't a feature. They're the foundation of a development workflow where AI agents reliably build the right thing — not because the developer remembered to tell them, but because the data made it impossible to miss. ## Spec-Driven Development: Living Specs for AI Coding Tools URL: https://www.rampify.dev/blog/living-specs-ai-assisted-development Every codebase has two layers: what the system does and what the system is supposed to do . Today, we only track one of them. The intent behind your code — why this API returns that shape, why this page exists, what problem a feature was solving — lives in Slack threads, pull request descriptions, meeting notes, and people's heads. When those conversations scroll away or those people move on, the intent disappears with them. An AI agent modifying that code six months later has no access to the original intent. It guesses. It breaks assumptions. It rebuilds what already existed. And the developer reviewing its output has no way to evaluate whether the change matches what was originally intended. This is the problem living specifications solve. Why Traditional Specs Fail Developers have resisted specifications for decades, and for good reason. Traditional specs fail in three predictable ways: They're tedious to write Nobody wants to open a document, write acceptance criteria, list affected files, and maintain a structured format before they can start building. The overhead feels disproportionate to the value, especially for smaller features. So people skip it. They go stale immediately A spec written on Monday is outdated by Friday. The code evolves, requirements shift, edge cases emerge during implementation. But nobody goes back to update the spec. Within weeks, the spec describes a version of the feature that no longer exists. They're disconnected from code Even when specs exist, they live in a separate system — Confluence, Notion, Google Docs — with no link to the actual code that implements them. Developers ignore them because they don't trust them. New team members don't even know they exist. The result: Most teams have either no specs (and lose intent) or stale specs (and lose trust). Neither outcome is acceptable when AI agents are writing and modifying code at scale. The Conversational Spec: You Talk, It Writes Here's the key insight that changes everything: you're already describing what you want to build before you build it. Every time you prompt an AI coding agent, you're articulating intent — the problem you're solving, the behavior you expect, the constraints you're working within. That conversation is a specification. It just disappears the moment the context window clears. What if it didn't? With a living spec system, the workflow looks like this: 1. You have a conversation with your AI agent about what you want to build. You discuss the problem, explore approaches, define what "done" looks like. 2. You say "create the spec" and the agent generates a fully structured specification — title, description, acceptance criteria, tasks, affected files — from your conversation. 3. The spec is stored in your project, versioned, and accessible to any agent in any future session. 4. Any agent can read it via MCP and understand not just what to build, but why, with what constraints, and how to verify it's correct. You never open an editor to write a spec. You never manually format acceptance criteria. You never copy-paste between tools. The spec is a natural byproduct of the conversation you were already having. More Than Code: A Shared Language for Every Stakeholder Code is precise, but it's not a shared language. A product manager can't read your React components to understand what a feature does. A QA engineer can't derive test cases from your API routes. A support team member can't explain feature behavior to a customer by reading your codebase. Living specifications fill this gap because they capture intent in structured, human-readable language: - Product teams read specs to verify that what was built matches what was requested - QA engineers use acceptance criteria directly as test cases — they're already written in verifiable terms - Support teams reference specs to understand feature behavior without asking developers - Documentation writers use specs as the starting point for user-facing docs - New developers (and new AI agents) read specs to understand why code exists, not just what it does This is especially critical in AI-assisted development. When you dispatch an agent to modify a feature, the spec gives it the full picture: original intent, acceptance criteria, technical constraints, and the history of how the feature has evolved. Without this, the agent is working from code alone — and code doesn't explain why it exists. What Makes a Spec "Living" A static spec is worse than no spec. It creates false confidence — people trust it, but it describes a reality that no longer exists. A living spec stays true because the system actively maintains it. Drift detection When commits touch files referenced by a spec, the system flags the spec as potentially stale. You already know which files a spec affects and which commits are linked to it. When new commits modify those files outside the spec's context, that's drift. Acceptance criteria verification For specs with testable criteria — "the API returns paginated results," "the page includes structured data markup," "the form validates email format" — an agent can periodically verify them against the current codebase. Failed checks surface immediately. Agent-proposed updates When code changes are detected, an agent reads the diff, compares it to the existing spec, and proposes updates: modified acceptance criteria, new tasks, updated affected files. The human reviews and approves with a glance, creating a new spec version. The spec evolves with the code, automatically. Version history Every update creates a new version. The original intent is always preserved. You can see how a spec has evolved over time — what was added, what changed, what was removed — and understand why. This prevents feature drift and gives you a complete audit trail from initial intent through every iteration. The Closed Loop: From Detection to Verification The real power of living specifications emerges when you close the loop: Detect change → Flag spec drift → Agent proposes update → Human approves → Agent implements → Verify acceptance criteria → Spec is current This is the same pattern that works for automated SEO management: scan a site, detect issues, generate structured action items, implement fixes, verify resolution, rescan. Living specs generalize that loop to any kind of development work. The spec isn't documentation you maintain. It's a feedback loop that maintains itself. What This Means for AI-Assisted Development AI coding agents are powerful but stateless. Each session starts fresh. The context window is the only memory they have, and it's temporary. This means: - Without specs: Every agent session requires the developer to re-explain context, constraints, and intent from scratch. The quality of the output depends entirely on the quality of the prompt in that moment. - With living specs: The agent reads the current spec, understands the full context — original intent, acceptance criteria, version history, linked commits — and picks up exactly where the last session left off. As AI agents handle more of the implementation work, the value of captured intent increases. The spec becomes the durable layer between transient agent sessions — the persistent memory that ensures continuity across any number of agents, sessions, and contributors. Getting Started Living specifications don't require a new process or a cultural shift. They require a system that captures what you're already doing — having conversations about what to build — and keeps that captured intent current as your code evolves. The workflow is simple: 1. Discuss what you want to build with your AI agent 2. Generate the spec from your conversation (one command) 3. Build with any agent that can read the spec via MCP 4. Let the system detect drift and propose updates as code evolves No manual writing. No stale documents. No process overhead. Just intent that persists and evolves alongside your code. ## AI Code Generation Tools: From Copilot to Coding Agents URL: https://www.rampify.dev/blog/agentic-coding-tools-landscape Software development is being restructured around AI agents. Not incrementally — fundamentally. The tools developers use, the workflows they follow, and the skills that matter are all shifting. In less than three years, we've moved from AI suggesting the next line of code to AI autonomously planning, implementing, testing, and iterating on entire features. But the tooling hasn't kept pace with the ambition. Each wave of tools solves one problem while exposing the next. Understanding where we are — and what's still missing — is essential for anyone building or choosing developer tools today. Wave 1: AI-Assisted Code Completion (2021–2023) The promise: AI finishes your code as you type. Key tools: GitHub Copilot, Tabnine, Amazon CodeWhisperer (now Amazon Q Developer), Codeium, Supermaven. GitHub Copilot launched in 2021 and fundamentally changed expectations. For the first time, developers had an AI pair that could suggest entire functions, not just syntax. Tabnine offered self-hosted alternatives for enterprise. CodeWhisperer brought Amazon's models to the mix. Codeium and Supermaven competed on speed and context window size. These tools operated in a simple paradigm: the developer drives, AI assists. You write code, the AI suggests the next chunk. You accept, reject, or modify. The human remains fully in control of architecture, logic, and intent. What this wave solved - Reduced boilerplate typing - Accelerated pattern-based coding (tests, CRUD operations, data transformations) - Made unfamiliar APIs more accessible through contextual suggestions What it didn't solve - No understanding of intent. Copilot didn't know why you were writing a function, only that you'd started one. - No project-level awareness. Suggestions were based on the current file and a limited context window. - No autonomy. Every action still required the developer to initiate and approve, line by line. The ceiling was clear: autocomplete, no matter how intelligent, doesn't change the fundamental nature of the work. The developer still does everything — they just type less. Wave 2: AI-Native Editors and Chat Interfaces (2023–2024) The promise: AI as a conversational coding partner, not just an autocomplete engine. Key tools: Cursor, Windsurf, Zed (AI features), GitHub Copilot Chat, Void, PearAI. Cursor changed the game by forking VS Code and rebuilding the editing experience around AI. Instead of suggestions appearing inline as you type, developers could select code and ask for changes in natural language ("refactor this to use async/await"), generate entire files from descriptions, and chat with an AI that had visibility into their full codebase. Windsurf (from Codeium) and others followed, each with their own take on how deeply AI should be integrated into the editing loop. The key innovation wasn't the model — it was the interface . Chat sidebars, inline edit commands (Cmd+K), multi-file "Composer" agents, and codebase-aware context retrieval. What this wave solved - Multi-file awareness. Editors could reference and modify multiple files in a single operation. - Natural language interaction. Developers described what they wanted instead of writing it. - Iterative refinement. Chat-based interfaces allowed back-and-forth to get the output right. What it didn't solve - Editor lock-in. Moving between Cursor, Windsurf, and VS Code meant losing your AI workflow. - Still human-initiated. Every action started with a developer prompt. The AI couldn't proactively identify work that needed doing. - No persistent memory. Each conversation started fresh. The AI didn't remember yesterday's architectural decisions or last week's refactor. Wave 3: Autonomous Terminal Agents (2024–2025) The promise: AI that doesn't just suggest code — it does the work. Key tools: Claude Code, OpenAI Codex CLI, Google Gemini CLI, Aider, Amp (Sourcegraph). This wave represented a qualitative shift. Terminal agents operate with full shell access — reading files, running tests, executing git commands, installing dependencies, and iterating on errors autonomously. You describe a task, the agent plans an approach, implements it across as many files as needed, runs the test suite, and fixes failures. The developer's role shifts from writing code to reviewing it. Claude Code pioneered the extended-thinking, tool-use loop that defines this category. Aider established the open-source "pair programming in terminal" pattern with tight git integration. Codex CLI and Gemini CLI brought OpenAI and Google's models into the paradigm. Amp focused on enterprise workflows. What this wave solved - End-to-end task completion. Give the agent a task, get back a working implementation. - Autonomous error correction. Agents read error messages, diagnose problems, and fix them without human intervention. - Git-native workflows. Changes are committed, branched, and ready for review. What it didn't solve - Statelessness. Each session starts with amnesia. The agent doesn't know what was decided yesterday, what was already tried and rejected, or what architectural patterns the team chose. - No direction. Agents are exceptional at how to build but have no opinion on what to build or whether the result matches intent. - Review bottleneck. The human must now audit code they didn't write and may not fully understand. Without clear criteria for "correct," review becomes subjective. - Cost and control. Long agentic sessions consume tokens rapidly, and agents running arbitrary shell commands raise safety questions. The industry recognized this as "vibe coding" — a term coined by Andrej Karpathy in early 2025 to describe building software by describing intent in natural language and letting AI handle implementation. It was both celebrated as democratizing and criticized as reckless. The core concern: when nobody understands the code, nobody can fix it when it breaks. Wave 4: Agent Orchestration (2025–2026) The promise: Manage multiple AI agents working in parallel, like a team of developers. Key tools: Vibe Kanban, emdash, Conductor. As terminal agents proved they could reliably complete individual tasks, the natural next step was parallelism. Why run one agent when you could run five, each working on a different feature in an isolated git worktree? Vibe Kanban (from BloopAI) introduced a Kanban board for agent management — launch it with npx vibe-kanban , get a local web UI where you plan tasks, dispatch them to agents, and review output. It uses MCP bidirectionally, meaning agents can read the board and update their own task status. Emdash (YC W26) built a native desktop app supporting 23+ CLI agents, each isolated in git worktrees. It integrates with Linear, GitHub, and Jira, letting you pass tickets directly to agents and review diffs in a unified UI. Conductor (from Melty Labs, YC S24) focused specifically on Claude Code, offering a macOS app for running parallel instances with one-click worktree isolation and a diff-first review interface. What this wave solved - Parallelism. Multiple agents working simultaneously on different tasks. - Isolation. Git worktrees prevent agents from stepping on each other's work. - Visual management. Dashboards and boards replace tracking terminal sessions. - Review workflows. Diff views, PR creation, and merge in one place. What it didn't solve - The "what" problem persists. Orchestration tools manage how agents work, not what they should work on. Dispatching five agents in parallel amplifies both productivity and mistakes. - No verification loop. You can review diffs, but there's no systematic way to verify that what was built matches what was intended. - No persistent intent. When an agent finishes a task, the context — why it was needed, what constraints applied, how it fits into the broader vision — isn't captured anywhere durable. - Coordination without shared context. Isolated worktrees solve merge conflicts but don't solve architectural coherence. Two agents can make contradictory assumptions about data models or API contracts. The Gap: Intelligence, Intent, and Verification Each wave solved a real problem: Wave Solved Shifted bottleneck to --- --- --- Code completion Typing speed Still doing all the thinking AI editors Multi-file changes Editor lock-in, no memory Terminal agents End-to-end implementation What to build, review quality Agent orchestration Parallel execution Direction, verification, coherence Notice the pattern: the bottleneck keeps moving upstream. We started by automating the lowest-level activity (typing) and progressively automated higher-level ones (editing, implementing, coordinating). But the highest-level activities — deciding what to build, capturing why, and verifying that the result matches intent — remain almost entirely manual. This is the gap in the stack. And it manifests as three specific problems: 1. The direction problem Agents need structured, unambiguous direction to produce reliable output. Today, that direction comes from a developer typing a prompt at the start of each session. The quality of the output is entirely dependent on the quality of that prompt, in that moment, from that person's memory. There's no system ensuring that the developer's prompt reflects the team's actual priorities, the project's technical constraints, or the original intent behind a feature. Every agent session is a fresh start, and every prompt is improvised. 2. The intent preservation problem When an agent modifies code, the why behind the original implementation can be silently lost. Comments get rewritten. Architectural decisions get reversed. The codebase drifts from its design intent without anyone noticing — until something breaks and nobody understands why the code was written that way in the first place. Code tracks what the system does . Nothing in the current stack tracks what the system is supposed to do in a way that agents and humans can both access and trust. 3. The verification problem "It works" is not the same as "it's right." An agent can produce code that passes tests while missing the actual requirement. Without structured acceptance criteria — criteria that are machine-readable and verifiable — the review process is subjective. The reviewer is pattern-matching against their own understanding, which may be incomplete or outdated. For domain-specific work (SEO, accessibility, performance, security), verification requires specialized knowledge that the agent doesn't have and the reviewer may not have either. The only reliable approach is automated verification against domain-specific rules. What the Stack Needs: The Intelligence Layer The missing layer sits between orchestration (managing agents) and implementation (agents writing code). Call it the intelligence layer — the system that provides: Structured direction — not improvised prompts, but durable specifications with acceptance criteria, technical constraints, and priority ordering. Specs that any agent can read in any session, ensuring continuity across sessions and contributors. Domain-specific context — real-time intelligence from authoritative sources (search console data, crawl results, performance metrics, security scans) that agents can query at decision time. Not general knowledge, but deterministic data about this specific project . Automated verification — the ability to check whether what was built actually satisfies the requirements. Not just "does it compile and pass tests," but "does it meet the acceptance criteria in the spec" and "does it satisfy domain-specific rules." A closed feedback loop — detection of issues, generation of structured action items, agent implementation, automated verification, and re-detection. A loop that runs continuously, not a one-shot audit. Detection → Structured specification → Agent implementation → Automated verification → Re-detection This is fundamentally different from what any of the four waves provide. Code completion, editors, terminal agents, and orchestration tools are all horizontal — they work on any codebase, any domain, any task. The intelligence layer is vertical — it brings deep, domain-specific understanding that general-purpose tools can't replicate. How This Works in Practice Consider technical SEO — a domain where the gap is especially clear. Without an intelligence layer: A developer prompts an agent: "Add schema markup to the blog pages." The agent generates JSON-LD that looks plausible. It passes the build. Nobody checks whether the markup matches Google's current requirements, whether the page was already indexed with different structured data, or whether the markup conflicts with existing schema on the site. Weeks later, Search Console shows validation errors, but by then the developer has moved on. With an intelligence layer: The system has already crawled the site, analyzed every page's SEO state against current standards, and identified that blog pages are missing Article schema while product pages have outdated Product schema. It has ranked these issues by traffic impact using actual Search Console data. It has generated structured specifications — one for Article schema on blog pages, one for updating Product schema — with acceptance criteria, affected files, and the specific properties Google requires. An agent reads the spec via MCP, implements the schema markup with full awareness of the technical requirements, and commits the changes. The system re-crawls, verifies the markup passes validation, confirms the acceptance criteria are met, and marks the spec as verified. If a future code change removes or breaks the schema, the system detects the regression and flags it immediately. The agent didn't need to know SEO. The intelligence layer provided the domain expertise. The developer didn't need to write a prompt from memory. The spec provided structured direction. And nobody needed to manually verify the result. The feedback loop handled it. The Emerging Stack Here's how the layers fit together: ┌─────────────────────────────────────────────┐ │ Developer (Planning & Review) │ ├─────────────────────────────────────────────┤ │ Agent Orchestration Layer │ │ Vibe Kanban · emdash · Conductor │ │ "Manage how agents work in parallel" │ ├─────────────────────────────────────────────┤ │ Intelligence & Intent Layer │ │ Domain context · Specs · Verification │ │ "What to build, why, and did it work" │ ├─────────────────────────────────────────────┤ │ Agent Implementation Layer │ │ Claude Code · Codex · Gemini CLI · Aider │ │ "Autonomous code generation & iteration" │ ├─────────────────────────────────────────────┤ │ Editor / Interface Layer │ │ Cursor · Windsurf · VS Code · Terminal │ │ "Where developers interact with agents" │ ├─────────────────────────────────────────────┤ │ Codebase & Infrastructure │ │ Git · CI/CD · Cloud · Databases │ └─────────────────────────────────────────────┘ Each layer has a clear responsibility. The editor is the interface. The agents do implementation. Orchestration manages parallelism. The intelligence layer provides direction, context, and verification. The developer sits at the top, making decisions and reviewing results. The layers are complementary, not competitive. A developer using Conductor to manage parallel Claude Code instances can use Rampify's MCP tools to give each agent domain-specific context and structured specs. The orchestration tool decides when and how to run agents. The intelligence layer decides what they should work on and whether the result is correct. This is why the tools that initially look competitive — an SEO intelligence platform and an agent Kanban board — are actually different layers of the same stack. They become more valuable together than either is alone. Where This Is Heading Several trends are converging: MCP as the interop standard. The Model Context Protocol is becoming the common language between layers. Agents read specs and context via MCP. Orchestration tools manage agents via MCP. Intelligence layers expose their data via MCP. This interoperability means developers can assemble their stack from best-of-breed tools rather than being locked into a single vendor's ecosystem. Specs over prompts. The shift from improvised prompts to structured specifications is accelerating. When your AI agent can read a spec with acceptance criteria, affected files, technical constraints, and version history, the output is deterministic and verifiable. When it's working from a one-off prompt, the output is probabilistic and subjective. Teams that adopt spec-driven development will outperform those that don't — not because their agents are better, but because their agents receive better direction. Continuous verification replaces manual review. Human code review doesn't scale when agents produce code faster than humans can read it. The alternative is automated verification against structured criteria — acceptance tests derived from specs, domain-specific rule checks, and regression detection through continuous monitoring. The human reviews the criteria, not every line of code. Domain intelligence becomes a competitive advantage. General-purpose agents are commoditizing. The models get better every quarter, and the orchestration tools are converging on similar patterns. What doesn't commoditize is domain-specific understanding — knowing what Google's current schema requirements are, how search intent maps to content structure, which pages drive traffic and which are technical debt. Teams that connect their agents to domain-specific intelligence will build better software than teams relying on general-purpose agents with generic prompts. What This Means for Developers If you're building with AI agents today, the practical takeaway is this: invest in the layers above the agent, not just the agent itself. The agent is powerful. The orchestrator is helpful. But the quality of what you ship depends on the quality of direction you give, the context you provide, and the verification you apply. These are the layers that are still underbuilt, and they're where the leverage is highest. The agentic coding stack is forming. The bottom layers are maturing. The top layers are just getting started. ## What is Spec-Driven Development? A Complete Guide URL: https://www.rampify.dev/blog/what-is-spec-driven-development Spec-driven development is a software development methodology where structured specifications drive the entire AI-assisted development lifecycle . Instead of describing features in chat and hoping for the best, you define specs with acceptance criteria, affected files, and implementation tasks. AI queries the spec, implements against it, and you verify the result. This is the professional alternative to vibe coding. Models come and go. Prompts are ephemeral. Specs persist across sessions, tools, and team members. Quick Definition Spec-driven development: A methodology where AI coding tools operate against structured specifications rather than ad-hoc prompts. Specs define what to build, acceptance criteria define done, and automated scans verify the implementation. Previously explored as "context-driven development" (CDD), which focused on bringing deterministic context into the editor. Spec-driven development builds on that foundation with a concrete methodology: the spec is the context . The Problem: AI Without Structure AI coding tools are fast. They generate code in seconds. But speed without direction creates a different kind of technical debt. The vibe coding loop: 1. Describe a feature in chat 2. AI generates code 3. It mostly works, but misses edge cases 4. Describe the fix in another chat message 5. AI patches it, breaks something else 6. Repeat until it seems right 7. Ship and hope The result: code that works but nobody understands why. No traceability from requirements to implementation. No way to verify completeness. Context is lost between sessions. A different AI (or teammate) starts from zero. The spec-driven loop: 1. Define a spec with acceptance criteria and tasks 2. AI queries the spec via MCP server, knows exactly what to build and which files to touch 3. AI implements against the spec 4. You commit, and the commit links back to the spec 5. Scan to verify the fix 6. Spec tracks what's done, what's left, and why decisions were made Why Specs, Not Prompts Prompts are instructions for a single moment. Specs are durable artifacts that persist. The difference is structural. A prompt says "fix the SEO." A spec says "add canonical tags to these 4 URLs, verify with a crawl, here are the affected files." How Spec-Driven Development Works The Workflow Define a spec (or let Rampify create one from a scan) AI queries the spec via MCP server, knows what to build AI implements the change You commit, the commit links back to the spec Scan again to verify the fix Manual Specs: You Define What to Build You create a spec when you know what needs to happen. The spec includes a description, acceptance criteria, implementation tasks, affected files, and tech stack. Any AI coding tool can retrieve it via the MCP server and implement against it. "Get the feature spec for auth token expiration" AI: calls get feature spec() "Spec: Implement token expiration logic Acceptance criteria: 1. Tokens expire after 15 minutes 2. Refresh tokens last 7 days 3. Expired tokens return 401 Tasks: 1. Add expiration check in lib/auth.ts 2. Update verify endpoint 3. Add refresh token flow Affected files: lib/auth.ts, app/api/auth/verify/route.ts Starting with task 1..." The AI doesn't guess what to do. It reads the spec and executes. Auto-Generated Specs: Rampify Defines What to Fix Run a scan, and Rampify analyzes your site for real issues. Each issue becomes a spec with affected URLs and fix instructions. No manual triage needed. After scan: - "Missing Canonical Tag" (4 URLs affected) - "Pages Missing Structured Data" (3 URLs affected) - "Meta Description Too Short" (2 URLs affected) Each is a spec your AI can pick up and fix immediately. This is where spec-driven development and AI SEO tools converge. The scan is deterministic (real crawl data, not AI opinions), and the output is a structured spec that any AI coding tool can act on. The Verification Loop After AI implements a fix, you don't just trust it. You scan again. Rampify re-crawls the affected URLs and checks whether the issues are resolved. If they are, the spec is automatically marked as verified. If not, it stays open with updated affected URLs. This closes the loop: define, implement, verify . Core Principles 1. Determinism Over Plausibility Facts must come from crawlers, APIs, and authoritative sources, not LLM weights or training data. When you ask an LLM "is my site SEO-optimized?" without tools, it guesses. It might say "looks good!" without checking anything. With spec-driven development, the AI calls a real tool that crawls your site, queries Google Search Console, and returns measured data. The spec captures what was found and what needs to change. 2. Specs as the Single Source of Truth The spec is the authority. Not the chat log. Not the PR description. Not someone's memory of what was discussed. A spec contains: - What to build (title, description) - Why it matters (context, business value) - How to verify it's done (acceptance criteria) - Where to implement it (affected files, tech stack) - What's next (ordered tasks with dependencies) - What happened (linked commits, progress tracking) When a new developer joins, when you switch AI coding tools, when you resume work after a week, the spec has everything. 3. AI as Interface, Data as Truth AI is a powerful interface. But it should operate on top of structured data, not instead of it. AI excels at natural language understanding, code generation, explaining issues, and recommending approaches. Deterministic systems handle crawling, measuring, validating, and storing facts. Spec-driven development keeps these concerns separate: the MCP server provides real data, the AI provides the interface. 4. Verification Closes the Loop Implementation without verification is just hope. Spec-driven development requires a verification step: scan the site, check the URLs, compare against acceptance criteria. This is what separates a professional workflow from vibe coding. Real-World Example: Fixing SEO Issues Traditional Workflow 1. Run an SEO audit tool in the browser 2. Export a spreadsheet of issues 3. Open your editor 4. Try to remember what the spreadsheet said 5. Fix some issues, miss others 6. Deploy and re-run the audit 7. Discover you missed half the issues 8. Repeat Total time: days. Issues slip through. Spec-Driven Workflow # Run a scan from your editor "Scan my site for SEO issues" AI: calls crawl site() "Scan complete. 3 specs created: 1. Missing Canonical Tag (4 URLs) Fix: Add to /login, /signup, /terms, /privacy 2. Pages Missing Structured Data (3 URLs) Fix: Add JSON-LD schema to /terms, /privacy, /blog 3. Wrong Schema Type on Pricing Page Fix: Replace WebPage with SoftwareApplication + Offer schema Which spec should I start with?" AI implements each fix, you commit, scan verifies Total time: minutes. Nothing slips through. For a complete guide to the technical architecture behind this, see our Spec-Driven Development documentation. Real-World Example: Using GSC Data for Content Decisions Spec-driven development isn't just about fixing bugs. It's about making data-driven decisions in your editor. # In Claude Code or Cursor "What content should I write next based on my search data?" AI: calls get search performance() "Based on your GSC data (last 28 days): Top opportunity: - 'spec-driven development' ranking at position 5.5 - 8,100 impressions, low CTR - Recommendation: Expand content, improve meta description Quick wins: - 'ai seo tools' at position 10.2 (2,900 impressions) - 'mcp server setup' at position 4.5 (low volume but high intent) Want me to create a feature spec for the content update?" The AI retrieved real data from Google Search Console via the MCP server. No guessing. No hallucination. You make decisions based on facts. Setting Up Spec-Driven Development Step 1: Sign Up Create a free account at rampify.dev/signup. Step 2: Install the MCP Server The MCP server connects your AI coding tools to Rampify specs and site intelligence. # For Claude Code claude mcp add --transport http rampify \ https://www.rampify.dev/api/mcp \ --header "Authorization: Bearer sk live your api key here" For Cursor — add to .cursor/mcp.json { "mcpServers": { "rampify": { "type": "http", "url": "https://www.rampify.dev/api/mcp", "headers": { "Authorization": "Bearer sk live your api key here" } } } } Step 3: Install the VS Code Extension Search "Rampify" in the Extensions panel or install from the VS Code Marketplace. Browse specs in the sidebar, copy references into AI chat, and toggle resolved specs. Step 4: Run Your First Scan Ask your AI to scan your site. Rampify creates specs for every issue it finds. Pick one and tell your AI to implement it. Commit the fix. Scan again to verify. That's spec-driven development. Define, implement, verify. Beyond SEO Spec-driven development is a general methodology. Rampify currently implements it for SEO, where scans create specs from real site issues. The same pattern applies to any domain: - Accessibility scanning for WCAG violations, creating specs with affected components - Security scanning for vulnerabilities, creating specs with remediation steps - Performance scanning for Core Web Vitals issues, creating specs with optimization targets The architecture is the same: deterministic scan produces structured findings, findings become specs, AI implements against specs, scan verifies the fix. Frequently Asked Questions How is spec-driven development different from project management tools? Project management tools track work at the team level. Spec-driven development operates at the code level. Your AI coding tool retrieves the spec via MCP server, knows which files to touch, and implements against acceptance criteria. A Jira ticket can't do that. Do I need AI to practice spec-driven development? Specs are useful without AI. But AI makes them dramatically more powerful because the AI can query specs via MCP, understand the full context, and implement against them. Without AI, specs are documentation. With AI, specs are executable instructions. Can spec-driven development work with any AI coding tool? Yes. Any tool that supports the Model Context Protocol (MCP) can query Rampify specs. This includes Claude Code, Cursor, Copilot, and Windsurf. The spec is the structured layer underneath, independent of which model you use. What happened to "context-driven development"? Spec-driven development evolved from context-driven development (CDD), which we introduced in 2025. CDD focused on bringing deterministic context into the editor. Spec-driven development takes that further with a concrete methodology: specs define what to build, acceptance criteria define done, and automated scans verify the result. The context is now structured as specs. Conclusion Spec-driven development represents a shift from ad-hoc AI prompting to structured, verifiable software engineering. Define what to build. Let AI implement against the spec. Verify with a scan. Track everything. The tools exist today. The MCP server connects AI to specs. The VS Code extension puts specs in your sidebar. The scan pipeline creates specs from real site data. Commits link back to specs for full traceability. Stop vibe coding. Start spec-driven development. ## Topic Clusters for LLMs: Hybrid Architecture for AI Search URL: https://www.rampify.dev/blog/hybrid-topic-clusters-llm-seo Google is no longer the only search engine that matters. ChatGPT, Claude, Perplexity, and other LLM-powered search tools are processing your content right now, and they understand structured data differently than Googlebot. Traditional topic cluster implementations fail here. They rely on internal links alone, with no machine-readable relationship data that LLMs can parse. We built a React component that solves this: ContentCluster , a triple-layer architecture that serves Google crawlers, LLMs, and human readers simultaneously. The Problem: Topic Clusters Without Machine-Readable Context Topic clusters are a proven SEO strategy. You create a pillar page that covers a broad topic, then link cluster pages that dive deep into subtopics. Google follows the internal links, understands the topical relationship, and rewards your site with authority. But here's what most implementations miss: LLMs don't navigate your site like Googlebot. They process page content in isolation, often through training data snapshots. Without explicit structured data declaring topic relationships, ChatGPT and Claude have no way to understand that your 15 blog posts form a cohesive content hub on "technical SEO." Consider how these systems process your content differently: The Solution: Triple-Layer Architecture Our ContentCluster component implements three distinct layers, each optimized for a different consumer: This separation of concerns means each layer can be optimized independently. The structured data layer follows Schema.org specifications precisely, the SEO layer maximizes link equity transfer, and the UI layer prioritizes reading experience. Implementation: The ContentCluster Component Here's the complete React component for Next.js: // components/content-cluster.tsx 'use client'; interface ClusterItem { name: string; url: string; position: number; description?: string; } interface ContentClusterProps { pillarPage: { name: string; url: string; description: string; }; clusterItems: ClusterItem[]; currentUrl: string; } pillarPage, clusterItems, currentUrl }: ContentClusterProps) { const [isScrolled, setIsScrolled] = useState(false); const [isExpanded, setIsExpanded] = useState(false); useEffect(() = { const handleScroll = () = { setIsScrolled(window.scrollY 300); }; window.addEventListener('scroll', handleScroll); return () = window.removeEventListener('scroll', handleScroll); }, []); // Filter out current page from cluster items const otherItems = clusterItems.filter( item = item.url !== currentUrl ); // Schema.org ItemList for crawlers and LLMs const schemaData = { '@context': 'https://schema.org', '@type': 'ItemList', name: ${pillarPage.name} Topic Cluster , description: pillarPage.description, itemListElement: [ { '@type': 'ListItem', position: 0, name: pillarPage.name, url: pillarPage.url, description: 'Pillar page for this topic cluster' }, ...clusterItems.map(item = ({ '@type': 'ListItem', position: item.position, name: item.name, url: item.url, ...(item.description && { description: item.description }) })) ] }; return ( < Related Articles on {pillarPage.name} This article is part of our {pillarPage.name} topic cluster. {pillarPage.name} (Pillar Page) {otherItems.map(item = ( {item.name} ))} {isScrolled ? ( // Collapsed badge after scroll setIsExpanded(!isExpanded)} className="bg-[#1e1e1e] border border-[#3e3e42] rounded-full px-3 py-2 text-sm text-[#9d9d9d] hover:border-[#4fc1ff] flex items-center gap-2 shadow-lg" {otherItems.length} related ) : ( // Expanded panel initially visible Topic Cluster {pillarPage.name} {otherItems.slice(0, 3).map(item = ( {item.name} ))} {otherItems.length 3 && ( +{otherItems.length - 3} more articles )} )} {isScrolled && isExpanded && ( Related in {pillarPage.name} Overview: {pillarPage.name} {otherItems.map(item = ( {item.name} ))} )} ); } React escapes HTML entities by default, which breaks JSON-LD parsing. Using dangerouslySetInnerHTML with JSON.stringify ensures the structured data renders correctly. This is safe because we control the input data structure. Understanding the Schema.org ItemList The ItemList schema type explicitly declares a collection of related items. Google uses this for carousels, recipe lists, and how-to steps. For topic clusters, it serves a different purpose: declaring topical authority relationships . Here's what the generated JSON-LD looks like: { "@context": "https://schema.org", "@type": "ItemList", "name": "Technical SEO Topic Cluster", "description": "Complete guide to technical SEO for developers", "itemListElement": [ { "@type": "ListItem", "position": 0, "name": "Technical SEO for Developers", "url": "https://example.com/technical-seo", "description": "Pillar page for this topic cluster" }, { "@type": "ListItem", "position": 1, "name": "Core Web Vitals Optimization", "url": "https://example.com/core-web-vitals" }, { "@type": "ListItem", "position": 2, "name": "Structured Data Implementation", "url": "https://example.com/structured-data" } ] } When LLMs like ChatGPT are trained on web data, they extract structured data alongside page content. An ItemList schema creates an explicit relationship graph that persists through training. When users ask about "technical SEO," the LLM has machine-readable evidence that your content forms a comprehensive cluster on that topic. The sr-only Layer: Link Equity Without Visual Clutter The second layer solves a specific problem: we need internal links for SEO (PageRank transfer), but showing 15 related links would destroy the reading experience. The solution is screen-reader-only content: Related Articles on {pillarPage.name} {otherItems.map(item = ( {item.name} ))} This HTML is: 1. Crawled by Googlebot - All links are followed and counted for PageRank 2. Read by screen readers - Improves accessibility for visually impaired users 3. Invisible to sighted users - The sr-only class hides it visually The Tailwind sr-only utility applies: .sr-only { position: absolute; width: 1px; height: 1px; padding: 0; margin: -1px; overflow: hidden; clip: rect(0, 0, 0, 0); white-space: nowrap; border-width: 0; } This is not hidden content in the "black hat SEO" sense. It's accessible content that serves a legitimate purpose for users who cannot see the visual UI. Usage: Adding ContentCluster to Blog Posts Here's how to integrate the component into your blog layout: // app/blog/[slug]/page.tsx params }: { params: Promise }) { const { slug } = await params; const post = await getPost(slug); const clusterData = await getClusterData(post.cluster); return ( {post.title} {clusterData && ( )} ); } And the cluster data structure: // lib/content-clusters.ts 'technical-seo': { pillarPage: { name: 'Technical SEO for Developers', url: '/blog/technical-seo-guide', description: 'Complete guide to technical SEO implementation' }, items: [ { name: 'Core Web Vitals Optimization', url: '/blog/core-web-vitals', position: 1 }, { name: 'Structured Data Implementation', url: '/blog/structured-data', position: 2 }, { name: 'XML Sitemaps for Large Sites', url: '/blog/xml-sitemaps', position: 3 } ] } }; if (!clusterId) return null; return clusters[clusterId] null; } Validating Your Implementation Before deploying, verify the structured data is correct: Why ItemList Over Other Schema Types? You might wonder why we use ItemList instead of other relationship schemas. Here's the reasoning: Why not isPartOf ? The isPartOf property connects an item to a larger work, like a chapter to a book. It's semantically correct but doesn't create a bidirectional relationship. The pillar page wouldn't know about its cluster items. Why not hasPart ? The hasPart property is the inverse, going from container to contained items. You could add this to the pillar page, but then cluster pages have no machine-readable cluster context. Why not relatedLink ? The relatedLink property doesn't convey hierarchical relationships. Google and LLMs would see the links as loosely related, not as a cohesive topical cluster. Why ItemList works: ItemList creates an explicit collection with ordered positions. The pillar page sits at position 0, cluster items follow. Every page in the cluster can include the same ItemList, creating a network of identical structured data that strongly signals topical cohesion. ItemList complements your existing Article, BlogPosting, or TechArticle schema. Keep your primary content schema intact and add ItemList as an additional signal. Multiple schema types on a single page is valid and encouraged. Measuring Impact Track these metrics after implementing ContentCluster: Search Console Signals: - Impressions for cluster-related queries (should increase as topical authority grows) - Click-through rate on pillar page (often improves as supporting content reinforces authority) - Index status for cluster pages (related content typically gets indexed faster) LLM Visibility: - Ask ChatGPT or Claude about your topic area and see if your content surfaces - Monitor referral traffic from AI-powered search tools (Perplexity, You.com) - Track brand mentions in LLM responses using monitoring tools User Engagement: - Time on site for users who navigate through cluster links - Pages per session from cluster entry points - Conversion rate from pillar pages vs. standalone content Extending the Pattern The ContentCluster component is intentionally minimal. Here are extensions worth considering: Dynamic cluster generation: Instead of hardcoding cluster data, query your CMS or database for posts tagged with the same topic. Generate the ItemList dynamically based on content metadata. Cluster analytics: Track which cluster links get clicked. Add UTM parameters or custom events to understand how users navigate through your topic clusters. Visual cluster maps: For pillar pages, consider rendering a visual map of the cluster showing relationships. This helps users understand the content architecture at a glance. AI-assisted clustering: Use Rampify's GSC insights to identify natural topic clusters in your existing content. Query patterns reveal which posts users associate with similar topics. Common Pitfalls Over-clustering: Not every post needs to be in a cluster. Standalone content is fine. Force-fitting unrelated posts into clusters dilutes topical signals. Orphaned pillar pages: Your pillar page should have substantial content, not just a list of links. Google needs to understand what the cluster is about from the pillar alone. Duplicate ItemLists: Each cluster should have exactly one ItemList definition, included identically on all cluster pages. Don't create variations or subsets. Missing currentUrl filtering: Always filter the current page from the displayed links. Linking to yourself creates a confusing user experience. Next Steps The ContentCluster component gives you a foundation for LLM-aware topic clusters. To maximize impact: 1. Audit existing content - Identify natural topic groupings in your blog or docs 2. Define pillar pages - Create comprehensive overview content for each cluster 3. Implement the component - Add ContentCluster to your blog layout 4. Validate structured data - Use Google's testing tools to confirm correct implementation 5. Monitor performance - Track GSC impressions and LLM visibility over time For automated cluster identification based on your actual search data, Rampify's MCP tools can analyze GSC query patterns and recommend topic groupings. This removes the guesswork from cluster planning. Topic clusters aren't a new concept, but the implementation needs to evolve. As AI-powered search grows, structured data becomes the bridge between your content and machine understanding. The hybrid architecture of Schema.org, sr-only navigation, and clean UI ensures your topic clusters work for every consumer: Google, LLMs, and the humans who actually read your content. ## Build SEO Workflows Without Code: Rampify's Automation API URL: https://www.rampify.dev/blog/automation-friendly-seo-api We've rebuilt our API from the ground up with one goal: make automation so easy you don't need to write JavaScript. If you've ever tried building n8n or Zapier workflows that consume REST APIs, you know the pain: - Writing JavaScript to filter and group data - Manually categorizing items with switch statements - Building complex IF/THEN logic just to route data - Wrestling with JSON structures that weren't designed for automation That ends today. The Problem with Traditional APIs Most APIs are designed for developers writing code. They return raw data and expect you to: 1. Filter it yourself - Loop through arrays, check conditions, build new objects 2. Group it yourself - Categorize items, calculate counts, organize by type 3. Route it yourself - Write IF/THEN logic to decide what to do with the data This works great if you're writing Python or Node.js. But in n8n or Zapier? You're stuck writing JavaScript in tiny code nodes, debugging JSON paths, and fighting with execution contexts. Our Solution: Zero-Code Routing We added a ?view= parameter to our action items endpoint that completely eliminates the need for custom code: 1. The routing View - Boolean Flags for IF/THEN Logic Instead of this (old way): // n8n Code Node - Manual filtering const actions = $input.all(); const hasCritical = actions.some(a = a.priority === 'critical'); const hasAutoFixable = actions.some(a = ['missing meta description', 'short title'].includes(a.actionType) ); return { hasCritical, hasAutoFixable }; You get this (new way): GET /action-snapshots/{id}/actions?view=routing Response: { "routing hints": { "has critical": false, "has auto fixable meta": true, "has auto fixable schema": false, "has indexing issues": true, "recommended next action": "fix meta tags" }, "counts": { "total actions": 11, "auto fixable": 8, "manual review": 3 } } Now in n8n, you just use IF nodes: - Condition: {{ $json.routing hints.has critical }} equals true - True branch: Send Slack alert - False branch: Continue to next check Zero JavaScript required. 2. The grouped View - Pre-Organized Data Instead of manually grouping actions by type, category, or priority, we do it for you: GET /action-snapshots/{id}/actions?view=grouped Response: { "groups": { "auto fixable": { "count": 8, "actions": [...] }, "manual review": { "count": 3, "actions": [...] }, "by priority": { "critical": { "count": 0, "actions": [] }, "high": { "count": 5, "actions": [...] } } } } Perfect for batch processing - just iterate through groups.auto fixable.actions and trigger your fix workflow. 3. The summary View - Dashboard-Ready Stats Building a dashboard or sending email reports? The summary view gives you exactly what you need: GET /action-snapshots/{id}/actions?view=summary Response: { "overview": { "total actions": 11, "health score": 72, "improvement potential": "28%" }, "top actions": [ { "title": "Missing Meta Description (12 affected)", "priority": "high", "affectedCount": 12 } ], "quick wins": { "count": 5, "estimated time": "30-60 minutes", "actions": [ "Fix 12 missing meta descriptions", "Add schema to 3 pages" ] } } Drop this straight into a Slack message or email template. No transformation needed. Real-World Use Cases Use Case 1: Daily SEO Monitor Goal: Check your site every morning, alert on critical issues, auto-fix simple ones. n8n Workflow (no code needed): 1. Schedule Trigger - Runs at 10am daily 2. HTTP Request - POST /clients/{id}/analyze with { "callbackUrl": $execution.resumeUrl } (start site analysis) 3. Wait Node - Pauses workflow until callback is received 4. HTTP Request - POST /sites/{id}/action-snapshots/generate (create action plan) 5. HTTP Request - GET /action-snapshots/{id}/actions?view=routing (get routing hints) 6. IF Node - \{\{ $json.routing hints.has critical \}\} = true? - YES: Create GitHub issues for each critical item - NO: Continue to next check 7. IF Node - \{\{ $json.routing hints.has auto fixable meta \}\} = true? - YES: Trigger auto-fix workflow (call meta generation API) - NO: Continue 8. Send Email - Daily summary with \{\{ $json.counts.total actions \}\} issues found Key Innovation: Callback Pattern Instead of polling the API every few seconds to check if analysis is complete, we use n8n's Wait node with webhook callbacks : // Step 2: Trigger analysis with callback URL POST /clients/{id}/analyze { "callbackUrl": "{{ $execution.resumeUrl }}" } How it works: 1. n8n generates a unique resume URL for each workflow execution (via $execution.resumeUrl ) 2. Rampify stores this URL in the database alongside the site check 3. Analysis runs in the background (Inngest handles the crawl, no timeout limits) 4. When complete, Rampify POSTs results to the stored callback URL 5. n8n workflow resumes with all the analysis data available in $json Why this is better than polling: Polling Approach Callback Approach ------------------ ------------------- Check every 10s: "done yet?" One ping when actually done 30+ API requests wasted 2 total requests (start + callback) Workflow keeps running ($$$) Workflow paused (free) 10-minute timeout limit No timeout (can run hours) Supports parallel workflows: Each execution gets its own unique callback URL, so you can run multiple site analyses simultaneously without conflicts. Total JavaScript written: 0 lines Get the workflow: Download from GitHub Use Case 2: Pre-Deployment Check Goal: Before deploying, check staging site for SEO issues. Make.com Scenario: 1. Webhook Trigger - Receives deployment event from CI/CD 2. HTTP Module - Trigger site analysis 3. Sleep Module - Wait for crawl to complete 4. HTTP Module - Get actions with ?view=routing&filter=critical 5. Router Module - Route based on routing hints.has critical - Route 1 (has critical): Block deployment, post to GitHub PR - Route 2 (no critical): Approve deployment, proceed Total code: None. Just HTTP requests and routers. Use Case 3: Weekly Client Reports Goal: Email clients their SEO health score and top issues every Monday. Zapier Workflow: 1. Schedule - Every Monday 9am 2. Rampify API - Generate action snapshot 3. Rampify API - Get summary view: ?view=summary 4. Email by Zapier - Send formatted email: - Subject: "Your SEO Health Score: \{health score\}" - Body template uses \{top actions\} and \{quick wins\} Zapier Formatter needed: None. Data is already email-ready. Filter Combinations Mix ?view= with ?filter= for powerful combinations: # Get only auto-fixable issues, already grouped ?filter=auto fixable&view=grouped Get only critical issues as a flat array ?filter=critical&view=flat Get routing hints for high-priority items ?filter=high&view=routing Get summary of just indexing issues ?filter=indexing&view=summary Every filter + view combination is documented in our OpenAPI spec. Decision Tree for Automation Here's the exact decision tree we recommend for n8n/Zapier: 1. GET actions with ?view=routing 2. IF has critical = true → Send urgent alert (Slack/PagerDuty) → STOP (manual intervention needed) 3. IF has auto fixable meta = true → GET actions with ?filter=auto fixable&view=grouped → Iterate through groups.auto fixable.actions → Call /meta/generate for each URL → Mark actions as completed 4. IF has auto fixable schema = true → Similar auto-fix flow for schema 5. IF has indexing issues = true → GET actions with ?filter=indexing → Submit URLs to Google Search Console 6. IF has any actions = true → Send summary email with remaining issues ELSE → Send "All Good" notification Every step uses boolean flags from the API. No JavaScript, no complex logic. Technical Implementation Behind the scenes, we: 1. Pre-compute routing hints - Boolean flags are calculated server-side 2. Cache grouped views - Expensive aggregations happen once 3. Optimize for automation - Response structure matches n8n/Zapier data models 4. Document everything - OpenAPI spec with examples for every view type Our philosophy: The API should do the hard work, not your automation tool. Developer Experience For teams that DO want to write code, we still support the standard ?view=flat (default) that returns a clean array of action items. You can filter, group, and transform however you want. But for the 90% of use cases where you just want to: - Route based on severity - Batch process auto-fixable items - Display top issues in a dashboard You don't need code anymore. AI-Native Alternative: Claude Code Subagents While no-code tools like n8n and Zapier are powerful for workflow automation, there's another approach: AI-native automation with Claude Code subagents . Key Difference: - No-code tools: Visual workflows with pre-defined triggers and actions - AI subagents: Natural language instructions with autonomous decision-making Example workflow comparison: n8n (No-Code): 1. Schedule trigger (daily) 2. GET /actions?view=routing 3. IF has critical = true → Send Slack alert 4. IF has auto fixable meta = true → Loop through actions 5. Call /meta/generate for each Claude Code Subagent (AI-Native): seo-agent Check my site daily. If you find critical issues, alert me on Slack. For auto-fixable meta tags, just fix them and let me know what you changed. The subagent handles the routing logic, API calls, and decision-making autonomously. When to use each: - Use n8n/Zapier: Multi-tool integrations (Slack + Airtable + Email) - Use AI subagents: Content creation, SEO optimization, code generation - Use both: n8n triggers the subagent for complex workflows Learn more: Claude SEO Checker API Reference All of this is documented with real examples in our API Reference: - Introduction section - Quick start workflow for n8n/Zapier - Decision tree - Step-by-step routing logic with n8n expressions - View examples - Complete JSON responses for all 4 view types - Filter combinations - Every supported filter + view pair Get Started 1. Sign up at rampify.dev 2. Generate API key at Settings → API Keys 3. View the API docs at rampify.dev/api-reference 4. Import our n8n workflow from GitHub Or just start with a simple workflow: # Get your action plan with routing hints curl -H "Authorization: Bearer sk live your key" \ "https://www.rampify.dev/api/action-snapshots/{id}/actions?view=routing" Then use those boolean flags in your automation tool. No code needed. Questions? Check the API docs. Want to see the code? All workflows are open-sourced on GitHub. ## Why Modern Developers Need the Inbound Playbook for SEO URL: https://www.rampify.dev/blog/marketing-grader-to-developer-seo I. The Demo That Changed How I Think About Software It's 2014. I'm a Sales Engineer at HubSpot, embedded in Ryan Neu's team. If you don't know Ryan, he's Founder and CEO of Vendr now. But back then, he was leading one of HubSpot's top-performing sales teams, and he was probably the best salesperson I'd ever met. Not in a slick, close-the-deal-at-any-cost way. Ryan was calm . Reassuring. The kind of person who made you feel like he was solving your problem, not selling you a product. People trusted him immediately, and he passed that philosophy down to everyone on the team. My role was to be the technical voice in the room. Demo the product, field the hard questions, translate marketing automation into language that made sense for different buyers. Less pitch, more proof. One Inbound Marketing Assessment call sticks with me. Ryan was coaching a new rep that day, sitting in on the call, letting them lead, but ready to jump in if needed. About ten minutes in, the rep was struggling to articulate the issue they were seeing on the prospect's site. Ryan muted the line and said quietly, "Let me show you how to do this." He unmuted and smoothly took over. "Hey, do you mind if I share my screen for a second? I want to show you something." Mid-sized B2B SaaS company. Their VP of Marketing had requested a free assessment through HubSpot's website. No strings attached, just a 30-minute critique of their marketing. Ryan opened their homepage. Big hero image. Slick design. And right in the center: a single call-to-action. "Request a Demo." That's it. No blog. No resources. No way to engage unless you were ready to talk to sales. Ryan pulled up their analytics: "You're getting 15,000 visitors a month. How many demo requests?" "About 40," she said. "So you're losing 99.7% of your traffic. Let me guess, most visitors aren't ready to buy yet. They're researching. Comparing options. Trying to understand the space. But your site says: 'Buy now or leave.'" She nodded slowly. "It's like trying to get married on the first date," Ryan said. "Most people just want to get coffee first." The VP laughed, but you could see the gears turning. Ryan walked her through the inbound approach: give people something valuable before asking for a commitment. A free guide. A marketing grader. A checklist. Let them opt in, build trust over time, and then ask for the demo. "HubSpot's homepage has dozens of free resources," he explained. "That's how we turn researchers into leads, and leads into customers. You're skipping the first two steps." By the end of the call, she wasn't asking if she should change her approach. She was asking how fast HubSpot could help her implement it. That's when I understood: the best sales don't feel like sales at all. They feel like someone showing you what's broken and offering to fix it. --- This was the HubSpot way. Give value first. Show problems. Offer solutions. Build trust. Let the methodology do the selling. Ryan's team "bled orange" (HubSpot-speak for living and breathing the inbound philosophy), but it wasn't just culture, it was results . This approach worked. Prospects appreciated being treated like intelligent buyers instead of quota targets. In 2014, most SaaS sales felt like used car lots: pushy demos, "limited time offers," artificial urgency. HubSpot felt different. And the proof came that fall when the company went public. The inbound methodology was a business model that scaled. --- Fast-forward to 2025. I'm building developer tools now, and I keep seeing the same problem Ryan and his team solved for marketers back in 2014. Except this time, the people who need help are developers , and nobody's giving them the playbook. --- II. Developers Are Building Blind Here's what I'm seeing: developers are building better websites than ever before: Next.js, Astro, Remix, modern frameworks with incredible performance and developer experience. But when it comes to SEO? They're raw-dogging it. I don't mean this as a criticism. It's a structural problem. Back in the WordPress era, you had training wheels: - Yoast SEO screaming at you with red/yellow/green indicators - RankMath giving you checklists - Built-in guidance for meta descriptions, alt tags, schema markup You couldn't avoid thinking about SEO. The tools made it impossible to ignore. (Though modern developers are ditching CMSs entirely for good reasons.) Fast-forward to 2025: - You're building in Next.js App Router - You've got Claude or Cursor helping you write code - You ship your site to Vercel - You wait for Google Search Console to index your pages And then, weeks later, you discover: - Half your pages aren't indexed - Your meta descriptions are auto-generated garbage - You have no schema markup - Your images have no alt tags - Your sitemap is broken There's no safety net. No real-time feedback. No proactive guidance. AI coding tools will help you build features, but they won't tell you your SEO is broken. They don't know what "good" looks like for your specific use case. It's like writing code without tests, without linting, without type checking. You're just shipping and hoping. --- III. The Website Grader Playbook (What I Learned at HubSpot) This problem felt familiar. Back in 2010, marketers had the same issue. They knew they "should" do SEO, and build out content, but they didn't know what was broken or where to start. HubSpot's solution wasn't to sell them software first. It was to show them their blind spots . The Website Grader formula: 1. Free audit - Run their domain through the tool 2. Show problems - "Here are 20 things holding you back" 3. Offer context - "Here's why this matters for your business" 4. Provide solutions - "Here's how to fix it" (oh, and we have a platform for that) The genius wasn't the technology. It was the sequencing . You didn't feel sold to. You felt helped. And when you were ready to fix the problems, HubSpot was the obvious choice because they'd already built trust. This approach worked for Inbound Marketing Assessments too. I sat in on dozens of these calls: - "A top of the funnel offer like a Free Consultation should be prominently displayed in the navigation" - "We can help you strategize on a content calendar and publishing on a regular basis" - "You have blog posts but no CTAs, missing opportunities to convert visitors to contacts" By the end of the call, prospects were asking us about next steps. --- Same exact playbook. Different audience. Marketers in 2010 needed inbound methodology. Developers in 2025 need the same thing, they just don't know it yet. --- IV. Rampify: Inbound Methodology for Developers This realization is what led me to build Rampify. The core insight: Developers are the new marketers. They're building from scratch, making SEO and content decisions (whether they realize it or not), and discovering problems too late. They need the Website Grader experience, but translated into their workflow. Here's how we're applying the HubSpot playbook: 1. Show Problems First (Free Value) Just like Website Grader, Rampify gives you an instant audit: - Crawl your site - Check every URL for SEO health - Detect missing meta tags, broken schema, indexing issues - Show Google Search Console data (coverage, mobile usability) - Use your business profile to personalize recommendations (industry benchmarks, tech stack optimizations) No paywall. No trial. Just: "Here's what's broken." 2. Phased Guidance (Inbound Journey) HubSpot taught me that buyers move through stages: Awareness → Consideration → Decision. For developers, the journey is different but parallel: - Pre-Launch - Fix critical issues before you ship - Launch - Ensure Google can crawl and index - Early Growth - Optimize for conversions and performance - Scale - Advanced SEO, content strategy - Expansion - Multi-market, internationalization Rampify's phase system guides you through this lifecycle. You're not overwhelmed with 100 action items. You see what matters right now . 3. Recommendations in Context (IDE Integration) Here's where it gets interesting. You know how HubSpot brought inbound methodology to marketers where they worked (in their CMS, in their email tools)? We're doing the same thing for developers—but in their IDE. Rampify creates a closed-loop system that brings SEO intelligence directly into your development workflow: The Loop: 1. Action Plan - Rampify analyzes your site and generates a prioritized action plan 2. MCP Tools - Your AI coding tool (Claude Code, Cursor) executes fixes directly in your editor 3. Verification - Changes sync back to Rampify, action plan updates automatically You never leave your IDE. The entire SEO optimization loop happens in the context of your code. Example workflow: # Rampify action plan identifies issues: - Add Article schema to blog post template - Fix missing OG images on 12 pages - Update meta descriptions (3 too long for mobile) You ask Claude Code: "Fix the Article schema issue flagged by Rampify" Claude Code: - Calls Rampify MCP tools to get schema requirements - Generates correct schema markup - Applies fix to your code - Marks action as complete via MCP Action plan updates in real-time ✓ This is what we call Context-Driven Development. Your AI assistant has deterministic context about what needs to be fixed, and the tools to fix it, without you context-switching between browser tabs and your editor. 4. Recommend HubSpot at the Right Time Here's the full-circle moment. Once developers start getting traffic, they need to capture leads. They need a CRM. They need email marketing. Rampify proactively recommends HubSpot when you hit the "Early Growth" phase. Not as a hard sell. As a natural next step: "You're getting traffic now. Here's how to turn visitors into customers." Same playbook Ryan's team used: - Give value first (SEO audit, action plan) - Build trust (help them succeed) - Recommend the right tool at the right time (HubSpot CRM) We're teaching the inbound methodology to developers who've never heard of it, and creating future HubSpot customers in the process. --- V. Why This Matters (The Inflection Point) We're at a unique moment in technology. Developers are building more websites than ever before: - SaaS companies with marketing sites - Documentation platforms - Developer blogs and portfolios - Product landing pages - AI-powered tools that need web presence And they're building from scratch (not on WordPress, not on Webflow). This means: 1. They control the entire stack (and are responsible for SEO decisions) 2. AI tools help them build faster (but don't guide them on SEO) 3. There's no institutional knowledge (no Yoast equivalent for Next.js) SEO is not optional. Organic traffic = qualified leads. If you're not showing up in search, you're invisible. But most developers don't realize they're making SEO mistakes until it's too late. Weeks after launch, when they check Google Search Console and see: - "Discovered - currently not indexed" - "Crawled - currently not indexed" - "Excluded by noindex tag" (wait, what?) Rampify gives them the feedback loop they're missing. Just like HubSpot gave marketers a methodology for inbound, we're giving developers a methodology for SEO-first development. --- VI. Loop Marketing: HubSpot's Evolution Meets Rampify's Mission Here's what's fascinating: while I was building Rampify, HubSpot was evolving their methodology for the AI era. In September 2024, they introduced Loop Marketing, a new framework that responds to a fundamental shift in how people find information online. The problem they identified: 60% of Google searches now end without a click. From AI Overviews, ChatGPT, to Perplexity, people get answers directly in search results. The old funnel is broken. Sound familiar? This is exactly the problem developers face with SEO: - Build a great site - Wait for Google to index it - Hope people click through - Discover weeks later that nobody's seeing your content Loop Marketing's solution is a four-stage framework: 1. Express - Define your brand's unique voice and perspective (AI can't do this for you) 2. Tailor - Use AI to personalize messaging at scale 3. Amplify - Distribute across channels to meet buyers where they are 4. Evolve - Continuously learn and optimize (feeds back into the cycle) Here's the connection to Rampify: Loop Marketing is about adapting to an AI-driven world where traditional funnels don't work. Developers face the same challenge: building in an AI-assisted world where traditional SEO guidance doesn't exist. The parallel: - HubSpot's Loop - Marketers + AI working together for better outcomes - Rampify's approach - Developers + AI working together for better SEO Both recognize that AI isn't replacing humans, it's augmenting them. Loop Marketing helps marketers stay visible in a zero-click world. Rampify helps developers build discoverability from day one. Different audiences, same philosophy: give AI the context it needs to amplify human expertise. HubSpot is teaching marketers to adapt to AI-powered search. Rampify is teaching developers to build for AI-powered search, with AI-powered tools. The results speak for themselves: - HubSpot's Loop early adopters saw 82% increase in conversion rates - AI-generated traffic converts 4.4x better than traditional search traffic - Why? Because it's contextual, personalized, and relevant That's what we're building for developers: contextual SEO intelligence that makes every page discoverable in an AI-first world. --- VII. Full Circle: From Student to Teacher I spent 7 years at HubSpot. I watched the inbound methodology transform marketing. I saw how giving value first—showing problems, offering solutions, building trust—created a category-defining company. Now I'm applying those lessons to a new audience. Developers don't need to be sold. They need to be shown . Show them what's broken. Give them a clear path to fix it. Build trust through competence. And when they're ready to grow, recommend the tools that will help them scale. HubSpot taught me this playbook. Rampify brings it to developers. And we're creating future HubSpot customers in the process. It's a full-circle moment: the student becomes the teacher, and the methodology that worked for marketers in 2010 gets translated for developers in 2025. Ryan Neu would be proud. (Or at least, I hope he would.) --- VIII. Try It Yourself Want to see what your site's SEO looks like? → Get Started Free Just like Website Grader. Type in your domain, see what's broken, get a clear action plan. And when you're ready to capture leads from that traffic? → HubSpot CRM is still the best way to turn visitors into customers. Want to learn more about HubSpot's AI-era evolution? → Check out Loop Marketing - their framework for thriving in a zero-click world. Same playbook. Different era. Let's build something great. --- About the Author I spent 7 years at HubSpot as a Sales Engineer, working alongside some of the best sales and marketing teams in SaaS. Now I'm building Rampify, bringing SEO intelligence into the developer workflow through AI-powered tools and IDE integrations. If you're a developer building in Next.js, Astro, or Remix, I'd love to hear from you. Twitter/X LinkedIn ## Speed Up Search Engine Indexing with IndexNow URL: https://www.rampify.dev/blog/indexnow-faster-indexing Traditional search engine crawling can take days or weeks to discover your new content. IndexNow changes that by allowing you to instantly notify search engines about new or updated URLs. What is IndexNow? IndexNow is a free protocol launched by Microsoft and Yandex that allows webmasters to instantly notify search engines about URL changes. Participating Search Engines Currently supported by: - Bing (Microsoft) - Yandex - Seznam.cz - Naver (partial support) Not supported: Google (they maintain their own Indexing API) Why Use IndexNow? Traditional crawling has limitations: 1. Slow discovery - Can take days for crawlers to find new content 2. Wasted resources - Crawlers hit unchanged pages repeatedly 3. No control - You can't tell crawlers what's actually changed IndexNow solves these: - Instant notification - URLs indexed in 5 seconds to 5 minutes - Free - No API costs or limits - Multi-engine - One ping notifies all participating engines Implementation Here's a simple implementation using Node.js: async function pingIndexNow(urls: string[]) { const apiKey = generateRandomKey(); // 32-char hex string const host = new URL(urls[0]).hostname; const response = await fetch('https://api.indexnow.org/indexnow', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ host: host, key: apiKey, urlList: urls, }), }); return response.ok; } Best Practices 1. Ping on publish - Trigger IndexNow when you publish new content 2. Batch updates - Submit multiple URLs in one request (up to 10,000) 3. Don't spam - Only ping when content actually changes 4. Track results - Monitor which URLs get indexed Combining with Google Since Google doesn't support IndexNow, use a hybrid approach: // Ping IndexNow first (Bing, Yandex, etc.) await pingIndexNow([url]); // Then submit to Google Indexing API await submitToGoogle([url]); This way your content appears in multiple search engines faster! Real-World Results In our testing: - Bing : Indexed in 5-30 minutes (average: 12 minutes) - Yandex : Indexed in 10-45 minutes (average: 22 minutes) - Traditional crawling : 2-14 days (average: 5 days) That's a 500x speed improvement ! Conclusion IndexNow is a no-brainer for any website that publishes content regularly. It's free, fast, and easy to implement. Want to see it in action? Our SEO Ops Dashboard has IndexNow built-in for all URL submissions. --- Resources: - IndexNow Official Docs - Bing IndexNow Guide - Implementation Examples on GitHub ## Welcome to the Rampify Blog URL: https://www.rampify.dev/blog/welcome Welcome to the Rampify blog! We're building the first SEO intelligence layer for AI coding tools and pioneering a new development methodology called Context-Driven Development (CDD) . What You'll Find Here This blog is for developers using AI coding tools (Cursor, Claude Code, etc.) who want to: - Practice Context-Driven Development - Get real-time domain intelligence in their editor - Fix SEO issues before deployment, not after - Build optimized sites without context switching - Understand how AI should (and shouldn't) be used in development Our Philosophy We believe in: 1. Determinism over plausibility - Real data from authoritative sources, not AI hallucinations 2. Context at decision-time - Domain intelligence when you need it, not weeks later 3. Zero context switching - Expert knowledge in your editor, not in dashboards 4. AI as interface, not intelligence - LLMs should explain and converse, not guess facts Our Tech Stack This blog practices what we preach - built with: - Next.js 16 with App Router - MDX for content with full type safety - Model Context Protocol (MCP) integration - Rampify MCP Server for SEO intelligence - No external CMS - just local files and git We use our own MCP server to ensure every post is optimized before it ships. What's Next? We'll be writing about: - Context-Driven Development methodology and best practices - How to integrate MCP servers into your workflow - Real-time SEO checks in Cursor and Claude Code - Building deterministic systems with AI interfaces - Technical deep-dives on indexing, crawling, and search engines - Case studies from developers using Rampify Get Started Ready to practice Context-Driven Development? - What is Rampify? - Learn our philosophy - What is Spec-Driven Development? - Complete guide - Get Started Free - Set up in under 2 minutes --- Happy building!