Technical SEO is the part of search optimisation that has nothing to do with what you write and everything to do with whether a search engine can fetch, render, understand and index it. On a site built with Next.js, Nuxt, Remix or any other JavaScript framework, most of the decisions that matter are made in the codebase before a single article is published. This checklist is for business owners and marketing managers who need to know what to ask for, and for the developers who will be asked.
Does Google actually see the content?
The first question on any JavaScript site is whether the HTML that leaves the server already contains the content, or whether it contains an empty shell that fills in once the browser runs a bundle. Search engines can execute JavaScript, but they do it later, in a separate queue, with a budget. Anything that depends on that second pass is indexed later, less reliably, and sometimes not at all.
The fix is architectural rather than clever: render the pages that need to rank on the server or at build time. What breaks it is fetching the main content on the client, gating it behind a consent banner or a geolocation check, or hiding it inside tabs and accordions that only mount on interaction.
- View the raw response for a page and confirm the headline, body text and internal links are present without JavaScript.
- Check that error pages return a real 404 status rather than a 200 with a "not found" message rendered by the framework.
Which URL is the real one?
Every page should have exactly one address, and the site should say so. Duplicates creep in through trailing slashes, uppercase paths, query parameters added by campaigns, a www and a bare domain both answering, and staging environments that were never blocked.
- Set a self-referencing canonical tag on every indexable page, generated from the route rather than typed by hand.
- Pick one protocol, one host and one trailing-slash rule, and redirect everything else to it with a permanent redirect.
- Block staging and preview deployments from indexing entirely; a password is better than a robots rule.
How do you tell Google a page has an Arabic twin?
For a bilingual site this is the section most often done wrong. Hreflang tags tell search engines that the English page at one path and the Arabic page at another are the same content in different languages, so the right one is shown to the right searcher and neither is treated as a duplicate of the other.
The rules are simple and unforgiving. Every page in the pair links to itself and to its partner. The Arabic page must exist and return the same status; if a page is only available in one language, do not point hreflang at a page that does not exist. Add an x-default that points to whichever version you want a searcher of unknown language to land on. And keep the language in the path, such as a language prefix, rather than in a cookie or a query string, because a crawler does not carry cookies.
We build English and Arabic from the first screen on every project, and the practical lesson is that hreflang has to be generated by the same code that generates the routes.
What belongs in the sitemap and what does not?
A sitemap is a list of the pages you want indexed, not a list of every URL the site can produce. Filtered views, paginated archives, tag pages with two entries and internal search results all waste crawl budget, which on a large site means the pages you care about are visited less often.
- Generate the sitemap from the database at request time, or on every deploy, so it never lags behind the content.
- Include only canonical, indexable pages that return a successful status, with an accurate last-modified date.
- Use robots rules and noindex tags for the rest, and make sure the two do not contradict each other: a page that is blocked in robots cannot have its noindex read.
What else gets checked before launch?
Three more items belong on the list, and each is easy to forget once the site is live and everyone has moved on.
Core Web Vitals. Largest Contentful Paint, Cumulative Layout Shift and Interaction to Next Paint are measured from real visitors, on the pages that actually receive traffic. Check the heaviest template, not the homepage.
Structured data. Mark up the things that have a schema: the organisation, articles, services, breadcrumbs and any frequently asked questions. It does not raise rankings by itself, but it lets search results show more than a blue link, and it is the format assistants read when they answer a question about you.
Redirects. If the launch replaces an older site, map every old URL that has traffic or backlinks to its closest new equivalent before the switch, not after.
Almost all of this is decided by the people who build the site rather than the people who write for it. Put it in the scope from the discovery workshop onwards, and it costs a few days. Retrofit it afterwards, and it costs a rebuild.