Deploying your Next.js landing page on Vercel: the step-by-step guide

You bought a template and followed the case for Next.js over WordPress: good news, the hardest part is done. One step remains that many non-developers dread for no good reason — putting the project online. With Vercel (the platform built by the creators of Next.js), it's actually the fastest part: ten minutes, no credit card, and a landing page reachable worldwide. Here is the full path, from the downloaded folder to the custom domain pointing at it.

Why Vercel rather than a traditional host

A traditional shared host runs your page from a single server, somewhere in one country: a visitor far from that server waits longer than everyone else. Vercel works the opposite way — your static landing page is replicated across a worldwide network of edge locations, and each visitor gets served from the node closest to them. That is exactly the subject of a recent study measuring latency from edge datacenters: moving compute closer to the user measurably cuts response times compared to traditional cloud regions, with gains in the range of 15 to 19% depending on the user's location (Martin & Dogar, 2023). For a page where every second of load time costs conversions, that's not an infrastructure footnote — it's a direct advantage, with zero special configuration.

The other difference is structural: no FTP, no admin panel to secure, no database to back up. Vercel deploys straight from a Git repository — every code update becomes a live release within seconds. The free ("Hobby") plan is more than enough for a sales landing page: generous bandwidth, automatic HTTPS, custom domain included.

What you need before you start

• The template folder downloaded after purchase (a self-contained Next.js mini-project, with its own package.json).
• A free GitHub account — the bridge between your code and Vercel.
• A free Vercel account (sign up directly with "Continue with GitHub", no extra password needed).
• Optional at this stage: a domain name, if you don't want to stay on the default address (your-project.vercel.app).

The step-by-step guide: from downloaded folder to live page

1. Create a Git repository for the project

On GitHub, create a new repository (private, ideally, until the page is ready to be shown). From the local template folder, initialise Git and push the code: git init, git add ., git commit -m "Initial import", then git remote add origin <repo-url> and git push -u origin main. If the command line isn't your thing, GitHub Desktop achieves the same result with drag-and-drop.

2. Import the project into Vercel

From the Vercel dashboard, click "Add New… → Project", then select the repository you just pushed. Vercel automatically detects it's a Next.js project and pre-fills the build configuration — in the vast majority of cases, there's nothing to change. Leave the defaults and click "Deploy".

3. First deployment and preview

The build usually takes between 30 seconds and 2 minutes. At the end, Vercel shows a URL like your-project.vercel.app with a clickable preview: your landing page is already live, publicly reachable, HTTPS enabled by default. This is the moment to test the mobile and desktop rendering, and check every section displays correctly.

4. Customise before sharing the link

The README shipped with every LanderKit template explains how to edit the copy, colours and images from the files in components/. Forms are deliberately shipped as mailto: links or a fake "Thanks!" state — it's up to you to wire them to your own tool (Brevo, Tally, Google Forms…) before the final launch. Every change pushed to GitHub automatically triggers a new deployment.

5. Connect a custom domain

In the Vercel project settings, the "Domains" tab lets you add a domain or subdomain: Vercel shows the two DNS records to create with your registrar (an A or CNAME record, plus usually an automatic redirect for www). Propagation takes anywhere from a few minutes to 24 hours depending on the registrar. Whether to use a dedicated domain or a subdomain depends on your overall strategy — we cover both options in our subdomain vs. dedicated domain comparison.

6. Automatic deployments and per-branch previews

Once the repository is connected, every git push to the main branch automatically republishes the page to production — no FTP, no manual click. And every side branch or pull request generates its own preview URL, isolated from production: you can test a new headline or a new visual without risking breaking the live page. This isn't just developer comfort: a study of continuous delivery practices found that organisations which deploy frequently and automatically, in small reversible changes, achieve better operational outcomes than those relying on rare, large releases (Forsgren & Humble, 2016). For a landing page you keep adjusting through testing, that safety net genuinely changes how you iterate.

The mistakes that break a deployment

