Why I Say No to WordPress in 2026, and the 2 Cases Where I Still Say Yes

Your site loads in 4 seconds. You paid an agency for it. A year later the dashboard is begging you to update 14 plugins, two of them are flagged as vulnerable, and the renewal invoice for your "managed hosting" just landed at INR 9,000 a quarter. Sound familiar?

That is WordPress for most small businesses in 2026. And when a client comes to me with that setup, I usually say no to rebuilding it on WordPress.

I want to be precise here, because this gets turned into a religious war online and that helps nobody. WordPress is not bad software. It runs a huge slice of the web and it has done that for 20 years. The thing I am saying no to is the default. The reflex where every small business site has to be a PHP app sitting on a database, with a plugin for the contact form, a plugin for SEO, a plugin for caching to fix the speed the first three plugins killed.

For most of the SMB sites I build, I reach for Next.js. Let me give you the real reasons, not the hype ones.

Speed you do not have to fight for

Here is the part nobody tells you. A WordPress site is fast until you make it useful. Add a slider, a popup, an SEO plugin, a security plugin, a page builder, and suddenly you are loading hundreds of kilobytes of JavaScript and CSS before the hero even paints. Then you install a caching plugin to undo the damage, and now you are debugging cache rules at 1 AM.

With Next.js the static parts of your site are just HTML. They ship as files. There is no PHP runtime parsing a request, no database query to render your About page, no plugin stack to load. The browser gets markup and paints it.

I lived this on my own site. webight.com had a hero headline with a 4,190ms LCP render delay. The cause was a framer-motion opacity animation that sat there waiting for hydration before the text would show up. I swapped it for a transform-only CSS animation that runs without waiting for JavaScript, and the render delay dropped to 382ms. Same site, one change, no plugin involved. I also turned on experimental.inlineCss in next.config.ts, which removed two render-blocking stylesheets worth 22.5 KiB. Scores went from 90/96/96/100 to 96/100/100/100 on mobile.

You can do this kind of surgery cleanly when the site is your code. On a WordPress build, that animation would have come from a theme or a plugin, and your fix would be a child theme override fighting an update that overwrites it next month.

A smaller surface for things to break

Every plugin is someone else's code running on your site with full access. The 2026 WordPress install I keep seeing has 12 to 20 of them. Each one is a door. When a popular plugin ships a vulnerability, you are not patching one site, you are patching every site that trusted that plugin, and the attackers know the schedule better than you do.

A Next.js site for a small business has almost no public attack surface. There is no admin login page sitting at a known URL. There is no database exposed to the form on your homepage. Your content is built into static files at deploy time. When I added security headers to webight.com it was a few lines in one config, not a plugin with its own settings panel and its own update cycle.

// next.config.ts
const securityHeaders = [
  { key: "X-Content-Type-Options", value: "nosniff" },
  { key: "X-Frame-Options", value: "SAMEORIGIN" },
  { key: "Referrer-Policy", value: "strict-origin-when-cross-origin" },
  {
    key: "Strict-Transport-Security",
    value: "max-age=63072000; includeSubDomains; preload",
  },
  {
    key: "Content-Security-Policy",
    value: "default-src 'self'; img-src 'self' data: https:; script-src 'self'",
  },
];

const nextConfig = {
  experimental: { inlineCss: true },
  async headers() {
    return [{ source: "/(.*)", headers: securityHeaders }];
  },
};

export default nextConfig;

That is the whole thing. Copy it, adjust the CSP for your scripts, deploy. No dashboard, no monthly plugin lottery.

Hosting that costs you almost nothing

WordPress wants a server that is always on, running PHP and a database, waiting for requests. You pay for that idle time whether anyone visits or not. Managed WordPress hosting in India runs anywhere from INR 400 a month to a few thousand once you need real performance.

A static Next.js site sits on a CDN. For a brochure site or a small business landing page, that often fits inside a free tier on Vercel or Cloudflare. The first real bill might be when you cross serious traffic, and by then the traffic is paying for itself. I ship most client sites on this and the hosting line on their invoice is zero for a long while.

So for the typical SMB site, the one that is a few pages, a contact form, some service descriptions, and a blog the founder updates twice a month, Next.js wins on speed, on security, and on cost. That is most of my work. That is most of the web.

Case 1: a content team that publishes daily without a developer

Now the conditions. The first time I say yes to WordPress is when a real content team has to publish every single day and there is no developer in the room.

See, the thing developers love about Next.js, that the content lives in code or in a headless setup, is the exact thing that breaks for a daily newsroom. If your editor has to open a pull request to fix a typo, or wait for me to deploy their article, the system has failed them. They need to log in, paste their draft, add an image, hit publish, and see it live in 30 seconds. Every day. Five writers at once.

WordPress does that out of the box and it has done it for two decades. The editor, the media library, the scheduled posts, the roles and permissions for who can publish versus who can only draft. You can build all of that on a headless CMS plus Next.js, and for a big publisher I would. But for a 3-person content team that just needs to ship words daily, handing them WordPress is honest. It respects what they actually do all day.

In that case I do not fight it. I make their WordPress fast and locked down, I do not pretend they need a custom stack, and I move on.

Case 2: an existing WordPress site where a rebuild is not worth it

The second yes is the one founders do not expect to hear from a guy who builds in Next.js. If you already have a WordPress site that works, that ranks, and that your team knows how to run, a rebuild is often the wrong call.

A rebuild is not free. It is weeks of my time, it is the risk of breaking URLs you already rank for, it is retraining your team on a new editor, and it is the chance that the new thing has bugs the old thing solved years ago. I have seen founders burn three months and real money to move a working site onto a "modern" stack and end up with the same traffic and a new set of problems.

So I look at the existing site first and ask what it actually needs. Usually it is speed and a bit of SEO hygiene, not a new foundation.

I did this for a client called Zulal. Their PageSpeed sat at 39. I did not rebuild anything. I went in, fixed what was slow, and took it to 77. I did that one free, for goodwill, and they stayed on retainer. The point is the rebuild was never on the table. Fixing what existed gave them the result they actually wanted.

When you fix instead of rebuild, you usually look at the same short list. Strip the plugins you do not need, because every one you remove is speed back and one less door. Add real caching at the edge instead of three competing caching plugins. Compress and lazy-load the images, since on most WordPress sites the images are the heaviest thing on the page. Check your SEO basics, because a site can rank well and still have canonicals pointing one place while the server redirects somewhere else. I found exactly that on my own site, where canonicals pointed to webight.com while the server 307-redirected to www.webight.com, plus 12 deleted case-study URLs still sitting in the sitemap. Boring fixes. They move the numbers more than a rebuild does.

How I actually decide

When a small business comes to me, I do not start from the tool. I start from one question: who touches this site after I leave, and how often?

If the answer is "almost nobody, we update it once a month," it is Next.js. Static, fast, cheap, hard to break. If the answer is "a team, every day, and none of us code," WordPress earns its place and I make it as fast and safe as I can. And if there is already a site doing its job, I fix what is there before I ever talk about replacing it.

The mistake is picking the tool before you have answered that question. People do it in both directions. They put a daily newsroom on a stack that needs a developer for every typo, or they rebuild a perfectly good site because a stranger online said WordPress is dead. Both are the same mistake. The tool got chosen before the work was understood.

So before you ask anyone to build or rebuild your site, answer the boring question first. Who maintains this, and how often do they touch it? Get that right and the stack picks itself. Get it wrong and no framework on earth saves you.