Next.js does not make a website rank.

It gives us good tools for rendering, metadata, images, routes, robots rules, and sitemaps. We can still use every one of those tools badly.

I treat technical SEO as a consistency problem:

Can a crawler fetch the page, understand the same meaning a person sees, identify the preferred URL, and connect it to the rest of the site?

That question is more useful than any “SEO score.”

Start with eligibility, not keywords

Before rewriting a title, I trace five things:

1. Is the URL public and returning the intended page?
2. Can crawlers fetch the meaningful content and required assets?
3. Is the page indexable?
4. Does its canonical point to the URL we actually want?
5. Can another internal page reach it through a normal link?

A perfect description cannot rescue a page that is blocked, orphaned, or canonicalized somewhere else.

Make the first response useful

Google can render JavaScript. That is not a reason to make every crawler wait for a client-side API request.

For public pages, I prefer meaningful headings, copy, links, and primary data in the initial server-rendered output. Client JavaScript should enhance the task, not reveal the task.

This also helps users on slower devices and gives non-Google crawlers a simpler document to process.

Keep metadata specific and truthful

Next.js supports static metadata and dynamic generateMetadata.

The implementation is easy:

import type { Metadata } from "next";

export const metadata: Metadata = {
  title: "Technical SEO Audit for a Next.js SaaS",
  description:
    "A code-grounded checklist for crawlability, canonicals, schema, and performance.",
  alternates: {
    canonical: "/technical-seo-audit",
  },
};

The writing decision is harder.

The title should match the page’s actual task. The description should help a searcher decide whether the page is useful. Neither should be a bag of repeated keywords.

I also avoid duplicating the brand in both a page title and the layout title template. One clean brand suffix is enough.

Structured data must match the page

JSON-LD can clarify that a page is an article, profile, organization, or another supported type. It does not turn ordinary content into authority.

For a blog post, I keep the visible and machine-readable fields aligned:

• headline;
• author;
• publication and real revision dates;
• image;
• language;
• article section;
• canonical URL.

I also serialize safely:

const jsonLd = {
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  headline: post.title,
  author: {
    "@type": "Person",
    name: "Al Mojakkar Hossain Tawfik",
    url: "https://www.mhtawfik.com/",
  },
};

<script
  type="application/ld+json"
  dangerouslySetInnerHTML={{
    __html: JSON.stringify(jsonLd).replace(/</g, "\\u003c"),
  }}
/>;

Google recommends JSON-LD when it fits the site, but valid markup does not guarantee a rich result. The Article structured data guide is the source I check before changing article markup.

International pages need one coherent cluster

For English and Bangla versions, these signals must agree:

• each page has its own self-referencing canonical;
• each page references both language versions with reciprocal hreflang;
• internal language links reach the real counterpart;
• the sitemap lists the same pairing;
• the main content is genuinely localized.

I do not create English and Bangla pages just to multiply URLs. Each version must be useful to its reader.

AI search does not need magic tags

Google’s current guidance says its generative AI search features rely on normal Search foundations. There is no special AI schema, ideal word count, or required machine-readable file.

That changes the content strategy in a good way.

Write something a real person would keep:

• a first-hand decision;
• a concrete process;
• a failure mode;
• a useful comparison;
• a checklist grounded in actual work.

An optional llms.txt directory may help tools that choose to read it. It is not a replacement for crawlability, visible content, or trusted external references.

Read Google’s AI search optimization guide before accepting a “GEO hack.”

Measure what the repository cannot prove

Static code can prove that metadata objects, sitemap entries, and structured data are internally consistent.

It cannot prove:

• that Google indexed the URL;
• which canonical Google selected;
• field Core Web Vitals;
• rankings;
• rich-result appearance;
• ChatGPT or another system citing the page;
• qualified leads.

Those require Search Console, Bing Webmaster Tools, analytics, server logs, and real inquiries.

My release checklist

Before publishing, I want:

• one indexable canonical URL per page;
• useful server-rendered content;
• a specific title and description;
• reciprocal language alternates where a translation exists;
• schema that matches visible facts;
• descriptive internal links;
• real publication and modification dates;
• no claims the evidence cannot support;
• monitoring after release.

Next.js makes the implementation maintainable.

The reputation still comes from useful work, accurate writing, independent references, and time.

For the full launch sequence, read my technical SEO checklist for a business website. If you want the same system applied to a real product, tell me what is currently indexed and what is not.