Next.js shows up behind an unusually wide mix of well-known sites - Netflix’s jobs portal, Nike’s storefront, Spotify’s web player, OpenAI’s marketing pages, Ticketmaster’s checkout flow - and the pattern across them is not the industry, it is the shape of the problem: content that needs to be fast and indexable, combined with logged-in or interactive parts that need a real backend. Next.js renders the first kind on the server or at build time and the second kind as a normal React app, in the same codebase, which is why it turns up equally often on a marketing homepage and on the dashboard behind the login button. Telling whether a given site runs on it takes under a minute once you know what to look for in the page source.
This is not a top-ten list for its own sake. The companies that chose Next.js share a specific set of constraints, and recognizing those constraints is more useful than the logos - it tells you whether the same choice makes sense for your own project, and the detection tricks below double as a quick audit of any site you are studying.
Table of contents
- The well-known names, and what they actually needed
- How to tell if a site is built with Next.js
- What choosing Next.js implies for a project
- The App Router versus the Pages Router, briefly
- Where a Next.js site actually runs
- How this fits the rest of the stack
- FAQ
The well-known names, and what they actually needed
Nike, Spotify’s web player, Netflix’s jobs and media sites, Ticketmaster, OpenAI, Hashnode and NerdWallet appear in Next.js’s own showcase and in independent roundups. Group them by what they are actually doing rather than by industry, and three shapes repeat: ecommerce storefronts that need product pages to be fast and crawlable while checkout stays fully interactive; content platforms - blogs, documentation, marketing sites - that are mostly static but still need a handful of dynamic routes; and web apps with a public-facing shell wrapped around an authenticated core, like a jobs board or a ticketing flow.
None of that list needed Next.js specifically the way a video codec needs a specific chip - React with a different router and a different build step could serve most of these. What they needed was the rendering flexibility Next.js packages by default: static generation for the pages that do not change per visitor, server rendering or streaming for the ones that do, and a single deploy artifact instead of stitching a separate static site generator to a separate API.
It is also worth noticing what does not repeat: company size, funding stage and technical maturity vary wildly across the showcase, from a solo developer’s portfolio template to Nike’s global storefront. The framework scales down as easily as it scales up, which is a different claim from saying it is the right default for every project - a five-page marketing site with no dynamic parts gets little from Next.js that a plainer static generator does not already provide with less to configure.
How to tell if a site is built with Next.js
- View source, then search for /_next/. Next.js writes its JavaScript and CSS bundles under a /_next/static/ path by default. Seeing that prefix in a page’s asset URLs is close to a guarantee.
- Check the page source for a NEXT_DATA script tag. Server-rendered Next.js pages embed a JSON blob with this id, carrying the props the page was rendered with. It disappears if the app opts fully into the newer App Router’s React Server Components streaming, so its absence is not proof against.
- Look at response headers. Some Next.js deployments (notably on Vercel) send an x-powered-by: Next.js header, though it is one of the first things a security-conscious team disables.
- Right-click, View Page Source, and look for hydration markers. Comment markers around sections of HTML are a React Server Components tell, common in newer Next.js apps using the App Router.
- A browser extension beats manual checking for repeat use. Tools built for detecting web frameworks read the same signals automatically and label the result.
None of these are individually certain - a determined team can strip every one of these signals - but two or three matching together is a reliable call.
What choosing Next.js implies for a project
The companies above did not pick Next.js for the logo. They picked it because their traffic mixes two needs that used to require two different tools: pages that must be fast and indexable for people who are not logged in, and an application that must be interactive for people who are. Server-side rendering and static generation solve the first; React solves the second; Next.js is one deploy path that does both without gluing a separate CMS-driven static generator to a separate single-page app.
That mix is common - a SaaS marketing site sitting in front of a dashboard, a storefront sitting in front of a cart, a content platform sitting in front of an editor - which is why the framework shows up across such different industries. It is a bad fit when a site genuinely is just static content with no interactive core; a plain static generator with a smaller build step does the same job with less runtime to reason about, and Next.js’s own trade-offs are worth reading honestly before adopting it out of habit.
The App Router versus the Pages Router, briefly
A detail that matters for anyone deciding today rather than studying an existing site: Next.js currently ships two different routing systems side by side. The App Router, built on React Server Components, is where new features land first and is what most recent adopters build on. The Pages Router is the older model, still supported, and still what a large share of existing production Next.js sites run because migrating a working app for its own sake is rarely worth the risk.
This matters for detection too - the signals in the previous section differ slightly between the two. A Pages Router app is more likely to show a full NEXT_DATA blob; an App Router app leans more on streaming markers and shows less of the page’s data directly in the source. If a detection check comes back ambiguous, that split is often why. It also means two sites both correctly labeled as built with Next.js can look meaningfully different in the page source, which is worth knowing before treating any one detection signal as the definitive test.
Where a Next.js site actually runs
A Next.js build produces a mix of static assets and a Node.js server process for the dynamic routes (or edge functions, depending on configuration) - it is not, by default, a folder you can drop on a plain static host the way a fully static export would be, unless the project explicitly opts into an export-only build and accepts the static-only limitations that come with it. Most real deployments run the Node server: a Node service on RunxBuild builds from the repository, runs the app behind a live route, and keeps build logs and runtime logs separate so a failed build and a 500 in production do not look identical in the dashboard.
That server process is also why choosing Next.js is a small infrastructure decision, not just a frontend one: it needs a runtime that stays up, environment variables for whatever API keys the app calls, and a rollback path for the inevitable deploy that breaks something. The dashboard treats that the same way it treats any other web service - build, live route, logs, rollback.
How this fits the rest of the stack
Recognizing Next.js in the wild is a five-minute trick. Deciding to build on it is a longer conversation about whether a project actually needs server rendering, or whether that need is assumed because the big names use it. Either way, the framework needs somewhere to run once the decision is made, and the RunxBuild hosting calculator prices a Next.js service the same way it prices any other Node-based deploy - by the plan’s vCPU and RAM, not by which framework generated the code.
Useful related references:
- Next.js Cons: The Real Trade-offs Before You Choose It for Your Stack
- The Next.js Framework: What It Adds and What It Costs
- Vite vs Next.js: Picking Without the Framework Argument
- Next.js services on RunxBuild
FAQ
How can I tell if a website is built with Next.js?
Check the page source for asset paths under /_next/static/, a script tag with id NEXT_DATA, or an x-powered-by: Next.js response header. Newer App Router sites also show React Server Components streaming markers in the HTML comments. Two or three matching signals is a reliable call; a browser extension that detects web frameworks automates the check.
What companies use Next.js?
Publicly documented examples include Nike, Netflix’s jobs site, Spotify’s web player, OpenAI, Ticketmaster, Hashnode and NerdWallet, listed in Next.js’s own showcase and independent roundups. They span ecommerce, content platforms and web apps, but share the same underlying need: fast public pages combined with an interactive, often authenticated, core.
Is Next.js good for a production website?
It is a reasonable default when a site mixes static or server-rendered content with genuinely interactive, dynamic parts - a storefront, a dashboard, an app behind a login. For a site that is purely static content with no interactive core, a plainer static site generator is usually less to run and maintain.
What is the difference between the App Router and Pages Router?
The App Router is the newer routing system built on React Server Components, where current feature development happens. The Pages Router is the older, still-supported model that a large share of existing production apps run on, because a working app rarely justifies a router migration on its own.
Where should a Next.js app be deployed?
Unless it explicitly builds as a fully static export, a Next.js app runs a Node.js server process for its dynamic routes and needs a host that keeps that process running, not a plain static file host. A managed Node service with build logs, environment variables and rollback covers that without custom server configuration.