· Iren Saltali · operations · 2 min read

From Ghost Blog to Product-Led Content Hub

Why moving the blog into the product’s own landing repo improves canonical control, internal linking, and reader trust.

The short answer: A first-party content hub is easier to govern because canonicals, redirects, internal links, product context, and build-time validation live in the same repo as the site that benefits from them.

When to read this

  • You are consolidating content systems.
  • You want stronger internal linking between product pages and articles.
  • You need a cleaner search and AI-facing content graph.

What matters in practice

  • Content and product context belong together when the main goal is product education.
  • First-party canonicals reduce cross-domain confusion.
  • A repeatable generation and redirect process makes the migration safer.

Concrete example

    - One domain for canonicals and internal links
  - One repo for redirects, sitemap, and feed generation
  - One content model for migrated and net-new posts

The example above is intentionally small because the best gateway configs stay readable. Add only the route, auth, and mapping behavior you actually need.

How this maps to the current gateway

The current codebase already supports the behavior discussed here through its config schema, route matcher, and integration handlers. That is why this project is a good fit for reader-first examples: the docs and blog can point to real, implemented behavior instead of hypothetical gateway features.

What this product does not do

  • Migrating content systems still requires careful redirect and asset validation.
  • A first-party content hub does not replace the need for editorial discipline or product-truth review.

FAQ

Why not keep Ghost and the landing repo separate?

Because split canonicals, split navigation, and split publishing rules usually create SEO and maintenance drift.

What matters most in the migration?

Stable URLs, preserved content value, and clear new first-party ownership of the blog.

  • build a cloudflare worker api gateway in 30 minutes
  • serverless api gateway vs cloudflare workers hand rolled
  • how to test an api gateway before production

Last reviewed: March 6, 2026

Back to Blog

Related Posts

View All Posts »

Why Wildcard Routes Go Wrong

How broad route patterns accidentally shadow specific endpoints, and how the gateway’s match priority helps you avoid it.