• Test the build locally before pushing: run npm run build on your machine before any significant deployment — a TypeScript error or a broken import shows up in seconds, instead of after a round trip through Vercel.
• Public repository too early: if the page isn't ready to be seen, keep the GitHub repository private (free) — Vercel connects to it without any issue.
• Mistyped DNS records: a DNS value copied with an extra space or trailing dot is enough to block propagation — copy exactly what Vercel shows, without adding anything.
• Confusing the preview URL with the final domain: until a custom domain is connected, the .vercel.app URL works perfectly but isn't meant to be advertised — set up the domain before launching your campaigns.

After going live: the first-24-hours checklist

• Run the page through a PageSpeed Insights test to confirm green Core Web Vitals.
• Register the domain in Google Search Console and submit the sitemap.
• Wire up conversion tracking in GA4 before sending a single paid visitor.
• Fill out a real form end to end to verify the notification or confirmation email actually arrives.

A/B testing a static Next.js landing page: split URL, edge, and feature flags

Classic visual A/B testing tools rewrite the page after it loads — a real problem on a static landing page optimised for speed. Here are three methods that preserve your Core Web Vitals: split URL testing, edge feature flags, and when a visual tool's trade-off is actually fine.

1. Split URL testing: two pages, one edge redirect

1. Duplicate the page into a new route folder (/offer-b) and change only the element being tested — one change at a time, so you can attribute the effect with confidence.
2. Write a middleware that reads an existing cookie or, failing that, randomly picks a variant and sets that cookie for the duration of the test (30 days is enough in most cases).
3. Silently rewrite (a rewrite, not a visible redirect) visitors assigned to variant B from the original URL, so you keep a single URL to share in ads.
4. Send the variant seen as a custom parameter to your analytics tool, so you can compare conversion rates by group once the test is over.

Whichever method you choose, a sneakier danger lurks: an unintentional imbalance in traffic splitting. In their reference study published in 2012 at the KDD conference, Ron Kohavi and his Microsoft co-authors document this phenomenon under the name sample ratio mismatch — a programmed 50/50 split that ends up, in practice, at 47/53 because of CDN caching, poorly filtered crawler traffic, or a redirect that is slower for one variant than the other (see the study). Such an imbalance silently invalidates the test's results, with no alert ever triggered. On an edge architecture like Vercel, concretely check the actual traffic split in your analytics after a few days, before trusting the conversion numbers.

From Figma to a Next.js landing page: what always gets lost in translation

A mockup approved in a meeting, then a landing page shipped three weeks later that no longer quite matches: spacing that crept tighter, a fallback font flashing for an extra beat, a button that doesn't respond the way it did in the prototype. This isn't a one-off slip — it's a gap measured in design-work research, and there are concrete ways to close it.

A study by K. J. Kevin Feng, Tony W. Li and Amy X. Zhang, presented in 2023 at CHI — the largest research conference on human-computer interaction — on the collaborative practices of interface designers inside companies, documents what the authors call design-development divergence: the mockup and the shipped product drift apart over the course of a project, because the reasoning behind each visual choice (why this spacing, why this fallback font) doesn't survive the move from the design tool to the code editor. Visual information travels through the mockup; the intent that produced it often gets lost along the way.

What a Figma mockup never shows

• Responsive behavior between breakpoints. Figma renders one state per screen width (mobile, tablet, desktop); it doesn't show how a headline reflows at 850 pixels wide, between the two drawn frames — the developer decides, usually without a written spec.
• Real interaction states. A hover, a keyboard focus, an "in-progress" form-submission state sometimes exist in a Figma prototype, but rarely for every single component; keyboard accessibility in particular gets coded from scratch most of the time.
• Font and image loading. A mockup shows the final font instantly; a browser downloads the font before rendering it, with a flash-of-unstyled-text swap that Figma can't represent — a detail that directly affects the LCP measured in production.
• Real content, longer or shorter than the placeholder text. A 4-character client name in the mockup can turn into 22 characters in production, and break a layout that was never tested with real text.

Next.js static export: should you host your landing page without Vercel or a server?

