Web Development

Next.js website development – how it differs from a template site

A Next.js website is code written for one specific site, where a developer decides how each page is generated, how fast it loads and what bots see, instead of a theme and a stack of plugins. A template site launches faster, but it inherits someone else's code, most of which you don't need.

Next.js is a React framework that can produce HTML ahead of time, on the server for each request, or in the browser. For a business that means three things: the content is in the HTML before any JavaScript runs, the page loads only what it uses, and new features (a calculator, a client portal, a CRM integration) are added in the same project rather than through yet another plugin.

I don't think every site has to be built in Next.js. If you need a simple brochure site edited by a few people and you don't plan to grow it, a well-maintained WordPress install will do. I choose Next.js when the site has to earn money: generate leads, sell, serve customers or grow new features.

Business website, online store or web app – what you actually need

The type of project follows from what the user has to do: read and get in touch (website), buy (store), or do work after logging in (web app). That answer drives the architecture, the budget and the timeline.

• Landing page – one page, one goal, usually a paid campaign or a launch. See high-performance landing page.
• Business website – a dozen to a few dozen pages for customers, candidates and partners, with a CMS and integrations. That is the scope of a corporate website.
• Online store – catalogue, cart, payments. When a theme stops being enough, I propose a headless Shopify store; for wholesalers with per-customer price lists, a B2B platform.
• Web app – a dashboard, portal or internal system. Data design, APIs and permissions matter here as much as the interface.

Mixed projects are common: a business site with a client portal, or a store with a product configurator. Plan one shared architecture from the start instead of bolting an app onto a site built on a different system.

SEO-ready architecture – rendering, Core Web Vitals and structured data

An SEO-ready site sends its content, links and structured data in the server's HTML and stays within the Core Web Vitals thresholds. You can't add this properly after launch, because it depends on the rendering approach chosen at the start.

Rendering: what Google and AI crawlers see

Google processes JavaScript pages in three phases: crawling, rendering and indexing, and rendering waits in a queue. Google's JavaScript SEO documentation still calls server-side rendering or pre-rendering "a great idea" and reminds readers that not all bots can run JavaScript. In "The rise of the AI crawler" (2024), Vercel found that none of the major AI crawlers, including GPTBot and ClaudeBot, rendered JavaScript at the time. Content that only appears after scripts run may simply not exist for ChatGPT or Claude. I go deeper in my post on JavaScript SEO and AI crawlers.

The Next.js docs describe ISR as updating static pages without rebuilding the whole site, which lets you serve large amounts of content without long builds. In practice I pick the mode per page type, not one mode for the whole site.

Core Web Vitals and structured data

According to web.dev, a page has good Core Web Vitals when LCP is 2.5 s or less, INP 200 ms or less and CLS 0.1 or less, measured at the 75th percentile of visits. Google recommends hitting these, but its page experience documentation says good scores don't guarantee top rankings, because relevance comes first. I treat speed as a requirement, not an advantage on its own. My Core Web Vitals guide covers how to fix each metric.

Structured data gives Google, in its own words, explicit clues about the meaning of a page and can enable rich results. Google recommends JSON-LD. I generate it from the same data as the visible content (Organization, Product, BreadcrumbList, FAQ), so the schema never drifts from what users see. Details are in my Schema.org guide.

Which CMS to choose – WordPress, headless CMS or Shopify

I choose a CMS based on who edits content, how often, and what the site has to do beyond displaying text. There is no best system, only one that fits your team.

• WordPress (classic) – sensible for a simple site, many editors and a small development budget. Weak spot: plugins that slow the site down and need constant security updates.
• Headless CMS (Sanity, Contentful) – you edit content in a dashboard and the Next.js frontend pulls it through an API. A good choice when speed, language versions and custom components matter. Most of the business sites I build use this setup.
• Shopify – when you sell online and want a proven backend for products, payments and orders. The storefront can stay on a theme or go headless.
• No CMS – a campaign landing page that rarely changes sometimes doesn't need an editor. I make changes in code, which can be cheaper than maintaining a system.

Whatever the option, one rule holds: the content, the code and the accounts (domain, hosting, CMS) belong to you. Parting ways with a developer must never mean losing your site.

Headless Shopify – when a custom storefront makes sense

Headless Shopify keeps Shopify as the engine for products, payments and orders, while the storefront customers see is built separately, in my case in Next.js. Shopify describes it as all the power of Shopify under the hood with complete control over the frontend.

It makes sense when the theme is holding you back: you need an unusual UX, you combine selling with rich content, you sell in several countries, or product pages are slow because of apps and scripts. It doesn't make sense for a new store with a dozen products where nobody touches the layout. Invest in a good theme and content instead.

Shopify offers its own framework, Hydrogen, hosted on Oxygen. I build the storefront in Next.js because one project then covers the store, the blog, a headless CMS and the company site. Your team keeps working in Shopify Admin; only the layer customers see changes. The scope is described under headless Shopify store.

Migrating to Next.js without losing Google rankings

