Next.js vs WordPress: What Popular Sites Actually Use

WordPress is a content management system (CMS); Next.js is a framework for building websites and applications with React. They do not sit on the same shelf: one gives you a ready admin panel and a plugin ecosystem, the other an empty project and full control. The short answer: if the site's value is in its pages, WordPress; if it is in behaviour, Next.js. If you need both, there is a third route: WordPress stores the content and Next.js renders the page.

This comparison is usually made with global data. We looked at Türkiye instead. We scanned the home pages of the 200 most popular .tr sites in the Tranco list and classified what 162 of them run on. The result differs sharply from the global picture. Next.js, at 12.3 percent, is more than twice as common as WordPress, at 5.6 percent (Caliency measurement, 20 October 2026).

We compared custom code and WordPress in general in Custom Code vs WordPress. This post asks a narrower question: Next.js itself, its rendering modes, the Türkiye data and the option of running both systems together.

Are WordPress and Next.js the same kind of thing?

No. WordPress is a working product: install it and you get an admin panel, users, a media library and a publishing workflow. Next.js is a building block: install it and you get an empty project, and you either write everything yourself, admin included, or connect a CMS.

WordPress's official directory lists over 76,000 free plugins (WordPress.org, plugin directory). That is WordPress's biggest strength and also the source of its maintenance load; we come back to both below.

In practice the difference looks like this. Changing a headline in WordPress needs no developer; in Next.js, unless a CMS is connected, it does. On the other hand, a calculator, a member dashboard or a live pricing screen is a natural part of a Next.js project. In WordPress, those are handled with plugins or by writing a custom plugin.

What do Türkiye's popular sites run on? We measured it

Method: We took the 200 most popular .tr domains in the Tranco top 100,000 (list 64VKX) and fetched each home page once on 20 October 2026 (Tranco, list 64VKX). We did not execute JavaScript; we looked at the HTML the server sent and at the response headers. 162 sites returned a measurable page. 26 hit bot protection or an access block, 11 failed on connection, TLS or DNS, and one redirected to a site already counted.

We used only narrow, documented signatures. For WordPress we looked for /wp-content/ or /wp-json/ paths on the site's own domain. For Next.js we looked for /_next/static/ and __NEXT_DATA__, and for ASP.NET for the __VIEWSTATE field and ASP.NET session cookies. We first verified the signatures of Turkish e-commerce platforms (Ticimax, IdeaSoft, T-Soft, ikas) on known customer sites. The full list is in the chart's source note. A site that matched no signature was not guessed into a category; we counted it as "custom or unidentified".

Findings (Caliency measurement, 20 October 2026):

• The largest group is custom software: 37.7 percent of the 162 home pages (61 sites) show no trace of an off-the-shelf platform.
• ASP.NET at 25.3 percent (41 sites): Microsoft's .NET stack. 18 of the 45 public-sector sites (.gov.tr) fall into this group.
• Next.js at 12.3 percent (20 sites): By far the most common JavaScript framework.
• WordPress at 5.6 percent (9 sites): It shows up behind the scenes as a content store on two more sites, covered below.
• Hosted e-commerce platforms are almost absent: Shopify, Wix, Ticimax, IdeaSoft and ikas appeared on no home page; T-Soft appeared on one.

Split by domain type, the picture sharpens:

Commercial sites lean towards Next.js the most. Public-sector sites run on ASP.NET more often than on anything else. Universities are the only group where WordPress is relatively strong, and even there other PHP-based systems (such as Laravel and CodeIgniter) are more common. We measured the structured data side of the same 200-site sample in our AEO post.

Against the global numbers, the order flips

W3Techs data dated 20 October 2026 puts WordPress on 39.6 percent of all websites and 58.3 percent of sites whose CMS is known (W3Techs, WordPress usage statistics). The same source sees Next.js on 3.7 percent of all websites (W3Techs, Next.js). ASP.NET is used by 4.2 percent of sites whose server-side language is known (W3Techs, ASP.NET).

In our sample the order nearly reverses: WordPress 5.6 percent, Next.js 12.3 percent, ASP.NET 25.3 percent.

Comparing the two directly would be wrong, because the populations differ. W3Techs measures the web at large, much of which is small-business sites and blogs. Ours is made up of Türkiye's most visited sites: media groups, banks, ministries and universities. HTTP Archive's Web Almanac 2025 also notes that high-traffic sites tend to choose platforms that support complex workflows and deep customisation. Even so, the same report says WordPress accounts for roughly 58 percent of CMS usage among the top 10,000 websites (Web Almanac 2025, CMS chapter).

Our reading: Türkiye's large sites do work that does not fit an off-the-shelf CMS, and most have built their own software teams. The weight of ASP.NET in the public sector probably reflects how long these institutions have worked on Microsoft infrastructure. We did not measure that; we note it as an inference.