A Next.js template doesn't need a server to run. With the output: "export" option, Next.js produces a folder of already-computed HTML, CSS and JavaScript files, deployable on any host or CDN — often free, with no database and no serverless function. What you gain, what you lose, and which landing pages it's the right fit for.

This choice also has a security upside that rarely gets mentioned. Behnam Shobiri, Mohammad Mannan and Amr Youssef, in "CDNs' Dark Side: Security Problems in CDN-to-Origin Connections," published in 2023 in Digital Threats: Research and Practice (ACM) (see the study), audit 14 commercial CDNs and show that none of them properly validates the origin server's certificate, and that several let the CDN-to-origin connection travel unencrypted — a flaw that specifically exposes sites that keep an origin server to query behind their CDN. A landing page exported as pure static has exactly no origin server left to protect: the CDN serves the HTML files straight from its own cache, never reopening a connection to an application server that could be misconfigured or poorly authenticated. That's not a guarantee of invulnerability, but an entire category of risk disappears along with the server it targeted.

Comparison: static export vs managed hosting (Vercel)

Next.js 16 on a landing page: Turbopack is stable, but Cache Components doesn't work with static export

Turbopack is now stable and on by default, middleware.ts has a new name, and Cache Components promises a more explicit caching model — but that last feature, the most talked-about part of Next.js 16, simply doesn't work with the static export that most serverless landing pages already rely on. What actually matters for a project like a LanderKit template, and how to migrate without breaking anything.

Unlike Cache Components, Turbopack benefits any Next.js project, static export included: it's a compiler, not a server execution strategy, and it does its job before the hosting mode even comes into question. The gain shows up mostly in development time — local server startup and rebuilds after each file change — rather than in load speed for the actual visitor, since an already-static page loads at the same speed regardless of which bundler produced it. That gain isn't trivial, though: Gloria Mark, Daniela Gudith and Ulrich Klocke, in "The Cost of Interrupted Work: More Speed and Stress," published in 2008 in the proceedings of the CHI conference (ACM) (see the study), show that people interrupted mid-task compensate by working faster, but at the cost of measurably higher stress and frustration. A rebuild that drops from several seconds to a few hundred milliseconds cuts down exactly that kind of repeated micro-interruption while you're tweaking a headline or a CTA on a landing page.

Should you migrate a LanderKit template to Next.js 16 now?

1. Check the Node.js version on your host or CI (20.9 minimum) before starting the upgrade.
2. Update next and react to 16.x and 19.2, then run next build once to catch any configuration incompatibility.
3. Don't enable cacheComponents: true if the project keeps output: "export" — the two are incompatible, and the build fails if both options are present at once.
4. Only rename middleware.ts to proxy.ts if the project actually uses one — no LanderKit template needs it by default, since forms and payment already point to external services.
5. Run a full build again (npm run build) and confirm the demos still generate without errors before deploying.

Making a landing page installable (PWA): which pages actually benefit from it

A manifest and a service worker are enough to turn a landing page into an installable home-screen icon — but the install prompt only makes sense on journeys where the visitor comes back more than once: a SaaS waitlist, a webinar signup, a real estate decision. Which pages it's worth it on, how to implement it cleanly in Next.js, and why you should never cache an offer or a price that changes.

Which landing pages installation actually makes sense on

• A SaaS waitlist — the user signs up, then comes back to check their position or wait for launch; a home-screen icon beats an email buried three weeks later in a crowded inbox.
• A webinar signup — between confirmation and the event, the countdown page can be reopened voluntarily several times; paired with a notification, it cuts the no-show rate.
• A long-cycle decision — a property valuation or a mortgage broker quote the visitor compares before deciding, sometimes over several days.

Chrome's native prompt can be intercepted with e.preventDefault() on the beforeinstallprompt event, stored, then triggered later through a button that matches the page's own design — for example on the confirmation screen right after waitlist signup, rather than on arrival. Timing matters: offering installation after real engagement (the visitor has just signed up) rather than on load meaningfully improves acceptance, for the same reason a poorly timed notification permission request tends to get refused outright. On a webinar page, pairing installation with a reminder notification has a documented retention effect: Bell, Garnett and coauthors, in a randomized controlled trial published in 2023 in JMIR mHealth and uHealth (see the study), found that a notification made users 3.5 times more likely to reopen the app within the following hour compared to receiving no notification — an effect measured outside a marketing context, but whose mechanism (a visible reminder triggers a return visit) transfers directly to a webinar reminder.

