How to Publish Blogs From Windsurf to Your Own Domain (2026)

Photo by Marvin Tendies on Unsplash

You let Cascade refactor a service across nine files in one prompt. You let it run your test suite, read the failures, and patch the bug. You trust it with production code.

Then you write a blog post, copy the markdown out of Windsurf, paste it into WordPress, fight with the block editor for twenty minutes, retype the meta description into Yoast, upload an image, and pray the publish button doesn't 504.

That gap is the bottleneck. Cascade can run multi-step agentic workflows end-to-end. Why are you still doing the publishing step by hand?

In 2026, the same Model Context Protocol that lets Cascade talk to Postgres and GitHub talks to your blog. You prompt Cascade in Windsurf. It drafts the post. It scores the post. It publishes the post to yourdomain.com/blog. You never leave the editor.

This guide is the working setup — the config file, the four-move publishing loop, the prompts that ship, and the five mistakes that quietly tank scores. Updated May 2026.

Publish blogs from Windsurf: the short answer

To publish blogs from Windsurf to your own domain, add a blog-publishing MCP server to ~/.codeium/windsurf/mcp_config.json, prompt Cascade to draft a post in markdown, then ask it to score the draft against SEO criteria and publish to your subdirectory. The post lives at yourdomain.com/blog/your-slug with sitemap and RSS auto-updated and Google's Indexing API pinged. Total time: under five minutes from prompt to live URL.

That's the loop. The rest of this post is the detail — config, prompts, and the guardrails that keep Cascade from publishing a 65-score draft you'll regret next quarter.

Why Windsurf is a publishing surface in 2026

Windsurf is no longer the scrappy underdog. As of early 2026, it has 1M+ active users and the editor's AI writes 70M+ lines of code per day (Windsurf official site). In February 2026, it ranked #1 in LogRocket's AI Dev Tool Power Rankings, ahead of Cursor and GitHub Copilot (Second Talent Windsurf Review 2026).

Three things flipped Windsurf from "AI code editor" into a real publishing surface.

First, Cascade's autonomous agent loop. Cascade reads your full codebase, makes changes across multiple files, runs terminal commands, and executes multi-step tasks without requiring every action to be directed. That's the same shape as "draft → score → patch → publish." Give it a topic, get back a live URL.

Second, native MCP support. Windsurf adopted MCP early. The official Cascade docs list three transports — stdio, Streamable HTTP, and SSE — meaning every flavor of MCP server works out of the box (Cascade MCP Integration docs). MCP itself hit 97 million monthly SDK downloads by March 2026, with 78% of enterprise AI teams running at least one MCP-backed agent in production (MCP Adoption Statistics 2026). The protocol is industry infrastructure now, not a side experiment.

Third, the Cognition acquisition. Cognition AI — the team behind Devin, the autonomous coding agent — acquired Windsurf in December 2025 for roughly $250 million. The roadmap leaned harder into agentic, hands-off workflows. Publishing a blog is exactly the kind of multi-step, tool-using task this stack was rebuilt for.

There's a strategic angle, too. Aleyda Solis, the SEO consultant who's spent 2026 on every AI-search panel that matters, frames it sharply: "Treat AI search as both a performance channel and a visibility channel" (Humans of Martech podcast, January 2026). The fastest way to ship the volume of content needed to be visible across both is to delete the publishing handoff. Cascade plus MCP deletes it.

The Windsurf publishing loop: a 4-move framework

Every blog post you ship from Windsurf follows the same four moves. Name them, and Cascade runs them autonomously.

Call this the Windsurf publishing loop. The point: no human moves data between steps. Cascade reads the score, reads the patches, applies them, re-scores, and only publishes when the post crosses your quality threshold.

That's the whole framework. The remaining work lives in your prompt, your config, and your style file. Get those dialed in once and the next 50 posts ship the same way.

Phase 1: Prompt Cascade like a content brief

