Next.js, chosen for how pages are rendered
Next.js is a React framework whose defining feature is rendering choice. Each page can be generated at build time, rendered on the server per request, or rendered in the browser. Picking correctly per page is what makes a Next.js site fast and findable; picking by default is why some are neither.
Most framework comparisons are about developer preference. The reason to choose Next.js is more specific: it lets you decide, page by page, where HTML is produced. A marketing page and a logged-in dashboard have opposite requirements, and a framework that forces one answer for both makes one of them worse.
Teams adopt Next.js and then render everything client-side, which discards the reason for adopting it. Content arrives only after JavaScript executes, so Bing, which serves Yahoo and DuckDuckGo, may not see it reliably. Elsewhere the opposite happens: pages are rendered per request when they change monthly, so every visitor triggers work that could have been done once at build. Both are rendering decisions made by default rather than deliberately.
When this work makes sense
Questions worth asking any supplier
Which pages change rarely? Those should be generated at build time and served as files.
Which pages are personalised? Those need per-request rendering and cannot be cached the same way.
Is content in the initial HTML response? View source with JavaScript disabled to find out.
How much client JavaScript ships? The framework does not prevent sending too much.
Where will it be hosted? Some deployment targets support the full feature set and some do not.
Deliverables
A rendering strategy decided per page type rather than applied uniformly
Static generation for content that does not change per request
Server rendering where content is dynamic or personalised
Incremental regeneration so content updates without a full rebuild
Metadata, canonical URLs and structured data generated from content rather than hand-written
Image and font optimisation configured for the deployment target
A performance budget enforced in the build
Deployment set up for your chosen host, including self-hosted Node environments
Built with
Process
The rendering strategy is decided page type by page type before any building, and written down. It sounds procedural and it determines the site's cost, speed and indexability simultaneously, a page generated at build time costs nothing to serve and is instantly available to crawlers, while the same page rendered per request costs server time on every visit for no benefit. Teams that skip this step end up with one strategy applied everywhere, and it is wrong for half the site.
The standard nine stages, discovery, strategy, UX/UI, development, content and SEO, testing, launch, measurement and continuous improvement, apply to every project. The paragraph above is what differs for this one.
What moves the number
Pricing depends on scope, functionality, integrations and content requirements. These are the factors that change it most:
Next.js, plain React, or a traditional CMS
Next.js
Fits: Sites needing speed, search visibility and application functionality together
Limits: More complex than a CMS; needs developers for structural change
Plain React
Fits: Applications behind a login where search visibility is irrelevant
Limits: No server rendering by default; poor choice for public content
Traditional CMS
Fits: Content sites where editors publish and a developer is not available
Limits: Less control over performance and front-end behaviour
Case studies
This site is built in Next.js with a rendering strategy decided per page type and a content gate controlling indexability. The implementation is inspectable rather than described.
MBGDesk operates from 4 offices in India, United States, United Kingdom, United Arab Emirates. We hold no industry certifications and do not imply otherwise.
Frequently asked questions
Is Next.js good for SEO?
It can be, and it does not guarantee anything. Server-rendered or statically generated pages put content in the initial HTML, which is what matters. A Next.js site built entirely client-side has the same indexability problem as any other client-rendered application, the framework enables the right choice rather than making it.
Static generation or server rendering?
Static for anything that does not change per visitor, marketing pages, articles, product listings. Server rendering for personalised or genuinely real-time content. Most sites want both, applied per page type rather than chosen once for everything.
Do we need Vercel to host it?
No. Next.js runs as a standard Node application and deploys to conventional hosting, including shared Node environments. Some features are smoother on platforms built for it; none of the fundamentals require a specific host.
Is it overkill for a small site?
Sometimes. A five-page brochure site that nobody will extend may be better served by something simpler. Next.js earns its complexity when the site will grow, needs an application alongside it, or has performance requirements a simpler stack cannot meet.
What about the App Router?
It is the current direction and brings server components, which reduce client JavaScript substantially. It is also a different mental model from the older approach, so mixing both in one codebase without a plan produces confusion. Choose one for new work and migrate deliberately if at all.
Can we migrate from WordPress?
Yes, and a common arrangement keeps WordPress as the editing interface while Next.js renders the front end. Your team keeps the editor they know and the site gets the rendering control. The trade is running two systems.
How much JavaScript does it ship?
As much as you let it. The framework does not prevent importing heavy libraries or making everything interactive. Server components help considerably, and a bundle budget enforced in the build is what actually keeps it under control.
Services that connect to this
Talk to us about this
Tell us what you are trying to build and we will come back with scope, approach and an estimate.