Server Actions or an API route for a Next.js landing page form?

Since Next.js 13, a form can be handled by a Server Action — a server function called directly, without a separate API route. That simplifies the code, but it also changes how resilient and secure a landing page form ends up being. The concrete comparison, including when a plain API route is still the better call.

One argument comes up often in favor of Server Actions: CSRF protection (cross-site request forgery) is supposedly automatic, while a plain API route would need it coded by hand. That's true of Next.js's implementation, which automatically checks the request's origin before running a Server Action — a genuine simplicity win. But that doesn't make an API route inherently vulnerable: Adam Barth, Collin Jackson and John C. Mitchell, in "Robust Defenses for Cross-Site Request Forgery," published in 2008 in the proceedings of the 15th ACM Conference on Computer and Communications Security (CCS 2008) (see the study), show that reliable CSRF defenses rest on checking the request's origin or referer — exactly the mechanism an API route can implement itself, with a bit more code. The real difference, then, isn't "secure" versus "insecure", it's "protected by default without thinking about it" versus "protected if you take care to implement it". On an unauthenticated lead-capture form, CSRF risk is limited anyway — the real stakes sit more on the side of validating incoming data and blocking spam, as covered in our article on CAPTCHA.

Comparison: Server Action or API route

Sitemap.xml for a landing page: useful or not, and how to generate it with Next.js

"Does a single page need a sitemap.xml?" The question comes up as soon as a site has only a handful of URLs. The answer depends less on the page count than on what a sitemap actually does: a discovery channel, not a ranking lever. What it really changes, and how to generate it cleanly with Next.js.

Does a single landing page need a sitemap?

• A brand-new domain with no backlinks. Without an inbound link signalling its existence, a page can take a while to be discovered. A sitemap submitted through Search Console gives the crawler an explicit list of URLs to visit, mainly shortening that first pass.
• Several pages changing at different rates. A stable main landing page, an excluded thank-you page, a few legal pages, a blog publishing daily: as soon as a site goes past a single page, the sitemap becomes the place to declare a reliable per-URL modification date, more precise than what links alone convey.
• A multilingual version. If the French page has an English equivalent, the sitemap can carry the hreflang relationships between the two versions in addition to, or instead of, the ones set in each page's <head> - see our guide on hreflang tags for a multilingual landing page.

That last point ties into a problem older than the sitemap protocol itself: keeping a local copy of a changing resource fresh. Junghoo Cho and Hector Garcia-Molina, in a study published in 2000 at the ACM SIGMOD conference ("Synchronizing a Database to Improve Freshness"), show, from observing 270 websites over more than four months, that with limited crawling resources, allocating visits based on a reliable estimate of the actual change rate markedly improves overall freshness compared to a naive policy. The lastmod date is exactly that estimation signal - as long as it isn't corrupted: Google has confirmed that a lastmod set to today's date across thousands of URLs that haven't actually changed eventually teaches it to ignore the attribute for the whole domain. A true but rarely updated lastmod beats a systematically refreshed but fake one.

Open Graph image for a landing page: why the share preview changes everything

You paste your landing page link into a LinkedIn message or a WhatsApp group, and nothing shows up — or worse, a broken, generic, unreadable preview. That small 1200×630 pixel rectangle gets seen before the page even loads: here's why it matters, how to diagnose it, and how to fill it in properly.

When a link is pasted into LinkedIn, Facebook, WhatsApp, Slack, or X, the platform doesn't display the raw URL — it looks in the page's <head> for Open Graph tags — og:title, og:description, og:image — standardized by the Open Graph protocol introduced by Facebook in 2010 and now read by nearly every social and messaging platform. X (formerly Twitter) adds its own variant, twitter:card. These tags are separate from the ones Google reads for search ranking: a page can be perfectly well indexed and yet completely silent the moment it's shared, simply because nobody filled in those few lines of metadata.