Does using Next.js mean "rendered on the server"?

No, but that is the default. In Next.js's current App Router, pages are Server Components by default: HTML is produced on the server, optionally cached and streamed to the browser. Parts that need interactivity run in the browser as Client Components (Next.js, Server and Client Components).

A Next.js page can be produced in three ways:

• Static: HTML is generated once at build time. The fastest and cheapest route for company pages.
• Incremental Static Regeneration (ISR): a static page is refreshed in the background at set intervals, without rebuilding the whole site (Next.js, Incremental Static Regeneration).
• Dynamic: the page is rendered on the server for every request; needed for personalised content.

There is also a fourth state you can fall into by accident. Next.js's own error documentation says that reading useSearchParams() without a Suspense boundary opts the entire page into client-side rendering. The page can then stay blank until the JavaScript has loaded (Next.js, Missing Suspense with CSR bailout).

We saw traces of this in our measurement. Of the 20 home pages using Next.js, 14 were built with the App Router and 6 with the older Pages Router. 18 sent full HTML from the server. Two returned an almost empty shell: their visible text did not exceed three words, and one carried Next.js's marker for falling back to client-side rendering. Five responses carried an x-nextjs-cache header, showing the page came from Next.js's cache (Caliency measurement, 20 October 2026).

This is not a Next.js-only problem. Of the 9 home pages built with Angular, AngularJS, Nuxt or plain React, 5 also returned an empty shell. The lesson: a framework makes server rendering easy, but does not guarantee it. What matters to search engines and AI crawlers is what the server actually sends. We cover the SEO side in SEO-friendly website.

Speed: why do Next.js sites pass less often?

The short answer: in the field they pass less often on average. The cause is less the framework itself than the kind of sites built with it and the JavaScript they send to the browser.

In HTTP Archive's Core Web Vitals Technology Report for July 2026, 33.9 percent of Next.js origins passed all three thresholds on mobile (349,852 origins). The figure is 49.5 percent for WordPress and 53.2 percent for the web as a whole (HTTP Archive, Core Web Vitals Technology Report). The report's September 2026 data points the same way: Next.js 35.7 percent, WordPress 48.3 percent.

The gap opens widest on interaction. On INP, which measures responsiveness to interactions, 58.8 percent of Next.js origins are rated good against 91.0 percent of WordPress origins. On server response time (TTFB) the order reverses: Next.js 46.1 percent, WordPress 24.4 percent (same source, July 2026, mobile).

Why? web.dev's guide to client-side rendering says two things. Even with a React framework that renders on the server, components still need to be hydrated in the browser if the page is interactive. Sending most of the HTML from the server lets the browser break up the work and avoid long main-thread tasks (web.dev, Client-side rendering of HTML and interactivity). INP measures exactly that kind of blocking.

This is a population comparison, not an experiment. Many sites built with Next.js are app-like, interaction-heavy products; WordPress sites are mostly content pages. The data does not prove WordPress is faster. What it shows is narrower: choosing Next.js is not, by itself, a speed decision. We showed how the two stacks fail in opposite places in Custom Code vs WordPress, and explained the metrics in our Core Web Vitals guide.

The third route: headless WordPress with Next.js

In a headless setup, content is written in the WordPress admin, but Next.js, not WordPress, renders the page. Next.js pulls the content from the WordPress REST API. WordPress's documentation describes that API as an interface for applications to exchange JSON objects with a site. It is also the foundation of the Block Editor (WordPress Developer Resources, REST API Handbook).

Our measurement shows traces of this model. On two of the 20 Next.js sites we saw signs of a separate CMS behind the front end. One linked into an Umbraco back office; the other loaded WordPress media paths from a separate content host. One university site also served WordPress content through a front end built with Angular (Caliency measurement, 20 October 2026).

What you gain: editors keep the panel they know and the front end is completely free. The same content can feed a website and a mobile app at once.

What you pay: two systems to build, two to update, two to host. Things WordPress gives you out of the box, such as previews, forms and page builders, are rebuilt in the front end. We cover that trade in our headless CMS post. Our view: headless is worth the price only when a second channel, such as a mobile app, an in-store screen or another site, genuinely exists.

Whose job are maintenance and security?

Both options carry risk. The difference is where the risk comes from and whose job it is to close it.

In WordPress, most of the risk comes from plugins. According to Patchstack's 2026 report, 11,334 new vulnerabilities were found in the WordPress ecosystem in 2025, a 42 percent increase on 2024. 91 percent were in plugins and 9 percent in themes; only 6 were reported in core, all low priority. For heavily exploited vulnerabilities, the weighted median time from public disclosure to the first exploitation attempt was 5 hours (Patchstack, State of WordPress Security in 2026). The report draws on the vulnerability database of Patchstack, a security company.

