Subdomain or subdirectory for Web3 SEO: the blog dilemma

Their blog is pulling in solid organic traffic — sometimes thousands of visitors a month, content ranking on page one for valuable search terms — yet the main application sits invisible on the second or third page, gathering dust while the team wonders why no one is discovering the product itself. The content is fine. The product is fine. What tends to be wrong is the structure underneath — specifically, whether the blog lives on a subdomain like blog.project.com or in a subdirectory like project.com/blog.

This is one of those decisions that gets made early, often casually, and then quietly compounds into a structural tax on organic growth for years. And for Web3 teams in particular — where the marketing surface area is already smaller, where trust deficit is the default, where every percentage point of search visibility matters because paid acquisition is expensive and conversion is uncertain — the subdomain-versus-subdirectory question deserves more than a quick technical default.

We've watched teams treat this as a one-time setup detail and then spend eighteen months trying to recover authority they didn't realize they were fragmenting. We've also watched teams swing too hard the other way, collapse a perfectly working blog back into the root domain, and discover that the reverse proxy setup was more friction than their small team could sustain. The right answer, as is often the case in growth work, depends on what you're actually optimizing for — and how long you intend to play.

A subdomain is not a free decision. It is a slow, quiet fragmentation of the authority your brand domain has spent months — or years — earning.

The SEO mechanics of domain consolidation: why subdirectories often win

Let's start with the mechanism, because the rest of this conversation only makes sense once we agree on what we're actually talking about. When you publish a blog on project.com/blog, every backlink that article earns, every mention a journalist writes, every internal link from a partner, every bit of anchor text and referring domain strength — all of it accrues to the root domain project.com. Your blog content and your product page are not just co-located; they share the same authority pool. Search engines can see them as one continuous site, with one accumulated trust profile, one history of inbound signals.

When you publish that same blog on blog.project.com, you have, in the eyes of most search engines, created a separate site. Yes, Google has said repeatedly — Matt Cutts back in 2012, John Mueller again in 2017 — that its search engine treats subdomains and subdirectories roughly equivalently. And that statement is technically accurate at the algorithmic level. But practitioners, the people running the actual experiments, have observed something different in practice for over a decade: subdirectories consolidate link equity faster and rank new content more quickly. The Salesforce migration is the canonical case study here — moving their blog from a subdomain into a subdirectory of salesforce.com roughly doubled organic traffic, not because the content changed, but because the authority flow changed.

For a Web3 project, this distinction matters in ways it doesn't for a B2B SaaS company. Your root domain is your identity on the search results page. It's what appears in the title tag when someone searches for your protocol, your token, your governance mechanism. If your blog lives on a subdomain, the editorial work you're doing to build topical authority — explaining your category, educating potential users, capturing comparison queries — that work accrues to blog.project.com rather than to the domain users actually type into their wallets and explorers. The trust signals you'd want feeding into your main brand live somewhere else, and the path between them is not as clean as the URL suggests.

We should be honest about what we don't know here. The exact percentage of link equity lost when content lives on a subdomain instead of a subdirectory — nobody publishes that number with rigor, because it's variable and contested. AI Overviews and other newer search features may or may not favor consolidated structures; that's still an open question. What's not open is the directional answer: subdirectories win on consolidation, and the cost of fragmentation is real even if the precise magnitude is fuzzy.

Security isolation and the Web3 tech stack dilemma

Now here's where the conventional SEO advice breaks down a little, and where Web3 teams have a legitimate reason to pause before collapsing everything into a single domain. The standard wisdom in marketing circles is "always use subdirectories." But the standard wisdom was written for companies whose main application is a marketing website — a static page or a content management system that doesn't handle user authentication, doesn't touch private keys, doesn't store anything sensitive in the browser.

Your dapp is not that.

When you host your blog at project.com/blog, you are serving content from the same origin as your main application. The Same-Origin Policy — a foundational security boundary in every browser — means that a vulnerability in your blog (a compromised dependency, a malicious comment, a misconfigured CMS that allows XSS) can theoretically reach the local storage, cookies, and session data of the application running at project.com. For a Web3 product, that local storage might contain wallet connection state, session tokens, or cached preferences tied to user identity. The blast radius of a content-layer bug suddenly includes your actual product surface.

This is why many security-conscious Web3 teams default to a subdomain even knowing the SEO cost. blog.project.com is a separate origin. A bug there is contained. The trust deficit that already exists between users and crypto applications — the scars from a decade of exploits and drainers — means that the security calculation for Web3 is not the same as for a content site. Some teams have decided, with good reason, that a moderate SEO penalty is a price worth paying to keep the wallet layer physically separated from the editorial layer.

The question is whether that trade-off still holds once you look closely at the alternative.

The pragmatic answer, in our experience, is to reverse-proxy your subdirectory through a layer that gives you the SEO benefit of consolidated hosting while keeping the actual application origin protected. That brings us to the infrastructure question.

Technical implementation: reverse proxies and infrastructure requirements

The cleanest version of "blog in a subdirectory" assumes that your main domain and your blog are running on the same stack. If you're a Next.js dapp with a CMS bolted on, and both live on the same Node process, this is straightforward. Most teams are not in that situation.

More commonly, the marketing site and the dapp are deployed separately — the dapp might be a static build on IPFS, the blog might be Ghost or WordPress, and the team has been told "put it on a subdomain because it's easier." That's true. It's also where the slow leak of authority begins.