Open the Cascade panel. You can either drop a posts/draft.md skeleton in your repo or prompt Cascade directly. Either way, the prompt matters more than the editor.

A working prompt has four parts: topic, audience, evidence sources, and style. Here's the template that ships ranking posts:

Topic: How to roll out feature flags without breaking prod
Primary keyword: feature flag rollout
Audience: senior backend engineers at Series A startups
Word count: 2,800-3,400

Use these sources:
- LaunchDarkly's 2026 trunk-based dev report
- Anthropic's experiment notes on staged rollouts
- Two real GitHub PRs from our repo (link below)

Style: builder-to-builder. No "in today's fast-paced world."
Short paragraphs. Code blocks for every claim about how
to actually do the thing. One named framework readers can
quote ("the canary checklist" or similar).

Draft to a Quillly draft on website_id <id>. Folder: Engineering.
Tags: feature-flags, deployment, devops.

Notice the structure: a primary keyword, a target reader, real sources for evidence, and a style boundary. Notice the absence of length-padding instructions or "remember to mention our product." If the post needs to mention the product, Cascade infers it from the topic.

Cascade reads that prompt, plans the section structure, calls create_blog with status: "draft", and returns a draft ID. The first draft is rarely perfect — that's fine, the next phase fixes it.

For reuse, drop the prompt template into a Cascade Memory or a .windsurf/rules/blog-style.md file. Windsurf's memory system pulls those rules into every Cascade run on the workspace, so you don't retype the style guide on every post. Pages with strong structural signals get cited at materially higher rates: content scoring 8.5/10+ on semantic completeness is 4.2x more likely to be cited by AI search engines than content scoring below that threshold (Digital Applied AI Search Statistics 2026).

Phase 2: Score the draft against 14 SEO criteria

The fastest way to ship bad SEO is to skip this phase. The fastest way to ship good SEO is to score before you publish.

Quillly's MCP exposes a tool called check_blog_seo. It runs 14+ SEO criteria against the saved draft and returns a 0–100 score, a grade, and a per-criterion breakdown. The criteria cover what actually moves rankings in 2026: meta tags, heading structure, keyword placement, internal linking, image alt text, readability grade, content length, schema readiness, and a handful more.

Why score before publish? Two stats explain it.

• 44.2% of all LLM citations come from the first 30% of a page, with 31.1% from the middle and 24.7% from the last third (Digital Applied citation pattern study). If your intro doesn't lead with a direct answer, the rest of the post barely matters for AI Overviews and ChatGPT.

• AI Overviews now trigger on roughly 48% of all Google queries, a 58% jump in twelve months (Digital Applied AI Search Statistics 2026). Posts that skip the AEO structure aren't just losing rank — they're losing the entire above-the-fold answer.

The Cascade prompt for this phase:

Run check_blog_seo on the draft. If score < 85, run
get_blog_seo_patches and fix every issue with update_blog
in a single call. Re-score. Loop until 85+ or two passes,
whichever comes first. Then stop and show me the report.

That's the entire control flow. Cascade decides when to stop. You decide the threshold. A floor of 85 is reasonable for a long-form post; a floor of 90 if the post is in a competitive cluster.

Phase 3: Patch the draft without rewriting it

This is where most "AI publishing" workflows quietly fall apart. The agent reads the score, then tries to fix issues by regenerating the entire post. Regeneration breaks the things that were already working.

Patches solve this. A patch is a surgical find-and-replace operation. The MCP server returns patches like "replace this exact meta description string with this one" or "insert this H2 here." Cascade applies them in a single update_blog call. Nothing else changes.

A typical response from get_blog_seo_patches:

[
  {
    "find": "## Why this matters",
    "replace": "## Why feature flag rollouts matter in 2026",
    "impact": "+4 (H2 keyword coverage)"
  },
  {
    "find": "Learn how to roll out features safely.",
    "replace": "Learn how to roll out features safely without breaking prod.",
    "impact": "+3 (meta description CTA)"
  }
]

