How to Add a Blog to Next.js on Vercel Without WordPress

Why Avoid WordPress When Hosting Next.js on Vercel?

Vercel engineered its platform specifically for immutable deployments and serverless architectures. WordPress operates on a directly opposing paradigm. It relies on a stateful environment with mutating file systems and continuous PHP execution to render pages. Attempting to force these two distinct paradigms together creates massive technical debt.

When developers use WordPress as a headless CMS for Next.js, they typically rely on REST API calls or WPGraphQL abstraction layers. This architectural decision introduces severe latency during the build process. Next.js must halt static generation to wait for a distant MySQL database to resolve queries through a heavy PHP application layer.

Furthermore, maintaining a WordPress instance strictly for content creation exposes your infrastructure to continuous security threats. Security patches, plugin updates, and database maintenance consume valuable engineering hours. Senior technical founders recognize that polluting a clean serverless Next.js stack with legacy PHP vulnerabilities is an unnecessary risk.

What Are the Three Ways to Add a Blog to Next.js on Vercel?

When you eliminate WordPress from your stack, you have three primary methodologies for deploying a blog on Vercel. Each architecture carries specific trade-offs regarding build times, operational maintenance, and scalability.

Engineering teams must evaluate these three methods based on their publishing frequency and the technical literacy of their content marketing teams.

Why Does Local MDX Cause Build Bottlenecks at Scale?

Local MDX allows developers to write blog posts using Markdown enriched with JSX components. The files sit directly inside the Next.js repository. For a technical founder publishing a monthly update, this method works well. However, this architecture degrades rapidly as a content library grows.

Next.js must parse every local MDX file during the Vercel build phase. Webpack and Turbopack allocate memory to process the syntax trees, validate the imports, and generate the static HTML files. When a blog scales to hundreds of posts, this static generation process consumes substantial memory and pushes the Vercel build process toward its execution limits.

Local MDX tightly couples content updates to your application deployment pipeline. A marketing manager cannot fix a simple typographical error without requiring an engineer to commit code, push to the main branch, and trigger a full application rebuild. This friction destroys publishing velocity.

What Are the Hidden Trade-offs of Headless CMS Architectures?

To decouple content creation from deployment pipelines, many teams adopt a headless CMS like Contentful or Sanity. While this solves the editorial friction of MDX, it introduces complex data fetching requirements. The Next.js application must fetch content via GraphQL or REST APIs during the build phase using getStaticProps or App Router server components.

This reliance on external APIs creates distinct scaling bottlenecks. Generating one thousand blog posts requires one thousand consecutive API calls. Headless platforms strictly enforce rate limits. If your Vercel build exceeds these limits, the entire deployment fails. Developers must engineer request batching or complex retry logic simply to publish static pages.

Additionally, keeping the live site synchronized with the CMS requires setting up webhook listeners for Incremental Static Regeneration (ISR). When a content editor clicks publish, the CMS fires a webhook to Vercel, which then invalidates the cache and regenerates that specific route. This adds significant operational complexity to your serverless infrastructure.

How Do Vercel Edge Rewrites Route Subdirectory Blog Traffic?

The most robust architecture for adding a blog to Next.js on Vercel is deploying an edge reverse proxy. Instead of forcing Next.js to render the blog, you instruct the Vercel edge network to intercept incoming requests for the /blog path. The edge router immediately forwards these requests to an external, specialized blog engine.

This pattern provides the maximum SEO benefit of a subdirectory without bloating your application code. Modern tools like Nurio function as dedicated edge subdirectory blog engines. They automate the routing and apply Chameleon brand matching so the proxied blog seamlessly mirrors your main application design.

Browser Request (GET /blog/seo-guide)
       |
       v