How to check your own landing page's preview

• Facebook Sharing Debugger (developers.facebook.com/tools/debug) — shows the preview and offers a "Scrape Again" button to force a refresh after a change.
• LinkedIn Post Inspector (linkedin.com/post-inspector) — essential since LinkedIn keeps its own cache, independent from Facebook's.
• Twitter Card Validator, found via a "card validator" search on developer.x.com — specifically checks the twitter:card tag, which needs to be present even when og:image already is.
• A manual test in WhatsApp or Slack, pasting the link into a conversation with yourself — the fastest first check, even if it doesn't say why a preview is broken.

Astro or Next.js for a landing page: which should you choose?

Astro promises zero JavaScript by default through its islands architecture, Next.js bets on the React ecosystem and the ability to grow into a full product. An honest comparison to help you pick the right tech for your landing page.

This is not a cosmetic detail. A landmark study in web performance measurement, Butkiewicz, Madhyastha and Sekar (2011), “Understanding Website Complexity: Measurements, Metrics, and Implications” (IMC 2011), analysed hundreds of real sites and identified the number of loaded objects — scripts, network requests, third-party resources — as the strongest predictor of render time and perceived load time, ahead of total data weight. Less JavaScript to parse and execute doesn't just mean a lighter file: it means fewer requests, less main-thread blocking, and a shorter time to interactive.

Where Astro pulls ahead

• Overwhelmingly static pages: an email-capture landing page, a one-pager, a launch page with no complex logic — Astro ships almost nothing for the browser to run.
• Dense editorial content: a blog post, documentation, a long page mixing a lot of text — Astro's MDX support is particularly comfortable for this case.
• Component freedom: the ability to import a one-off React, Vue or Svelte component as an island, without shipping the whole framework for the rest of the page.
• Guaranteed minimal JavaScript footprint: zero-JS isn't an option to turn on, it's the default behaviour you have to work around to bypass.

Static landing page or React SPA: the technical choice that tanks (or saves) your conversion rate

A React landing page can be a fully client-rendered SPA, or a static page pre-generated at build time. Perceived speed, Core Web Vitals, SEO: the architecture choice changes everything, before the first word even appears on screen.

Back in 1968, psychologist Robert B. Miller laid out, in what is now a classic study of human-computer interaction, three thresholds for perceived response time: under 0.1 second, the reaction feels instantaneous; up to 1 second, the user's train of thought stays uninterrupted; past 10 seconds, their attention drops off — Miller (1968), "Response Time in Man-Computer Conversational Transactions". A SPA showing a blank screen or a spinner while its JavaScript bundle downloads and then executes very often blows past that one-second threshold on a mobile connection — before the first word is even readable.

SSG or ISR: how to handle a price or offer that changes on a Next.js landing page

A statically generated (SSG) landing page is the fastest to serve: the HTML is already built, no server-side computation on every visit. But what happens when the price or offer it displays changes faster than your rebuilds? A concrete comparison of pure SSG, ISR (Incremental Static Regeneration) and client-side computation, including the approach LanderKit uses on its own site.

The instinct "it changes, so it needs dynamic rendering" costs more than it looks. A page rendered on every request (SSR) recomputes the entire HTML server-side on every visit, even when nothing has changed since the last one — a cost in response time and serverless billing that a landing page's LCP has no reason to pay. Lee Breslau, Pei Cao, Li Fan, Graham Phillips and Scott Shenker, in "Web Caching and Zipf-like Distributions: Evidence and Implications," published in 1999 in the proceedings of IEEE INFOCOM, use real web proxy traces to show that requests toward the same content follow a highly uneven distribution: a handful of pages account for most of the traffic, which makes caching already-computed content extremely profitable in terms of hit rate. A sales landing page fits this pattern exactly: the homepage and template pages get visited thousands of times for content that, most of the time, doesn't change from one visit to the next. Paying for a server computation on every request just to regenerate an identical HTML output only makes sense if part of the content actually changes — not as a default habit.