A Next.js migration is safe when every old URL has a new equivalent and a 301 redirect, and metadata, structured data and internal links move together with the content. The biggest drops I see come from lost URLs, not from the change of technology.

Google's site move documentation recommends server-side redirects from old to new URLs according to your mapping, without chains and without sending everything to the home page. Keep the redirects for as long as possible, generally at least a year. Google also warns that on a medium-sized site it can take a few weeks or more for the new URLs to replace the old ones in results, and ranking fluctuations in that period are normal.

1. Export every URL: from the sitemap, a crawl, Search Console and backlink data.
2. Build a 1:1 redirect map and decide which pages to merge or remove.
3. Migrate route by route, starting with the highest-traffic pages, with tests before and after.
4. Switch over and monitor 404s, indexing and Core Web Vitals over the following weeks.

That is how I run a Next.js migration. If the domain or the whole site structure changes too, I follow the checklist from SEO migration without losing rankings.

How a website or web app gets built – the process step by step

I work in four stages: strategy and audit, information architecture with wireframes, development with integrations, and SEO audit, QA and launch. Each stage ends with something you approve before I move on.

• Strategy and audit – the site's goal, the customer journey, analytics data and success metrics. Without this you design something pretty, not something that works.
• Architecture and wireframes – sitemap, content hierarchy and wireframes for approval before any code is written.
• Development and integrations – Next.js code, CMS, forms, CRM, analytics, payments. Every change goes to a preview you can click through.
• SEO audit, QA and launch – metadata, structured data, device testing, 301 redirects and monitoring after go-live.

On the client side, the biggest time sink is usually supplying copy and photos. That's why I ask for them at the wireframe stage, not a week before launch.

How much a website costs and how long it takes

With me, a landing page starts from €1,000, a corporate website from €3,000, a Next.js migration from €2,500 and a headless Shopify store from €4,500. SaaS interfaces and B2B platforms are quoted individually, because their cost depends mainly on integrations and business logic.

What drives the price up

• Integrations – CRM, ERP, ATS, payments. Every external system means documentation, testing and error handling.
• Language versions – separate content, hreflang and often separate CMS workflows.
• Content migration – moving hundreds of posts and URLs with redirects is real work, not copy and paste.
• Custom features – configurators, calculators, client portals, 3D.
• Content readiness – a project without copy and photos takes longer and costs more, because wireframes need rework.

When comparing quotes, look at total cost: hosting, CMS and plugin licences, maintenance and the cost of every future change. A cheap template can get expensive in year two.

How to measure results and maintain the site after launch

I measure a site by leads or sales, organic traffic and Core Web Vitals from real-user data, not by a single Lighthouse run. Maintenance means security updates, monitoring and small improvements, not just paid hosting.

• Business – conversions in GA4 (form, call, purchase) and cost per lead from campaigns.
• Visibility – clicks, impressions and indexed pages in Search Console, and increasingly your brand's presence in AI answers.
• Technical – field Core Web Vitals, 404 and 5xx errors, server response time.

The past year shows why maintenance matters. In December 2025 the React team disclosed a critical vulnerability in React Server Components (CVE-2025-55182, CVSS 10.0) that allowed remote code execution and affected Next.js among others. The fix was an immediate upgrade. A site without someone watching these advisories stays exposed, even though it "still works".

The second topic is accessibility. The European Accessibility Act (Directive 2019/882) applies from 28 June 2025 and covers e-commerce services among others. In Poland it is implemented by an act of 26 April 2024; according to gov.pl, it does not apply to services provided by micro-enterprises, but a larger store has to ensure digital accessibility. Check with a lawyer whether it applies to your business. I build semantic HTML, contrast and keyboard support from day one, because retrofitting them costs more.

Agency or freelancer – how to choose a web developer and which mistakes to avoid

An agency makes sense when you need many roles at once (branding, campaigns, video) and a large team. An independent specialist works well when you want to talk directly to the person who writes the code and owns the result. Either way, the answers to a few questions matter more than the business model.

Questions to ask before signing

• Who exactly will write the code, and can I talk to them?
• How will you choose the rendering approach and check what Google and AI crawlers see?
• Who builds the redirect map when the site changes, and from what data?
• Who owns the code, the repository, the domain and the accounts?
• What does maintenance include: updates, backups, response to vulnerabilities?
• Can I see live projects and their results, not just screenshots?

The most common mistakes when commissioning a website

• Choosing by the look of a mockup – without a goal, a customer journey and metrics, the site is pretty but doesn't sell.
• SEO "later" – rendering, URLs and heading structure decided after launch mean a rebuild.
• Migrating without a 301 map – the fastest way to lose years of work on visibility.
• Code and accounts in the developer's name – makes switching providers hard and can become leverage.
• No maintenance budget – an unpatched site keeps its vulnerabilities and slows down with every plugin.
• A plugin for everything – every extra script costs speed, and hardly anyone counts it.

I combine the roles of Next.js developer and SEO specialist, so I plan architecture and visibility together. If you already have a site and want to know what slows it down first, start with a technical audit and Core Web Vitals review.