Why your Next.js site needs a Subdirectory Blog, Not a Subdomain and Not WordPress
02 June 2026
Share
Made withHyperBlog
When a SaaS team decides to add a blog to their Next.js site, the conversation usually comes down to two options. Either spin up a WordPress instance because everyone knows how it works, or put the blog on a subdomain because it seems like the cleanest technical separation. Both feel like reasonable decisions in the planning meeting. Both turn out to be the wrong ones for reasons that only become clear months later when the rankings never materialise.
There is a third option that most teams do not consider seriously until they have already made one of the first two mistakes. And it is the one that actually works.
The short answer: A subdirectory blog at yoursite.com/blog passes domain authority directly to your main site, making every post you publish work harder for your overall SEO. A subdomain at blog.yoursite.com starts from zero authority. WordPress on a Next.js site introduces performance degradation, maintenance overhead, and SEO complexity that most teams severely underestimate. For a Next.js SaaS site, the subdirectory approach with a dedicated blog platform is the setup that ages well.
Before getting into why subdirectory wins, it is worth being precise about what these three options actually are and what each one means in practice.
A subdirectory blog lives at yoursite.com/blog. It sits under your main domain, treated by Google as part of the same site. Every piece of content published there contributes to the authority of yoursite.com directly.
A subdomain blog lives at blog.yoursite.com. It sits on a separate hostname. Google has historically treated subdomains as separate entities from the main domain, meaning the authority your main site has built does not automatically transfer to the blog.
Some teams put their blog on an entirely separate domain. This is the most isolated option and the most SEO-damaging for the main site. It is rare for SaaS teams to choose this intentionally, but it sometimes happens when the blog started as a separate project before the main site existed.
This is not a matter of preference. The SEO case for subdirectory over subdomain has been consistent across industry research, Google's own guidance, and the observed outcomes of hundreds of SaaS content programs.
Your main site has accumulated domain authority over time. Every backlink pointing to yoursite.com, every mention in industry publications, every customer linking to your homepage, all of that has been building a trust signal with Google that makes your domain more likely to rank for competitive keywords.
When your blog lives at yoursite.com/blog:
- It inherits the trust signal your main domain has built
- New posts start their ranking journey with an established domain behind them
- Every backlink earned by the blog strengthens the main domain simultaneously
- The authority compounds in both directions over time
When your blog lives at blog.yoursite.com:
- It starts from zero domain authority
- Backlinks pointing to yoursite.com do not transfer automatically
- The blog builds its own authority in isolation, which is a slower process
- Years of investment in your main domain does not help the blog rank faster
For a SaaS company that has been building domain authority for two or three years, putting the blog on a subdomain means leaving most of that investment on the table.
The authority difference between subdirectory and subdomain is easy to underestimate at the start and hard to ignore by month twelve.
In month one, the gap is small. Both a new subdirectory post and a new subdomain post are starting with limited signals. The subdirectory has a slight advantage from inherited authority but it is not dramatic.
By month twelve, the picture has changed significantly. Every piece of press coverage, every product review, every customer case study that linked to yoursite.com has been incrementally strengthening every post on the subdirectory blog. The subdomain posts have been building their own authority from scratch, competing without the leverage of an established domain behind them.
By month twenty-four, teams that chose subdirectory are typically seeing meaningfully stronger organic traffic growth from the same volume and quality of content. The content is not better. The distribution channel is just more efficient.
The most authoritative SaaS content programs on the internet run as subdirectories. This is not coincidence. It is deliberate SEO strategy by teams that understand exactly where they want authority to accumulate.
The pattern is consistent across the industry. Companies that have built content programs generating millions of monthly visitors have made the subdirectory decision early and stayed with it. The ones that started on subdomains and later migrated to subdirectories consistently report ranking improvements after the migration, once Google has fully processed the change.
Share your current blog setup to see how it compares with industry best practices.
Which blog setup does your team currently use?
WordPress powers a significant portion of the web. The familiarity is real. The plugin ecosystem is enormous. Finding developers who know it is easy. For teams that have used it before, reaching for WordPress when they need a blog is a completely understandable instinct.
But running WordPress alongside a Next.js site creates a specific set of problems that the familiarity argument does not outweigh.
Your Next.js site is a modern JavaScript application. WordPress is a PHP application. When you run both under the same domain, you are managing:
- Two different server environments with different requirements
- Two different sets of dependencies that update independently
- Two different deployment processes with different risk profiles
- Two different security surfaces that both need ongoing attention
- Two different performance optimisation strategies that do not share tooling
This complexity is manageable in isolation. The problem is that it multiplies every time something needs to change. A DNS configuration update, a CDN change, or a security certificate renewal affects both systems and needs to be managed separately through the same change. Teams consistently underestimate this operational overhead until they are living with it.
Next.js is built for performance. Your team chose it in part because of what it does for site speed and user experience. WordPress has made significant performance improvements over the years, but it is still a PHP application with database queries on every uncached page load.
When a reader visits yoursite.com and clicks through to yoursite.com/blog running on WordPress, they are moving from one of the fastest frontend frameworks available to a PHP application. The experience is not seamless. More importantly, Core Web Vitals are measured per URL, so your blog posts need to meet performance thresholds independently. Achieving consistent Core Web Vitals on WordPress requires:
- A caching plugin correctly configured
- A CDN properly set up and tested
- An image optimisation plugin running on every upload
- Regular performance testing after every plugin update
- Ongoing maintenance as WordPress and plugins update
That is a non-trivial operational commitment for a blog that was supposed to reduce the engineering burden.
A WordPress blog needs plugins to function properly for SEO and performance. The minimum viable plugin stack typically includes an SEO plugin, a caching plugin, an image optimisation plugin, a security plugin, and a backup plugin. Each one updates on its own schedule. Plugin updates occasionally conflict with each other or with the WordPress core version.
When conflicts happen, something breaks. Diagnosing which plugin combination caused the issue is a time-consuming debugging process. For a SaaS team where nobody specifically owns the WordPress instance, these conflicts accumulate. Updates get deferred. Technical debt builds. Security vulnerabilities go unpatched. Eventually something breaks at the worst possible moment and the fix takes longer than it should.
WordPress with an SEO plugin gives writers a framework for optimising each post. But it is still a manual process per post. The writer needs to fill in the focus keyword, meta description, OG image, and schema settings every time. When they do not, the post goes live with default or missing values.
At ten posts per month this is manageable. At thirty posts per month it starts breaking down. Writers miss fields. Editors do not catch it. Posts accumulate with missing meta descriptions and default OG images. The automatic technical SEO that should be handling this ends up inconsistently applied across the archive, and the ranking impact shows up months later when it is harder to diagnose.
A dedicated blog platform connected to your Next.js site as a subdirectory sidesteps both the authority problem and the WordPress complexity problem in one decision.
The blog lives at yoursite.com/blog, inheriting the domain authority your main site has built. Every post published there contributes back to your main domain. The authority compounds in the right direction from day one.
The blog runs on entirely separate infrastructure from your Next.js application. There are no two tech stacks to manage, no plugin conflicts, no WordPress updates to schedule and test. Your Next.js application is completely uninvolved in serving blog content.
Technical SEO across schema markup, canonical tags, sitemap updates, and OG meta generation is handled automatically on every publish. The marketing team publishes without filing a single dev ticket. Engineering stays focused on the product.
As covered in the guide on adding a blog to a Next.js site without touching your codebase the subdirectory connection is set up through a reverse proxy configuration that takes under an hour and requires one rewrite rule in next.config.js. After that, the two systems are cleanly separated and independently maintained.
For teams evaluating blog CMS options built for Next.js sites, the subdirectory setup is supported natively, meaning no custom proxy configuration is needed beyond a straightforward DNS change.
To be fair, there are situations where a subdomain is a reasonable choice rather than a wrong one.
Your main site is very new. If your domain has minimal authority to pass on, the compounding argument weakens in the short term. The difference between subdirectory and subdomain is smaller when there is not much to compound from.
You deliberately want content separation. If the blog serves a meaningfully different audience from the main site and you want Google to treat it as a distinct entity, a subdomain gives you that separation. This is rare for SaaS blogs but it exists as a legitimate use case.
Technical constraints make subdirectory difficult. If your hosting setup makes subfolder configuration genuinely complex and the team does not have the bandwidth to work through it, a subdomain is better than no blog. Start with subdomain and migrate to subdirectory when bandwidth exists.
For most SaaS teams in most situations, these exceptions do not apply. The subdirectory setup is worth the additional configuration time.
Whether you are setting up fresh or migrating from an existing setup, these are the mistakes that consistently cause problems:
- Canonical URLs pointing to the wrong domain. If your blog platform defaults canonical tags to its own domain rather than yours, Google indexes the content under the platform's domain and your main site gets no SEO benefit. Always verify before publishing at scale.
-Sitemap submitted under the wrong Search Console property. Your blog sitemap should be submitted under your main domain property. If submitted separately, Google treats the blog as a separate site for authority purposes.
- Not setting up redirects during migration. If you are moving from an existing setup, 301 redirects from old URLs to new ones preserve the ranking signals those URLs have already built. Missing redirects means starting from zero on content that has already earned authority.
- Choosing subdomain because it is faster to configure. The thirty minutes saved in setup compounds into months of slower ranking growth. It is rarely worth it.
Google has stated both can work, but independent SEO research and real-world outcomes consistently show subdirectory performing better for authority transfer across competitive niches.
Manageable but not trivial. It requires 301 redirects from every old subdomain URL, updated internal links, a resubmitted sitemap, and two to three months for Google to fully process the change. Starting with subdirectory avoids all of this.
Your main site scores are unaffected. But your WordPress blog posts are measured independently and need to meet performance thresholds on their own, which requires careful and ongoing WordPress optimisation.
Yes technically. But you still have two tech stacks to maintain, plugin conflicts to manage, and manual SEO work per post. The proxy solves the URL structure problem but not the operational ones.
The setup decision you make for your blog is not just a technical preference. It is an SEO decision with compounding consequences over the lifetime of your content program. A subdirectory blog starts with your domain's full authority behind it and builds from there. A subdomain starts from zero. WordPress adds operational complexity that grows over time rather than reducing it.
For a SaaS team that has invested in building a strong Next.js site and wants a blog that compounds that investment rather than diluting it, the subdirectory approach is the setup that makes every post work harder from the day it is published.