← Writing

Bringing my blog home: Hashnode → felixdiez.es/blog

  • #meta
  • #seo
  • #astro

For a while my blog lived on a hosted platform under blog.felixdiez.es. It worked. So why move it?

Two reasons: the way I publish, and where the authority lands.

Publishing should match how you already work

For most people a hosted blog is the easier option — you open an editor, you write, you hit publish. But my whole working life is already Markdown in a git repo, driven from my phone through an AI agent. Publishing a post, for me, isn’t “open a web editor.” It’s “write me a post about X” → a .md file → commit → push → deploy. That collapses into the exact muscle I use for everything else.

The lesson generalizes: the cheapest publishing flow is the one that matches the tools you already live in. For me that’s a repo. For you it might be something else — but it’s worth being honest about what you find frictionless, rather than copying someone else’s stack.

Subdirectory, not subdomain

The other decision was felixdiez.es/blog (a subdirectory) versus blog.felixdiez.es (a subdomain).

Google officially says it handles both fine. But the practitioner consensus — backed by migration case studies — is that a subdirectory consolidates authority on one host. Link equity and topical relevance accrue to a single domain instead of being split across two.

For a personal brand that’s the whole point. Everything — portfolio, writing, reputation — should make one domain stronger. Splitting it across a subdomain quietly works against your own goal.

The historical reason people reached for a subdomain was technical: their blog ran on a different stack than their main site, and stitching a subdirectory to a different backend meant fiddling with a reverse proxy. The moment the blog is the same stack as the site, that constraint disappears — and the subdirectory becomes both the better-for-SEO and the simpler-to-ship choice.

Owning the thing

There’s a third, quieter reason: ownership. My URLs, my markup, my presentation, no platform that can pivot, change its terms, or disappear. The content is plain Markdown in a repo I control. If the rendering layer ever changes, the posts come along untouched.

That’s the trade I made. Not because hosted platforms are bad — but because, in my setup, owning it is also the easier path. When the principled choice and the lazy choice point the same way, take it.