Next.js is not exempt. In December 2025, a flaw in the React Server Components protocol allowed remote code execution in Next.js 15 and 16 applications using the App Router. It was rated CVSS 10.0, the highest severity score (Next.js, Security Advisory CVE-2025-66478). 14 of the 20 Next.js sites we measured used the App Router; we did not measure versions, so we do not know which were affected.

The real difference is in patching. In WordPress, plugin and core updates can be applied from the admin panel. In Next.js an update is a code change: the dependency is upgraded, the site rebuilt and redeployed. Without a developer to do that, the patch waits. We cover the maintenance cost of both in our website maintenance post.

Which should you choose? A decision table

The shortcut: first answer "after launch, who will change the site, and how often?" A marketing team points to WordPress; a software team points to Next.js. If you have both and need a second channel, headless.

Why we don't always say Next.js

Caliency's website is built with Next.js. Still, let us say it plainly: for a content-heavy company site of 10–30 pages or a regularly updated blog, WordPress is often the better and cheaper choice. That the large sites we measured lean towards Next.js does not mean you should; those sites have their own software teams behind them.

The reverse holds too: turning WordPress into an application with plugins looks cheap in the short term and gets more expensive with every update. We describe how we work with both on our web development page.

What we did not measure

• Home pages only. A domain's blog or shop may run on a different stack. On some sites we saw separate WordPress installs on subdomains and did not count them.
• No JavaScript was executed. Sites that leave platform traces only in code loaded in the browser fell into the "custom or unidentified" group.
• The signatures are conservative. WordPress sites that hide their paths can be missed. One site had renamed its WordPress paths and added a misleading Drupal generator tag; we caught it through WordPress's API link. 6 of the 41 ASP.NET sites rest only on a server header (IIS or X-Powered-By).
• No versions. We do not know which sites are current and which run a vulnerable version.
• We did not measure the speed of these 162 sites. The figures in the speed section are HTTP Archive's global data.
• The sample is popular sites. It does not represent small businesses in Türkiye; WordPress's share among them is probably much higher, but we did not measure it.
• 38 of the 200 sites could not be measured; all shares are of the remaining 162.

Frequently asked questions

What is the difference between WordPress and Next.js?

WordPress is a ready-made content management system (CMS) for editing content from an admin panel; it runs on PHP and is extended with themes and plugins. Next.js is a framework for building websites and applications with React; it ships no content panel, and everything is built in code. So they are not in the same category, and they can be used together: WordPress stores the content and Next.js renders the pages.

Is Next.js faster than WordPress?

Not in the field, on average. In HTTP Archive's July 2026 data, 33.9 percent of Next.js sites passed all three Core Web Vitals on mobile, against 49.5 percent of WordPress sites. That is not a controlled experiment; it shows the field average of sites built on each stack. You can build a very fast site with Next.js, but choosing the framework does not make a site fast on its own.

What do popular sites in Türkiye run on?

Across 162 popular .tr home pages that Caliency measured on 20 October 2026, the largest group is custom software showing no off-the-shelf platform (37.7 percent). ASP.NET (25.3 percent) and Next.js (12.3 percent) follow. WordPress sits at 5.6 percent, while worldwide W3Techs puts WordPress on 39.6 percent of all websites.

What is headless WordPress, and when does it make sense?

In headless WordPress, content is written in the WordPress admin, but a separate front end such as Next.js renders the pages. The front end pulls the content as JSON from the WordPress REST API. It makes sense when there is a real need, such as serving the same content to a website and a mobile app. The price is building, updating and hosting two systems instead of one.

Which should I choose for a company website?

If the site's value is in its pages and a non-developer team will publish content every week, WordPress is usually the better choice. If the value is in behaviour, such as logins, dashboards, calculators or integrations, and you have a development team to maintain it, Next.js comes out ahead. Either way the site needs an owner: if nobody is responsible for updates, neither option is safe.

In short

WordPress is a CMS and Next.js a framework: one gives you a ready panel and plugins, the other an empty project and full control. Across 162 popular .tr sites in the Tranco list, the picture is the reverse of the global average. Next.js runs 12.3 percent, WordPress 5.6 percent, and the largest group, at 37.7 percent, is custom software (Caliency measurement, 20 October 2026). What large institutions choose is not a template for a small company.

The framework does not decide speed either: Next.js sites pass less often in the field on average, because speed depends on the JavaScript sent to the browser. The question that decides the choice is this: after launch, who will change the site?

If you want to work out which is right for your site, get in touch. Once the stack is settled, our SEO services help the site get found.