To host a blog at project.com/blog while the main app lives elsewhere, you need a reverse proxy — Nginx, Caddy, or Cloudflare Workers are the common choices — sitting in front of both and routing /blog/* to the blog backend while everything else goes to the application. This isn't rocket science for a senior engineer, but for a lean Web3 team where the engineering capacity is already being consumed by protocol work, it represents real operational friction. It means another service to monitor, another deployment pipeline, another place where DNS, TLS, and caching configurations can drift.

The costs stack up in smaller ways, too. A wildcard SSL certificate — which you'll typically need to serve project.com, blog.project.com, app.project.com, and so on from a unified certificate — runs roughly a hundred to a hundred and fifty dollars a year, compared to around fifty for a single-site certificate. DNS propagation when you add new subdomain labels can take anywhere from a few minutes to forty-eight hours, which sounds trivial until you're debugging why staging isn't resolving during a launch.

Each subdomain label is also constrained by a hard limit: sixty-three octets maximum per label, two hundred and fifty-five total for the entire domain name. That's not a problem you'll hit with sensible naming, but it's the kind of small thing that bites you at the worst possible moment when you're six levels deep in some staging environment a contractor built.

We'd be misleading you to claim the reverse proxy approach is risk-free or easy to maintain indefinitely. It is not. But for most teams that have decided the SEO trade-off matters, it is tractable — and the operational cost is far smaller than the long-term cost of fragmented authority.

The reverse proxy is the bridge between SEO ambition and operational reality. It is not free, but it is cheaper than the alternative once you project forward twelve months.

The hidden costs of subdomain fragmentation in Search Console

There's a quieter tax on subdomain hosting that doesn't show up in your traffic dashboards for a while, and that is the fragmentation of your analytics and search infrastructure itself.

When your blog lives on blog.project.com, you are running a separate Google Search Console property. You are configuring separate tracking properties in whatever analytics tool you use. Your team is checking two indexes, two sets of coverage errors, two performance reports, two verification flows. Every time Google changes something in Search Console — and it does this more often than people realize — you have to remember that you have two sites to verify against. When a backlink audit reveals toxic links pointing at your blog, you have a separate disavow workflow. When you migrate to a new CMS, you have two property migrations instead of one.

This compounds over time, and the compounding is invisible until someone new joins the team and asks, "why are we maintaining two of everything?" The answer is usually a shrug and a reference to some Slack thread from two years ago where someone said "subdomain is easier."

For sustainability — a word we use deliberately here, because we mean it across operational, financial, and reputational dimensions — the consolidation of search infrastructure matters more than most teams account for. The smaller your team, the more every doubled surface area costs you. And in Web3, where growth teams are chronically understaffed relative to the scope of work, the hidden costs of fragmentation are felt disproportionately hard.

It is also worth saying, in the interest of not overstating the case: a subdomain blog is not doomed. Teams do rank on subdomains. We have seen it work, especially when the subdomain has accumulated its own authority over years. The framing is not "subdomains fail." The framing is: if you're starting fresh, if you're trying to capture the maximum benefit from your editorial work for your brand domain, if you're trying to minimize operational overhead — a subdirectory, served through a reverse proxy, is the structurally cleaner choice. And if you already have a subdomain blog that ranks, the cost-benefit of migrating is a separate analysis we'd want to talk through with you before recommending the move.

Evaluating third-party publishing platforms versus self-hosted solutions

A final piece of the puzzle, and one we see teams wrestle with regularly, is the choice between self-hosting the blog and publishing on a Web3-native platform like Mirror.xyz. Both have surface appeal, and both come with real trade-offs.

Mirror offers a frictionless publishing experience — you write, you publish, you get a custom subdomain at name.mirror.xyz, and you tap into an existing crypto-native audience. For a team that needs to ship editorial quickly, that low friction is genuinely valuable. The cost is structural: hosting your blog on Mirror does not build SEO authority for your primary brand domain. None of it. Content published on Mirror lives on Mirror's own infrastructure, so every backlink, every mention, every authority signal accrues to the platform itself — not to your project. Your publication simply becomes a path on someone else's domain, no matter how cleanly your handle is presented in the URL. If your goal is organic discovery for your project — for users searching your protocol name, your token name, your category terms — Mirror is not where that work happens.

For a team's own narrative and community alignment, though, Mirror still has a role. We sometimes recommend a hybrid: Mirror for community-facing writing, drops, and rapid publishing where the audience is already gathered; a self-hosted subdirectory blog for the SEO-driven content that you want to accrue authority to your brand domain over months and years. That kind of alignment — between platform choice and intent — tends to be where the highest-leverage publishing setups come from.

It is not a question of "self-host everything" or "give up on owned media." It is a question of routing different kinds of content to the surfaces that serve them best, while making sure the SEO-critical work is happening on a domain you control.

Where this leaves the team that asked the question

So — to come back to the founder who came in wondering why the blog outranks the dapp, and what to do about it. The diagnosis is almost always one of three things: the blog is on a subdomain and the authority has fragmented; the blog is on a third-party platform and the authority isn't even accruing to your brand; or the blog and the dapp are on the same origin and there's a security conversation to be had. Sometimes all three.

The path forward usually looks like this. Decide where you want the authority to live — almost always project.com/blog. Reverse-proxy the subdirectory if the stacks differ, and budget the operational cost honestly. Consolidate your Search Console and analytics so that everything points at one property. Treat the blog as part of the product, not as a separate content channel, because in SEO terms it is the same site.

And the last thing we'd want to leave you with — the question we keep coming back to with the teams we work with longest — is this: when you imagine your project three years from now, when the protocol has shipped, the token has found its market, the community has grown into something durable, what does the search landscape look like around your brand? Do you want a single, authoritative domain that owns the conversation about your category, or do you want a constellation of subdomains and platform accounts that each carry a slice of who you are? The structural choice you make in the next quarter quietly answers that question for you — and it compounds, the way all structural choices do, until it becomes the foundation you either build on or spend years trying to unwind.

What does the foundation you're laying today make possible for the brand you'll be running tomorrow?