Each patch comes with a projected score impact. Cascade stacks all of them into one update_blog call, re-runs check_blog_seo, and reports the new score. If a fix can't be patched mechanically — like an entire missing FAQ section — Cascade writes the section and appends it.

Patches matter because freshness compounds. Content updated within the last 30 days receives roughly 3.2x more citations from AI search engines than content older than 90 days (Digital Applied AI Search Statistics 2026). Once a post is live, the same patch tool keeps it fresh on a schedule. You don't rewrite — you patch.

Phase 4: Publish to your subdirectory, not a subdomain

Most "AI blog" tools publish to something.subdomain.theirsite.com. That's a permanent SEO tax. Subdirectories share link equity automatically with the root domain. Subdomains divide it. Real-world case studies show subdirectories rank faster and more effectively on the first SERP page (Backlinko: Subdomain vs Subdirectory).

Quillly publishes blogs at yourdomain.com/blog/your-post-slug — same domain, same authority, same Search Console property. When Cascade calls publish_blog:

1. The post goes live at your subdirectory URL.

2. Your sitemap (/sitemap.xml) regenerates automatically.

3. Your RSS feed updates.

4. Google's Indexing API gets pinged for fast discovery.

5. The blog appears in list_blogs with indexing.status: "submitted".

You can watch indexing progress without leaving Windsurf. A follow-up list_blogs call shows when Google moves the post from submitted to indexed, plus search position, clicks, and impressions once Search Console data flows.

That last point is the one most workflows miss. Publishing isn't the end of the loop — it's the start of the data feedback loop. We've covered the GSC half of that loop in the 2026 MCP workflow for Search Console rankings. The short version: GSC data feeds back into the next prompt, the next prompt produces a sharper draft, and the loop tightens with every cycle.

The Windsurf MCP config you actually need

Windsurf reads MCP server config from ~/.codeium/windsurf/mcp_config.json. You can edit it directly, or open Cascade's settings panel via Windsurf Settings > Advanced Settings > Cascade > MCP Servers and click "View raw config" (Cascade MCP Integration docs).

Here's a working config with a Quillly server installed alongside the usual GitHub server:

{
  "mcpServers": {
    "quillly": {
      "serverUrl": "https://quillly.com/mcp",
      "headers": {
        "Authorization": "Bearer ${QUILLLY_API_KEY}"
      }
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}

Three things that trip people up on the first install.

1. Transport types. Quillly runs as a remote HTTP server, so its config uses serverUrl and headers. Locally-running servers like the GitHub one use command and args. Cascade supports stdio, Streamable HTTP, and SSE — pick whichever the server publishes.

2. The 100-tool ceiling. Cascade has a hard limit of 100 active tools across all servers. Exceed it and tools get silently dropped. Quillly alone exposes up to 23 tools (12 on Free, all 23 on Pro), so installing five or six servers will fill the budget fast. Toggle individual tools off on each MCP settings page if you don't need them.

3. Environment interpolation. Use ${QUILLLY_API_KEY} instead of pasting the literal key. Set the variable in your shell config (.zshrc, .bashrc) so it doesn't end up in a dotfiles repo. The same pattern works for the GitHub PAT and any other server credential.

Verify the install: open the Cascade panel and check the MCPs icon in the top right. A green dot next to quillly means the wire is up. If it's grey, click Reconnect. Type @quillly in Cascade — it autocompletes the available tools (create_blog, check_blog_seo, publish_blog, and friends). That's your confirmation.

If you've configured Cursor, Claude Desktop, or ChatGPT, the JSON shape is almost identical because all four editors speak the same MCP spec. The Cursor walkthrough lives in the 2026 Cursor publishing guide, the Claude Desktop walkthrough is in the 2026 Claude Desktop publishing workflow, and the 2026 ChatGPT publishing workflow covers the OpenAI side. Same mcpServers block, slightly different file paths.

Old workflow vs Windsurf + MCP: the comparison

The reason this loop matters isn't theoretical. It's a flat-out time delete on the part of blog work nobody enjoys. Here's the comparison.

The hidden cost in the left column isn't just minutes — it's context switches. Every tab you open is a chance to lose the thread of what you were trying to say. The right column keeps you in one window, in one conversation, in one mental mode.

The contrarian take buried in this approach: stop moving your blog into your stack. Pull publishing into your editor. The CMS as a separate destination was a 2010s assumption. In a 2026 agent stack, the editor is the publishing surface. Your CMS is a Cascade panel.

Five mistakes Windsurf users make on their first publish

Most people running this loop the first time hit the same five potholes. Skip them.

1. Trusting the Marketplace install over manual config. Windsurf's MCP Marketplace makes one-click installs trivially easy. The trade-off: you don't see what got installed, and credential prompts vary by server. For anything that touches a domain you own — your blog, your DNS, your analytics — open mcp_config.json and write the entry by hand. Five extra minutes of setup buys you a permanent audit trail.

2. Letting Cascade publish at score 70. The default temptation is to ship the first draft. Don't. Set a hard threshold (85 floor) and let Cascade loop until it crosses. The patch step is cheap; ranking from a low-quality post is not. Sites publishing 50–100 quality AI articles with human editing saw traffic increases of 30–80%, while sites publishing 1,000+ unedited AI articles saw traffic drops of 40–90% (Ahrefs study via Pravin Kumar's analysis, 2026). The difference is quality control, not AI usage.

3. Skipping the FAQ section. People-Also-Ask-style FAQs are the single most-cited block by ChatGPT and Google AI Overviews. The structural patterns LLMs reward live in the 2026 AEO playbook for getting cited. If your post doesn't have an FAQ, you're leaving citations on the table. Ask Cascade for one explicitly in the prompt — six questions, 50–90 word answers, direct answer in the first sentence.

4. Publishing to a subdomain because the platform makes it easy. Subdomains divide link equity. Subdirectories consolidate it. Take the extra hour to wire up yourdomain.com/blog once. You'll thank yourself when you've shipped 50 posts and they're all stacking authority on a single domain instead of fragmenting it across four.

5. Treating MCP as a single tool, not a stack. The real power isn't quillly alone — it's quillly plus github (publish changelogs as posts), plus a search MCP (fresh stats on demand), plus your own data MCP (real customer language and product metrics). Composability is the wedge. We covered the broader stack in the 2026 MCP servers for SEO guide, if you want to see what a full publishing stack looks like.

A real Cascade prompt that works on the first try

Theory is fine. Here's a prompt you can paste straight into the Cascade panel and ship a post tonight. Edit the bracketed parts.

You are my blog publishing agent. Use the quillly MCP server.

Topic: [your topic]
Primary keyword: [keyword]
Target audience: [who reads this]
Word count: 3,000-3,600
Voice: builder-to-builder, contractions, no marketing fluff,
no "in today's fast-paced world."

Workflow:
1. Search the web for 5+ recent stats with sources
2. Draft the post in markdown with: H1 under 60 chars,
   40-60 word direct-answer paragraph after the H1,
   8-10 H2 sections, FAQ with 6 questions, conclusion
3. Call create_blog (status: draft) on website_id [your_id]
4. Call check_blog_seo. If score < 85, call
   get_blog_seo_patches and apply all fixes via update_blog
   in one call. Re-score. Loop max 2 times.
5. Call suggest_internal_links and apply the relevant ones
6. Call publish_blog when score is 85+ and meta description
   is 160 chars or less
7. Report the live URL and final score

That's the whole thing. Cascade runs to completion. You get a live URL with no copy-paste anywhere in the loop.

If you want to schedule posts instead of shipping immediately, swap step 6 for update_blog with a future published_at timestamp — Quillly's scheduled publishing handles the rest. For batch publishing across a content calendar, the 2026 programmatic SEO with MCP guide walks through shipping 100 posts from one conversation.

Frequently asked questions

Do I need to host my own MCP server to publish from Windsurf?

No. Use a hosted MCP server like Quillly that exposes blog publishing as remote tools. Add the server URL and your API key to ~/.codeium/windsurf/mcp_config.json and Cascade calls the tools directly. Self-hosting an MCP server is an option if you have specific compliance requirements, but it isn't required to start. Most indie hackers and small teams should pick the hosted option to skip server maintenance entirely and stay focused on shipping content.

Can Cascade publish to a self-hosted WordPress site instead?

Yes — several MCP servers expose WordPress as a tool surface. The trade-off is the WordPress block editor's quirks. Markdown-to-Gutenberg conversion is lossy, image uploads can be flaky, and SEO scoring requires bolting on Yoast or Rank Math separately. If you want a markdown-native pipeline that publishes to your own domain without WordPress's overhead, an MCP-first platform like Quillly removes the moving parts. Both paths work; one has fewer surfaces that break at the worst moment.

What's the difference between a Windsurf MCP server and a Windsurf extension?

A Windsurf extension adds UI features inside the editor — sidebars, syntax highlighters, custom commands. An MCP server adds tools that Cascade can call autonomously, like create_blog or query_database. Extensions help the human; MCP servers help the agent. Blog publishing belongs firmly in MCP-server territory because Cascade does the work end-to-end without manual UI clicks. The two layers are complementary, not competing.

How do I keep my API key out of mcp_config.json?

Use environment variable interpolation. Set QUILLLY_API_KEY in your shell config (.zshrc, .bashrc, or a secrets manager) and reference it in the config as ${QUILLLY_API_KEY}. Windsurf resolves the variable at startup and never writes the literal key to disk. The same pattern works for any header or env field across all your MCP servers — including OAuth client secrets and database passwords.

Will Google penalize blogs published by Cascade?

Not if the content is genuinely useful. A 600,000-page Ahrefs study found a near-zero correlation (0.011) between AI assistance and ranking penalties, with 86.5% of top-ranking content using some form of AI assistance (Pravin Kumar analysis, 2026). Google penalizes unhelpful content, not the production method. The fix isn't to avoid AI — it's to add human judgment in the loop. Use Cascade for drafting and patching; review the final draft yourself before approving publish.

How do I track which posts are actually getting indexed?

Cascade can call list_blogs and read each post's indexing status. Statuses include submitted, indexed, not_indexed, and error. After publishing, Google's Indexing API gets notified automatically, and a background job polls Search Console for status changes. Search position, clicks, and impressions populate in list_blogs once GSC data flows — usually within a few days for a new post. You can ask Cascade for a weekly indexing report and get a one-glance view of every blog's coverage state without opening Search Console.

What if Cascade hits the 100-tool limit on my MCP setup?

Trim. Cascade silently drops tools when you exceed 100, which means a critical tool like publish_blog can stop working without warning. Open each MCP settings page and toggle off tools you don't actively use. A typical content stack — Quillly (23 tools) + GitHub (~30) + a search server (~10) — leaves comfortable headroom. If you've installed eight servers experimentally, prune to the four you'll use weekly.

Three takeaways before you ship

The whole point of this guide is one move: delete the publishing handoff. Three specifics to walk away with.

1. Set up the config once. Drop one block into ~/.codeium/windsurf/mcp_config.json, set the env var, restart Windsurf. Five minutes of setup pays back on every future post and stays out of your way forever.

2. Run the four-move loop every time. Draft → Score → Patch → Publish. Don't skip the score step. A score floor of 85 cuts your "I should have edited that" regret rate to near zero and keeps you out of the 40–90% traffic-drop bucket for sites that ship raw AI output.

3. Keep your domain on the post. Subdomains leak link equity. Subdirectories compound it. Pick the subdirectory once and stop fragmenting your authority across hosts.

Want Cascade to actually publish the post it just wrote? Connect Quillly to Windsurf in 30 seconds.