Building a local business website with Next.js: the workflow we use, and when we don't use it

"web page developer" appears in our Search Console export with impressions, rather than recorded visits. It is a broad phrase. This guide takes the perspective of a business owner who wants to understand the work behind a website, including the parts they cannot see.

This article is for that reader. It describes how we build a local business website when Next.js is the right choice, and it starts with two sites where it wasn't.

Two sites that don't use Next.js

Freshly Folded, a laundry pickup and delivery business in San Diego County that we've worked with for more than three years, runs on WordPress with the Elementor page builder. Our own site, luminousdigitalvisions.com, is neither: it's plain HTML generated by a set of Node scripts and deployed on Vercel.

Both choices came from the same question: who edits the site, and how often? A business whose team edits pages in a visual editor, or depends on a WordPress booking plugin, is often better served by WordPress. Our own site changes through code review, so generated HTML suits it.

Next.js is a React framework. It suits a site that needs structured data behind its pages, such as services, locations and bookings, integrations with other systems, and a development team comfortable working in code. When that describes the project, the workflow below is how we run it.

1. Map the URLs before writing code

For a rebuild, the first file isn't a component. It's a spreadsheet of every existing URL and where it will go. Google's guidance on site moves recommends mapping old URLs to new ones, using permanent server-side redirects (301 or 308), avoiding redirect chains, and keeping the redirects for at least a year. A rebuild that skips this can lose the search visibility the old site earned.

For a new site, the same sheet lists the pages the business needs: one per real service, one per area the business actually covers, and the pages a customer needs to book.

2. Put the metadata in the code

In the Next.js App Router, each page's title and description are defined in code: a static metadata object for fixed pages, or a generateMetadata function when the values come from data, such as a location or service record. The framework also supports sitemap.xml and robots.txt as file conventions, generated from the same data. The practical benefit is that a new location page arrives with its title, description and sitemap entry already in place, instead of relying on someone to remember them.

3. Review every change on a preview link

On Vercel, pushing to a branch that isn't the production branch, or opening a pull request, creates a preview deployment with its own URL. The site owner reviews the change on that link, on their own phone, before anything reaches the live domain. Vercel's knowledge base also notes that preview deployments aren't indexed by search engines by default.

This is the part owners tend to appreciate most. They don't approve screenshots. They approve a working site.

4. Check performance against field thresholds

Google's Core Web Vitals include Interaction to Next Paint, which replaced First Input Delay on March 12, 2024. A page's responsiveness is considered good when INP is 200 milliseconds or less, measured at the 75th percentile of real page loads. Lab tests during the build are a start. The field data after launch is what counts, and it takes weeks of real traffic to collect.

5. Automate the checks

Our own site runs a set of validation scripts before every deploy. Among other things, they confirm that every page is reachable, that each blog article has an author byline, that structured data matches the images on the page, and that the sitemap covers every page. A failed check stops the deploy.

In a Next.js project, the same idea applies. Checks run automatically on each preview deployment, so a missing title, a broken internal link or a page left out of the sitemap is caught before the owner reviews the link, not after launch.

6. Hand over something the business owns

Before launch, we agree and write down where each piece lives: the code repository, the hosting account and the domain registration. For most owners, all three should be in the business's name. The handover document says how to deploy a change, where the accounts are and who handles maintenance.

We use AI coding tools during the build, including Claude Code. Our Claude Code guide explains how. The tools change how fast a component gets written. They don't change who reviews it or who owns it.

What the owner can check

After a build like this, the owner should be able to answer five questions without calling us: where the code is, how a change gets previewed, what happened to the old URLs, how the pages perform for real visitors, and who to contact when something breaks.

Our web development service covers business websites, booking experiences and web applications. We choose the platform around the business's editing needs and integrations, and sometimes that's Next.js.

If you're planning a site and want to understand the build before you commission it, book a call and bring your current site, or a list of the pages you think you need.

Sources

• Next.js documentation, Metadata and OG images.
• Vercel documentation, Environments, and Vercel knowledge base, Are Vercel Preview Deployments indexed by search engines?
• web.dev, Interaction to Next Paint (INP) and Interaction to Next Paint becomes a Core Web Vital on March 12.
• Google Search Central, Site moves with URL changes.