How to Add a Blog to a Next.js Site Without Touching Your Codebase
29 May 2026
Share
Made withHyperBlog
Most teams building on Next.js hit the same wall eventually. The product is live, the site is fast, and someone on the marketing team asks for a blog. The instinct is to build it into the existing codebase. That instinct, as we covered earlier, comes with a significant engineering cost that most teams do not anticipate until they are already deep into the project.
There is a cleaner path. And it does not require a single change to your existing Next.js codebase.
The short answer: You can add a blog to a Next.js site by routing a dedicated blog cms for nextjs through your domain as a subfolder using a reverse proxy or DNS configuration. Your Next.js site stays completely untouched. The blog lives at yoursite.com/blog, inherits your domain authority, and runs on entirely separate infrastructure. Setup takes under an hour for most teams.
Before getting into the how, it is worth being clear on what the actual options are. There are three realistic paths, and each one suits a different team situation.
This is the option most Next.js teams do not consider initially because it is less obvious. A dedicated blog platform connects to your existing domain as a subfolder through a DNS or reverse proxy configuration. Your Next.js site stays exactly as it is. The blog runs on the platform's infrastructure, served through your domain.
Your marketing team gets a full content management interface, automatic SEO, lead capture, and analytics without any developer involvement after the initial setup. Engineering does not need to be involved in blog operations at all. For SaaS teams where marketing owns the blog and engineering owns the product, this is the cleanest operational model.
The rest of this post focuses on how option three actually works, because it is the least understood and the most underutilised.
This is the path most engineering teams default to because it feels like the path of least resistance. Everything lives in one codebase. The team controls every detail.
The reality is different. Building a production-ready blog inside Next.js means building a content management interface, per-post SEO management, schema markup, automatic sitemap generation, canonical URL handling, lead capture, and analytics instrumentation. Most of that work does not exist yet in a standard Next.js setup and all of it requires developer time to build and maintain.
For teams with a dedicated infrastructure engineer and genuinely complex content requirements, this path makes sense. For most SaaS marketing teams, it is the most expensive option with the least predictable outcome.
A headless CMS like Contentful, Sanity, or Strapi sits in the middle ground. The content lives in the CMS, the frontend is built in Next.js, and the two are connected through an API. This gives the marketing team a proper content interface and the engineering team full control over the frontend.
The trade-off is that it still requires significant developer involvement to set up and maintain. Every design change to the blog requires a code change. Every new SEO feature is a dev ticket. The marketing team gains content independence but not full operational independence. For teams with frontend engineers available to support the blog on an ongoing basis, this is a legitimate option.
Understanding the technical mechanism here is important because it directly affects SEO and it is the thing most teams get wrong when they first attempt it.
There are two ways to connect an external blog to your existing domain. Subdomain and subfolder.
A subdomain puts your blog at blog.yoursite.com. A subfolder puts it at yoursite.com/blog. From a user experience perspective they look similar. From an SEO perspective they are meaningfully different.
Share your preferred method for integrating a blog into a Next.js site.
What's your preferred method for adding a blog to a Next.js site?
When your blog lives at yoursite.com/blog, every piece of content published there contributes authority back to yoursite.com. Google treats the subfolder as part of the same domain. The domain authority your main site has built over time, through backlinks, age, and trust signals, extends to your blog content.
When your blog lives at blog.yoursite.com, Google treats it as a separate domain. The authority does not transfer in the same way. Your blog is essentially starting from zero in terms of domain authority, regardless of how strong your main site is.
For a SaaS company that has invested in building domain authority on their main site, putting the blog on a subfolder is the only setup that makes full use of that investment. This is why the subfolder approach matters and why it is worth the slightly more complex setup compared to a subdomain.
The subfolder setup works through a reverse proxy configuration. When a request comes in for yoursite.com/blog, your DNS or web server routes that request to the blog platform's infrastructure instead of your Next.js application. The blog platform serves the response, which appears to the user under your domain.
Your Next.js application never sees the request. It has no idea the blog exists. Nothing in your codebase changes. The routing happens entirely at the infrastructure layer, before the request reaches your application.
This is why the setup does not require touching your codebase. The blog and your Next.js site are completely separate systems that share a domain through infrastructure-level routing.
This is the practical implementation guide. The exact steps vary slightly depending on where your Next.js site is hosted, but the core process is consistent across Vercel, Netlify, AWS, and most other hosting providers.
Download our in-depth guide to setting up a blog on your Next.js site. Learn the best practices for SEO and seamless integration.
Before touching any DNS settings, get your blog platform configured first. Choose your Blog CMS for Next.js, complete the initial setup, configure your brand settings, and have at least one draft post ready. You want the blog to be in a publishable state before you connect it to your domain, so you can verify the connection is working correctly end to end.
There are two common methods for connecting an external blog as a subfolder. Which one you use depends on your hosting setup.
Reverse proxy configuration. If your Next.js site is hosted on Vercel, you can configure rewrites in your next.config.js file to proxy requests from yoursite.com/blog to your blog platform. This is a clean solution that keeps everything managed at the application level. The configuration typically looks like a rewrite rule that matches the /blog path and forwards requests to your blog platform's domain.
DNS-level routing. Some blog platforms support direct DNS configuration where you point a specific path on your domain to the platform's servers. This approach varies by platform and DNS provider, so checking the specific documentation for your chosen platform is important here.
For most teams on Vercel, the reverse proxy approach through next.config.js is the most straightforward. For teams on other infrastructure, the DNS approach is usually simpler.
If you are using Vercel, this is the one and only change you will make to your Next.js codebase. It is a rewrite rule, not a code change, and it takes less than five minutes.
In your next.config.js file, add a rewrite that matches incoming requests to /blog and forwards them to your blog platform. The exact syntax depends on your Next.js version, but the structure is a source path of /blog/:path* matched to a destination of your blog platform's URL with the path appended.
Once this is deployed, requests to yoursite.com/blog will be proxied transparently to your blog platform. The user sees yoursite.com/blog in their browser. The blog platform serves the content. Your Next.js application is uninvolved.
Before publishing any content, verify that the connection is working correctly. Check that yoursite.com/blog loads your blog platform's interface. Check that the canonical URLs on your blog posts are set to yoursite.com/blog/post-slug, not to the blog platform's own domain. Canonical URL errors here are the most common setup mistake and they have direct SEO consequences if left uncorrected.
Also verify that your blog platform's sitemap is accessible at yoursite.com/blog/sitemap.xml and that it is using your main domain in the URLs, not the platform's domain.
Once the connection is verified, publish a test post and run it through Google's Rich Results Test. Confirm that schema markup is rendering correctly under your domain. Check that the OG meta tags are pulling the correct post-specific values. Submit yoursite.com/blog/sitemap.xml to Google Search Console under your main domain property.
This verification step takes thirty minutes and catches the configuration errors that would otherwise take months to surface through declining rankings.
One of the legitimate concerns teams raise about the subfolder approach is whether routing blog traffic through a proxy affects the performance of the main Next.js site.
The answer is no, and the reason is clean separation of infrastructure. When a user visits yoursite.com, they hit your Next.js application directly. When a user visits yoursite.com/blog, the proxy routes them to the blog platform's infrastructure. The two systems never compete for resources. Your Next.js application is not processing blog requests. Your blog platform is not affecting your application's response times.
Your main site's Core Web Vitals are completely unaffected by the blog. The blog runs on its own CDN and its own servers. Google measures Core Web Vitals per URL origin, so your blog's performance is assessed independently of your main site.
A well-built blog platform will have its own CDN, fast hosting, and optimised delivery. The blog's Core Web Vitals should be strong on their own merits, not dependent on your Next.js infrastructure.
Having seen this setup implemented across many SaaS teams, the same mistakes tend to appear consistently.
Canonical URLs pointing to the wrong domain. If your blog platform's canonical tags default to the platform's own domain rather than your domain, Google will index the content under the platform's domain and your main site gets no SEO benefit. Always verify canonical URLs before publishing at scale.
Sitemap submitted under the wrong property. Your blog sitemap should be submitted to Google Search Console under your main domain property, not a separate property. If it gets submitted separately, Google treats the blog as a separate site for authority purposes.
Using a subdomain instead of a subfolder. Some teams set up blog.yoursite.com because it is slightly easier to configure. As discussed, this sacrifices the domain authority transfer that makes the subfolder approach valuable. The extra thirty minutes of setup time for the subfolder configuration is worth it.
Not setting up redirects for existing blog URLs. If you are migrating from an existing blog setup, make sure old URLs redirect correctly to the new structure. Broken redirects mean losing whatever ranking signals those old URLs had accumulated.
It works with Vercel, Netlify, AWS, and most standard hosting setups. The configuration method varies slightly but the underlying approach is consistent across providers.
Google sees the content under your domain and treats it as part of your site. The underlying infrastructure is irrelevant to how Google assigns authority and ranks the content.
For most teams, the DNS or proxy configuration takes 30 to 60 minutes. Propagation can take up to 24 hours depending on your DNS provider, though it is usually much faster.
Yes. Most dedicated next.js blog platforms have import tools that handle content migration. The important thing is setting up 301 redirects from old URLs to new ones to preserve any ranking signals the existing content has built.
Adding a blog to a Next.js site without touching your codebase is not a workaround. It is the right architectural decision for most SaaS teams. Your main site stays exactly as it is. Your marketing team gets full operational independence. Your engineering team stays focused on the product.
The subfolder setup takes under an hour to configure and delivers compounding SEO value from day one because every post published under yoursite.com/blog builds authority on the domain you have already invested in.
Meta description: Add a blog to your Next.js site without touching your codebase. Here is how the subfolder setup works, why it wins for SEO, and how to implement it step by step.