Content Engine for SaaS

The bottleneck on SaaS content in 2026 is rarely ideas or writers — it's the production system around the writers. A clean filesystem registry, schema-validated markdown, automatic sitemap and llms.txt, IndexNow on every publish, and a weekly GSC-fed feedback loop is the difference between a content team that ships 4 pages a month and one that ships 16. I build that system. I am Ignacio (IGNAX), a Spain-born, Paraguay-based, solo full-stack developer + SEO/AEO specialist. ignax.dev itself runs the engine I am offering — see the growth engine case study for the live proof.

Who is this service for?

  • SaaS marketing teams that have a content strategy but no production system, and are shipping 2–4 articles a month when 12–20 is the goal.
  • Founders who write but spend half their writing time on JSON-LD, hreflang, sitemap, and llms.txt instead of words.
  • Agencies that need a senior SEO production system delivered under their brand for a client.
  • Bilingual sites (EN/ES) that need parity between locales enforced by the system, not by goodwill.

If you are publishing one article every two months because you have no writers, the engine is premature. Solve the writer problem first.

What deliverables do you get?

  • Filesystem content registry — markdown files at src/content/{type}/{lang}/{slug}.md, validated against a Zod schema at build time.
  • Schema-validated front-matter — required fields fail the build before they fail Google Rich Results Test.
  • Dynamic sitemap.xml that walks the registry and emits hreflang siblings inline.
  • llms.txt + llms-full.txt auto-generated from the registry — no hand-maintained manifest.
  • IndexNow integration — fires on every publish and update, no manual ping.
  • JSON-LD generators for Article, Service, FAQPage, BreadcrumbList, Person, Organization, ProfilePage.
  • Quick Answer and FAQ blocks rendered from front-matter on every content page.
  • CMS integration (if applicable) — headless CMS (Sanity, Contentful, Storyblok) plugged into the registry layer.
  • GSC weekly loop runbook — the 60–90-minute Monday ritual, with the exact LLM prompt and CSV procedure.
  • 30-minute handover call + written runbook in the repo.

What tools do you use?

  • SvelteKit / Next.js / Astro / Nuxt — framework-agnostic; the registry pattern travels.
  • Zod for front-matter validation — schema lives in code, breaks the build on bad front-matter.
  • Marked or markdown-it for markdown → HTML.
  • IndexNow API — see the official IndexNow specification for the canonical reference.
  • llms.txt specification — for the AI-engine manifest layer.
  • Google Search Console + Bing Webmaster Tools + Ahrefs Webmaster Tools (free tier) — the weekly-loop data source.
  • Claude or GPT-4.1 — for the weekly GSC analyst loop, not for content drafting.
  • Optional paid: Ahrefs Standard or Semrush — only if you already have a seat.

I'm running this exact playbook on ignax.dev itself — see the live experiment for the registry layout, sitemap behavior, and current publish cadence.

How does the process work?

  1. Discovery call (free, 60 minutes). I review your current content workflow and identify where production friction is highest.
  2. Written scope + fixed quote within 48 hours. CMS integrations are scoped separately if needed.
  3. Build (week 1–3). Registry + schema + sitemap + llms.txt + IndexNow + JSON-LD generators. Daily commits, Friday Loom video.
  4. First-content pass (week 2–4). I run the engine on 5–10 of your existing pages so we catch friction before your team scales up.
  5. Handover. 30-minute call, written runbook including the Monday GSC loop, and the runbook for adding new content types (case study, location, etc.).

Working hours: Mon–Fri, 8:00–17:00 PYT (GMT-3). Weekends off. Overlap with US East 7:00–16:00 EST, with Madrid 13:00–22:00 CET.

How much does a content engine cost?

Pricing band: $3,000–$8,000 USD (Gs 18.4M–49.1M). The lower half covers a single-locale registry + sitemap + llms.txt + IndexNow + JSON-LD layer on a clean modern stack (SvelteKit, Next.js, Astro). The upper half covers bilingual or multilingual sites, headless CMS integration, multi-content-type setups (articles + case studies + locations + services), or migrations from a legacy CMS. Hourly outside that band: $30–$70 USD/hr. PYG values approximate, recalculated quarterly. Rate as of 2026-05-27: Gs 6,136.82 / USD. For tooling tradeoffs see Ahrefs vs free SEO tools.

For agencies — white-label content engines

