My 2026 Publishing Stack: 11 Portals + One Apex Blog for AEO and GEO

guptadeepak.com runs as eleven sub-portals plus one apex blog, deployed as a single Cloudflare Worker reading from a unified static tree. Eleven independent content surfaces, one origin, one deploy artefact, one cross-link layer. The architecture exists for a specific reason: AI search rewards focused authority on narrow topics, and a network of focused portals beats a monolith on every metric that matters in 2026.

This post is the operator's view of the stack. The reader-focused version ("which portal should I read for what") is the 11 portals and the pain each one solves. This post is for the practitioner who is trying to build something similar, or who is sceptical that the architecture pays off, and wants to see the bill of materials.

The structural choice: network vs monolith

The default 2018-era content architecture is the monolith. One domain, one CMS, one editorial pipeline, one set of categories. Every article lives in a single content database. The advantage is operational simplicity. The disadvantage is that no single page on the site has a clear, narrow topical identity to AI engines doing entity extraction.

The 2026 alternative is the network. Each focused topic lives on its own portal, with its own URL structure, its own content schema, its own internal taxonomy, and its own llms.txt and llms-full.txt. The apex blog stays a blog. The portals stay structured reference sources. Cross-linking is explicit and audited.

The network's advantage is that each portal develops a much sharper entity profile in AI engines. ChatGPT does not see guptadeepak.com as "a blog that covers many things." It sees CIAM Compass as the CIAM reference, GEO Compass as the GEO reference, Future Tech as the predictions source. Each one becomes a citable, named entity. The portals reinforce each other through cross-links and through shared author identity.

The monolith's disadvantage compounds. A blog with 600 posts on twelve topics has weaker per-topic authority than twelve portals with 50 reference pages each on a single topic. The retrieval layer behind AI search is closer to entity-based than to keyword-based, and the network wins on entity coherence.

The four layers

Layer 1: publishing (Next.js, Astro, Cloudflare Workers)