Comparison: pure SSG, ISR, computed static, triggered rebuild

Next.js Partial Prerendering (PPR): making a landing page static and dynamic at once

Nearly every performance recommendation pushes toward a fully static landing page — yet its promo banner, countdown, or localized price still needs to be recalculated on every visit. Next.js's Partial Prerendering serves an instant static shell and streams in those few dynamic blocks on top of it, without reopening the whole page's render to the server.

Nina Bhatti, Anna Bouch, and Allan Kuchinsky, in a study published in 2000 in Computer Networks on perceived tolerance to latency on the Web (see the study), show that this tolerance isn't uniform across a single page: it depends on what the visitor expects from each visual zone at the moment they're looking at it. A visitor who sees the headline, the main image, and the call-to-action button appear instantly generally doesn't notice that a small secondary block — a stock counter, a localized price note — fills in a fraction of a second later. That's exactly what PPR enables: the LCP, almost always measured on the hero headline or image, stays that of a purely static page, since that content is part of the prerendered shell. Only the explicitly dynamic block waits for its data, while the rest of the page is already fully visible and interactive.

Concrete use cases on a landing page

• A price localized or converted into the visitor's currency: server-side IP geolocation determines the currency inside a single Suspense component, without making the rest of the page dynamic — see our article on local currency and displayed price.
• A countdown to a real, server-stored deadline: useful for a webinar signup (demo) whose date genuinely closes, rather than a counter recomputed client-side on every render.
• An A/B test variant decided server-side: a natural complement to the "feature flags at the edge" approach described in our guide to A/B testing a static page — the flag is read inside the dynamic hole, while the rest of the page keeps the benefits of prerendering.
• A remaining seats or stock counter: data that changes more often than the page's own content would justify through a classic ISR revalidation.

The View Transitions API on a Next.js landing page: useful fade or gimmick?

Click a template card and the next page snaps into place with no visual thread connecting the image you just saw to the one that replaces it. The browser's View Transitions API, now controllable from Next.js without a third-party library, lets one visual element persist from one page to the next. Two studies on perceived waiting time and animation help explain where that fade actually helps, and where it's just a gimmick that slows the page down for nothing.

The value isn't purely decorative. A 2025 study in the Journal of Consumer Research by Yu Ding (Baruch College) and Ellie Kyung (Babson College), on animation speed and perceived waiting time, finds an inverted-U relationship between animation speed and how long a wait feels: a moderate-speed animation cuts perceived waiting time more than no animation at all, but also more than one that's too fast or too slow, because it captures attention without overwhelming it. An earlier study, presented in 2010 at the CHI conference by Jarmo Huhtala, Ari-Heikki Sarjanoja, Jani Mäntyjärvi and coauthors (see the study), points to the same conclusion from a different angle: showing a fragment of the next screen earlier in the transition does more to lower perceived waiting time than the animation's total duration does. In other words, it isn't the animation itself that reassures a user during a wait — it's the visual promise that something familiar keeps existing on the other side.

Where this fade actually earns its place on a landing page

• From a grid of templates to a detail page: the clicked thumbnail smoothly grows into the next page's hero image instead of vanishing and reappearing elsewhere — useful on a page presenting several offers side by side, where the paradox of choice already makes comparison mentally costly.
• From the hero to a template's live demo: on the SaaS waitlist template (demo), a visitor who clicks "view demo" keeps the same visual anchor (the product name, the button) while the next page loads, which reduces the feeling of having left the site.
• From the form to the thank-you page: letting the submit button morph into a visual confirmation avoids the brief hesitation where a visitor wonders whether their submission actually went through.
• Between two steps of a multi-step form: the progress bar and the fields already filled in slide rather than jump from one screen to the next, in line with what our article on progress bars already recommends.

The hard part was never hosting — it's having a page that converts. That's precisely what LanderKit templates solve: ten Next.js landing pages ready to deploy, structured for conversion from the first line, at €89 each or €229 for the full pack. The code is yours, Vercel hosting is free, and going live takes a handful of minutes following this guide.