Next.js templates give you server-rendered pages, but they do not rank just because you downloaded one. You still have to replace the demo metadata, size images, add structured data and a sitemap, and choose a host that can run your rendering mode. Work through the nine steps below in order, and a typical small site is ready for search within a few working sessions.
The steps assume you have a template running locally. If you have not picked one, the Marketplace has Next.js versions of designs for different trades, such as Growthin for SaaS sign-ups and Loopix for software companies, at $39 each. Our example throughout is a hypothetical invoicing startup launching a marketing site.
Step 1: Clear out what the demo left behind
Start by searching the project for the demo’s name, its domain and placeholder words. They hide in places you would not check by eye, including JSON data files, the web manifest, default social images and the favicon. Then delete the pages you will not use. A leftover demo blog with sample posts can end up indexed under your domain, and it will compete with your real pages.
Step 2: Find out which router you have
Check for an app folder or a pages folder. The metadata and data-fetching code differ between the two, and advice for one will mislead you on the other. With the App Router, components run on the server unless marked “use client”. If the template has that marker at the top of nearly every file, a lot of JavaScript will go to the browser, and you may want to push it down to the small parts that are truly interactive.
Step 3: Give each page its own metadata
For our invoicing startup, the page about recurring invoices needs a title that says so, not “Home | Growthin”. In the App Router, set defaults and a title pattern in the root layout, then export metadata from each static page. Use generateMetadata for pages that come from data, such as blog posts. In the Pages Router, the same job belongs to next/head.
While you are there, set metadataBase to your real domain. Without it, canonical and social image addresses can resolve incorrectly.
Step 4: Fix images before they slow you down
Replace plain img tags with the Image component where it makes sense. Give each image correct dimensions so that the layout does not jump while loading. Mark only the main image at the top of the page with priority, not all of them. Write alt text that describes the actual picture. A template’s sample photos are often large, so check that the images you are replacing them with are not even larger.
Step 5: Load fonts the Next.js way
Use next/font, which hosts the files with your site and reduces layout shift. Remove any leftover links to font services from the template’s layout. Keep the number of weights low: every extra one adds bytes for little visible gain.
Step 6: Add a sitemap and a robots file
In the App Router, app/sitemap.ts and app/robots.ts generate both from code, so new pages can appear automatically. Check two things that catch people out. Make sure the sitemap holds your production domain, not localhost. And confirm that robots rules from a staging setup did not come along, because a stray Disallow: / will keep your whole site out of search.
Step 7: Add structured data where it is true
Render JSON-LD in a script tag for what the page really is: Organization on the home page, Article on posts, FAQPage where visible questions exist. Our invoicing startup should not mark up star ratings it does not have. Structured data must match the content visitors can see, and made-up values can get a site penalized.
Step 8: Match your rendering to your host
This is where a working local site most often turns into a broken live one. A quick reference:
- Static export (output: “export”) produces files for any static host, but gives up server features such as default image optimization and on-demand rendering.
- Static generation with revalidation keeps pages fast while refreshing them over time. It needs a host that supports it.
- Server rendering runs on each request, so it needs a Node.js server or a platform built for it.
Set environment variables on the host too, and make sure secrets do not carry the NEXT_PUBLIC_ prefix, because anything with that prefix reaches the browser. Then set up redirects from any old addresses in next.config.
Step 9: Check the live site, not your laptop
Run these checks on the production URL:
- View the page source and confirm that your main text is in the HTML.
- Run Lighthouse on a phone profile against the home page and one inner page.
- Open a shared link in a social preview tool to test titles and images.
- Crawl the site for broken links and duplicate titles.
- Submit the sitemap through Google Search Console once you are happy with it.
Where the time goes with Next.js templates
The steps above are easy to list. Most of the delay comes from steps 2 and 8: untangling client components that should run on the server, and getting a host to behave. Writing unique metadata for many pages is the other slow job, simply because it is dull.
That split is why this work suits an AI-plus-expert setup. For a React and Next.js job, AI drafts titles and descriptions, finds the demo leftovers and writes the first version of the sitemap and schema code. A human developer then reviews the server and client boundaries, checks the production build, runs the Lighthouse pass and corrects any metadata that does not match the page. Five pages come to $799 for one week of delivery, while single jobs like “fix our metadata” start from $49. All of this is quoted up front, as shown on the pricing page.
Questions about Next.js sites and search
Do Next.js templates rank better than other kinds of site?
The framework alone will not earn rankings. It makes the technical base easier to get right. Useful content and links remain the larger factors.
Which should I choose: static or server rendering?
Use static generation for pages that are the same for everyone and change rarely. Reach for server rendering when content needs to be current on each request, or differs by visitor.
Can I edit a Next.js template without a developer?
Text in data files is manageable if you are careful, but anything structural needs code skills. If non-technical staff will publish often, connect a headless CMS, so they never have to touch the code.
Does the Regular License cover a site for a client?
Yes, for one end product. If you are building something many users will pay for or be offered, look at the Extended License.
Got a Next.js site that is live but going nowhere in search? Start a Task with the address, and weigh our fixed price and date against doing it yourself.