Each app picks its own framework. Eight of the eleven portals are Next.js (mixed across 14, 15, and 16, because each app's dependencies are isolated by the pnpm workspace). One is Astro (the web stories portal, which needs AMP and gets it more cleanly from Astro). The apex blog is Next.js with static export.

Each app builds to its own static output. A repo-level script assembles all of them into a single dist/ tree, with each app mounted at //. A single Cloudflare Worker fronts the whole tree: it attaches security headers, handles redirects, detects whether the first URL segment is a known sub-property, and otherwise rewrites the request into the apex blog's subtree.

The deploy artefact is one Worker version, deployed by GitHub Actions on push to main. There is no CMS, no database, no edge KV. The whole site is static HTML served from Cloudflare's edge, with a Worker that does routing, security, and 301s.

The cost of this stack at current traffic is approximately zero. Cloudflare Workers' free tier covers the request volume. The static assets are bandwidth-included in the Pro plan I already pay for. The marginal cost per portal added is also approximately zero, because each portal builds independently and shares no runtime dependencies.

Layer 2: content (JSON for apex, TS for portals, MDX for some)

The content format is deliberately different per portal, because the right format depends on what the content is.

The apex blog uses JSON. Every post is one JSON file with html, plaintext, frontmatter, tags, and schema fields. The format inherited from the Ghost CMS the apex migrated off of, and turned out to be ideal for AI agents writing new posts (they can write JSON reliably) and for build-time validation (every field is typed).

The portals that are reference databases (Future Tech, Books, Podcasts, Tools) use TypeScript. The data is structured: each entry has the same fields, the fields are typed, and the build verifies coverage. TypeScript also gives the build pipeline the leverage to derive related-content sections, tag pages, and JSON-LD schema at compile time, with no runtime cost.

The portals that are long-form reference (CIAM Compass, GEO Compass, Hash Lab) use MDX. The content is articles, not records. MDX gives the author the prose tools without losing the embedded data components.

The mistake to avoid is forcing one content format across all portals. The format should match the content shape. A blog wants prose with frontmatter. A directory wants typed records. A reference wants prose with embedded structured components. Picking one format and forcing the others into it costs you the leverage of having picked the right format.

Layer 3: cross-link (portal-links package + relatedPosts)

Cross-linking between portals is explicit, audited, and centralised. There is a single source of truth (a portal-links TypeScript module) that lists every portal, its canonical URL, and its label. Every portal's footer reads from this module to render the "Across guptadeepak.com" column. Adding a new portal is one line in the module.

Cross-links inside articles are managed by a script that maintains a canonical-URL cheatsheet (LINKS.md). The script knows every public URL on the site and surfaces them at write time. A broken-link checker runs as part of the build and fails the deploy if any internal link 404s.

The relatedPosts pattern lives inside each portal's data. Reference entries on GEO Compass list the related apex blog posts. Apex blog posts link to the relevant portal entries. The links are typed and validated at build time, so a renamed portal slug breaks the build instead of breaking the link.

This is the layer most teams underinvest in. Cross-linking is what turns a network of portals into a single brand, and the network effect only emerges when the cross-linking is comprehensive and current.

Layer 4: AI search (llms.txt, llms-full.txt, JSON-LD schema)

Each portal publishes its own llms.txt and llms-full.txt. The llms.txt is the navigational summary. The llms-full.txt is the full text of the portal's authoritative content, structured for AI crawlers that want to retrieve in one fetch.

The schema layer is JSON-LD, per portal, sized to the content. The apex blog uses Article schema on every post, Organization on the about page, and BreadcrumbList everywhere. The reference portals use the schema appropriate to their content (SoftwareApplication and Product on tools, FAQPage on guides, ItemList on directories, HowTo on tutorials). The structure is described in the state of AI search 2026 guide and the entity authority for AI engines guide.

The schema is generated at build time from the typed content. This matters: hand-written schema goes stale fast and is impossible to audit at scale. Generated schema stays correct because the content and the schema share a single source.

The methodology behind the GEO discipline I apply across the stack is documented at geo-compass/methodology.

What each portal surface owns

The portals divide into four categories by content shape.

Editorial. The apex blog ("guptadeepak.com"). Long-form opinion, original analysis, dated posts. The voice surface, the brand surface, the part that compounds reputation.

Reference. CIAM Compass, GEO Compass, Customer Identity Hub, Hash Lab. Structured topic libraries with guides, glossaries, vendor pages, and methodology documents. The authority surface, the part that gets cited by AI engines as the canonical source.

Comparison and directory. Tools, Podcasts, Books, E-books, Startup Offers. Typed directories with opinionated curation. The discovery surface, the part that wins "best of" and "compare X to Y" queries.

Editorial-meets-data. Future Tech, Tech Graveyard, Research, Web Stories. Each entry has data fields (confidence, date, status) and a long-form prose section. The combined shape is what gives them durable AI-citation traction on questions like "what is the current state of X" and "what happened to Y."

The split matters because each category needs a different operational rhythm. Editorial wants new posts on a steady cadence. Reference wants quarterly refreshes with visible changelogs. Directories want monthly additions plus an aggressive removal policy for stale entries. Editorial-meets-data wants new entries when the underlying world changes, not on a calendar.

How the network interlinks for AI search

The cross-linking is the part that produces network value rather than additive value. Specifically:

Apex blog posts about GEO link to specific GEO Compass guides. The GEO Compass guides link back to the relevant apex blog posts via relatedPosts. The Tools portal includes case-study links to the apex blog posts that exercise the tool. The E-books portal links to the apex blog posts that reference each e-book. The Future Tech portal links to the apex blog posts and the Tech Graveyard for the historical companion. Each portal's footer offers a direct link to every other portal.

The result is that an AI engine retrieving any single page gets enough signal to discover the network. The portals reinforce each other on entity disambiguation: when ChatGPT is uncertain whether "GEO" means "Generative Engine Optimization" or "geographic," the dense cross-linking from CIAM Compass and Hash Lab makes the first definition unambiguous in context.

This is documented at scale in the GEO product-content advantage and the complete guide to generative engine optimization.

Editorial discipline

The lint catches what humans miss. The build pipeline includes:

• Em-dash blocker (the long horizontal dash glyph and its HTML entity equivalent are both rejected in any content file)
• Banned-phrase warner (covers the common AI-output tells that signal low-effort or model-generated copy)
• Internal-link checker (every internal URL must resolve)
• Schema validator (the generated JSON-LD must parse)
• Sitemap and llms.txt regenerators (run on every build)

Scheduled publishing runs through GitHub Actions on an hourly cron. A post with a future published_at is filtered out of the build until the cron picks it up. There is no editorial CMS, no "draft" mode toggled in a UI. The whole publishing process is a git operation.

This sounds austere. In practice, it is the thing that has made the publishing rate sustainable. Removing the CMS removed three categories of mistake that used to consume editorial time: stale drafts, accidentally-published pages, and CMS-induced HTML cruft. The git workflow makes every editorial change reviewable and reversible.

The architectural tradeoffs (what you give up)

This stack is not for everyone. The honest tradeoffs:

You give up rapid editorial UI. If your editorial team is non-technical, they cannot write a post without a code change. The workflow assumes the writer is comfortable with git, Markdown or JSON, and a PR-based review cycle. This is a hard constraint.

You give up cross-portal search. Each portal builds its own search index. There is no unified search across the network. I have not built a federated search because I do not need one (the user typically knows which portal they want), but at higher portal counts this would become a real gap.

You give up shared session state. Each portal is a static export. There is no login, no personalisation, no per-user content. This is a feature, not a bug, for this content; for product-led portals it would be limiting.

You give up framework consistency. The portals run mixed versions of Next.js and one Astro app. The dependency graph is a working compromise, not a clean architecture. The cost is paid in repo complexity. The benefit is paid in per-portal velocity.

The tradeoffs are worth it for my use case because the alternative (one giant monolith with shared dependencies) was the constraint I was trying to escape. If your editorial pipeline runs through non-technical staff, or if your content is genuinely interactive, the network architecture is the wrong fit.

For the practitioner

If you are trying to build something similar, the four decisions in approximate order of importance:

1. Pick the topical decomposition first. The portals should be defensible as named entities. Not "my blog about identity, security, and growth." Specifically: CIAM, GEO, founder reading, predictions, each as its own surface.
2. Pick the content format per portal. Match the format to the content shape, not to your team's habits.
3. Pick the cross-link mechanism early. Retrofit is expensive; greenfield is cheap.
4. Pick the static-first deploy. The cost structure and the AI-friendliness are both better than a dynamic stack at the content scales most operators reach.

The stack is open. The repo structure, the assembler script, the worker code, the editorial lints, the schedule-publish workflow, and the cross-link package are all visible in how the site builds itself. If you are running content for a B2B SaaS team and want to talk through the architecture, the surface area for that conversation is the apex blog and the contact link on it.

Adjacent reading: SaaStr AI Annual 2026 on LLM visibility and GTM, and the GEO Compass methodology for the GEO discipline applied to every portal in this stack.