[ Vercel Edge Network / CDN ]
       |
       +,  Is path /blog/* ? 
                 |
        , , , , -+, , , , -
        |                 |
       YES                NO
        |                 |
        v                 v
[ Rewrite Engine ]  [ Next.js Origin ]
        |                 |
        v                 v
[ Nurio Edge Proxy] [ App Router ]
        |                 |
  Cached HTML        Dynamic Page

Because the proxy resolves at the edge level, the routing execution is virtually instantaneous. Users receive the requested blog post with a Time to First Byte (TTFB) consistently under 50ms.

How to Configure vercel.json for Zero-Maintenance Reverse Proxying

To implement an edge reverse proxy, you must define the routing rules before the request reaches the Next.js runtime environment. The most reliable method is utilizing the vercel.json configuration file located in the root of your repository.

By defining rewrites at the platform level, you ensure Vercel processes the routing natively at the CDN edge. You can learn more about platform-level routing in the Vercel project configuration guide.

{
  "rewrites": [
    {
      "source": "/blog",
      "destination": "https://your-blog-engine.com/blog"
    },
    {
      "source": "/blog/:path*",
      "destination": "https://your-blog-engine.com/blog/:path*"
    }
  ]
}

The :path* wildcard syntax captures all nested routes within the subdirectory. Whether a user requests an index page, an author profile, or an individual article, the Vercel edge transparently forwards the request and returns the upstream response without changing the URL in the browser address bar.

How to Configure Next.js Trailing Slashes and Edge Caching Headers

Alternatively, you can configure your reverse proxy directly inside the Next.js application configuration. This approach is highly effective if you prefer to keep all routing logic inside your JavaScript or TypeScript ecosystem. For advanced implementations, review the Next.js official rewrites documentation.

/** @type {import('next').NextConfig} */
const nextConfig = {
  trailingSlash: false,
  async rewrites() {
    return [
      {
        source: '/blog',
        destination: 'https://your-blog-engine.com/blog',
      },
      {
        source: '/blog/:path*',
        destination: 'https://your-blog-engine.com/blog/:path*',
      },
    ];
  },
};

export default nextConfig;

If you utilize Next.js Edge Middleware for authentication or personalization, you must instruct the middleware to ignore the proxied blog routes. Executing middleware functions on static blog assets consumes unnecessary Vercel execution units and adds latency to content delivery.

import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  // Your application authentication logic here
  return NextResponse.next();
}

export const config = {
  matcher: [
    /*
     * Match all request paths except for the ones starting with:
     * - blog (reverse proxy content)
     * - api (API routes)
     * - _next/static (static files)
     */
    '/((?!blog|api|_next/static|_next/image|favicon.ico).*)',
  ],
};

By explicitly excluding the /blog path in the config.matcher array, you guarantee that Vercel routes the traffic strictly through the rewrite engine without invoking unnecessary serverless compute.

Frequently Asked Questions About Next.js Blog Routing on Vercel

Should I use a subdomain or a subdirectory for my Next.js blog?

From an SEO perspective, subdirectories (example.com/blog) vastly outperform subdomains (blog.example.com). Search engines treat subdomains as entirely separate entities, which fragments your domain authority. Subdirectories consolidate all inbound link equity to your primary domain. If you are currently using a subdomain, you can analyze its impact using the Free Subdomain Checker.

How does Next.js caching interact with edge rewrites?

When Vercel processes a rewrite via vercel.json or next.config.js, it respects the caching headers returned by the upstream destination. If your external blog engine responds with highly optimized Cache-Control and s-maxage headers, the Vercel Edge Network will automatically cache the HTML response globally, eliminating redundant network trips.

Will Vercel charge for bandwidth on reverse proxied requests?

Yes. Any traffic that passes through the Vercel Edge Network contributes to your overall bandwidth metrics. However, because static HTML files for blog posts are incredibly lightweight compared to dynamic application payloads, the bandwidth impact is negligible for the vast majority of engineering teams.

Can I pass authorization headers through Vercel edge rewrites?

Vercel automatically proxies standard HTTP headers through the rewrite engine. If you need to append specific secret keys to authenticate with your upstream headless service, you must use Next.js Edge Middleware to mutate the request headers before allowing the request to proceed to the routing layer.