Most agencies do not have a dev who can also reason about SEO production at this level. Day-rate option: $240–$560 USD/day under your brand and NDA. I deliver under your domain, the agency's team operates the engine, end client never sees me. EN/ES bilingual coverage included. Common pairing: agency owns the editorial work and reporting; I own the engine layer.

What about ongoing maintenance?

The engine is designed to be quiet. Typical maintenance is 2–4 hours/month: schema additions when new content types are introduced, occasional GSC anomalies, IndexNow quota review. I offer this at 15% off hourly, 30-day rolling cancel. Most teams take the runbook and run it themselves — that's the cheaper path and the one I push.

Ready to talk? Email hello@ignax.dev with your site URL and current publish cadence. I review the current workflow before our call.

Working hours: Mon–Fri, 8:00–17:00 PYT (GMT-3). Weekends off. Overlap with US East 7:00–16:00 EST, with Madrid 13:00–22:00 CET.

Pricing

USD
$3,000–$8,000
PYG
Gs 18.4M–Gs 49.1M
Timeline
2–4 weeks

PYG values approximate, recalculated quarterly. Rate as of 2026-05-27: Gs 6,136.82 / USD.

For agencies

Available as a white-label senior subcontractor. Standard NDAs welcome. Day-rate option: $240–$560 USD/day depending on stack.

Email hello@ignax.dev

Frequently asked questions

What's a 'content engine'? Isn't that just a CMS?

A CMS is where editors type. A content engine is the production system around it — the schema-validated markdown registry, sitemap and llms.txt that walk that registry, IndexNow that fires on publish, the GSC-fed weekly loop that decides what to write next, and the JSON-LD that ships with every page. Most teams have a CMS and no engine; the engine is what turns a content team into a publishing pipeline.

Will this work with my existing CMS (WordPress, Contentful, Sanity)?

Yes for headless CMSes (Contentful, Sanity, Strapi, Storyblok) — the registry layer plugs in via the CMS's API and the rest of the engine works the same. For WordPress it depends: with the REST API exposed and a clean post structure, yes. For heavily-customized WordPress with plugin entropy, the engine fights the CMS — I will recommend a static-export migration in the discovery call if that's the case.

Are you going to AI-generate the content?

No. The engine is the production system; the content is still written by humans (you, your team, or contractors). I have strong opinions against shipping LLM-drafted content without review — it kills E-E-A-T, gets caught by AI-content detectors that AI engines themselves run, and reads like everyone else's content. The engine makes publishing fast; it does not replace writers.

How does the weekly GSC loop actually work?

Every Monday, 60–90 minutes. Export GSC queries.csv, pages.csv, position.csv, ctr.csv. Feed to an LLM with a fixed analyst prompt. The output is a prioritized list: pages ranking 11–20 that need a CTR rewrite, queries with traffic but no targeting page, and the next 2–3 articles to write. The full prompt and procedure ship in the runbook. The loop is what compounds — the engine is the substrate.

What's llms.txt and why does it matter?

llms.txt is a filesystem manifest at the site root listing all canonical pages with descriptions, designed for AI engines to discover and respect your content. Combined with FAQPage schema and Quick Answer blocks, it materially increases the chance ChatGPT/Perplexity/Gemini/Claude cite your site by name. The full background is in [llms.txt explained](/articles/llms-txt-explained) and the [official llms.txt spec](https://llmstxt.org/).

What's the difference between this and the SEO + AEO setup service?

[SEO + AEO setup](/services/seo-aeo-setup) ships the foundation (schema, llms.txt, IndexNow, hreflang) on existing pages. Content engine builds the production system that uses that foundation at scale — the registry, the validation, the weekly loop. Most clients buy SEO + AEO setup first and content engine second, once they have proven they can publish weekly. Some buy them together as a single 3–6 week engagement.

Can you white-label this for our agency?

Yes. Content engines are a clean white-label subcontract — most agencies do not have a dev who can also reason about SEO production. Day-rate $240–$560 USD/day under your brand and NDA. I deliver under your domain, your team uses the engine, end client never sees me. EN/ES bilingual coverage included.

What if my team can't keep up with the engine?

Then the engine isn't the bottleneck — content production is. I will tell you in the discovery call whether you have enough writing capacity to justify the engine. For teams without that capacity, I recommend a simpler [SEO + AEO setup](/services/seo-aeo-setup) plus a writing retainer with a content agency. No upselling someone into infrastructure they cannot fill.

Email hello@ignax.dev

Related