Technical SEO in 2026: the checklist I run on every site

Good content a search engine cannot read is invisible content. Technical SEO is the part of the job that guarantees three things: the crawler finds the page, can render it and understands what it is about. Below is the checklist I follow on every site I ship, including this portfolio.

1. Crawling: clear the path

The first filter is robots.txt. It is not meant to hide pages from the index (that is what noindex is for), but to tell crawlers where not to waste time.

User-agent: *
Allow: /

Sitemap: https://dominio.com.br/sitemap.xml

What I check:

• No accidental Disallow on CSS, JS or images. Google renders the page and needs those files.
• Sitemap generated at build time, never written by hand. Every modern framework has a plugin or integration for it.
• Internal links as real <a href> elements. Navigation that only uses onClick is not followed.

2. Indexing: one URL, one version

The most common issue I find in audits is duplicate content from URL variations: with and without a trailing slash, www and bare domain, http and https, tracking parameters. To a search engine each one is a different page competing for the same spot.

The fix has two parts:

1. 301 redirects to the canonical form on the server.
2. <link rel="canonical"> on every page, pointing to the preferred absolute URL.

On bilingual sites, add hreflang: every page declares itself and its translation, plus an x-default.

<link rel="canonical" href="https://dominio.com.br/en/blog/seo-tecnico-checklist/" />
<link rel="alternate" hreflang="en" href="https://dominio.com.br/en/blog/seo-tecnico-checklist/" />
<link rel="alternate" hreflang="pt-BR" href="https://dominio.com.br/pt/blog/seo-tecnico-checklist/" />
<link rel="alternate" hreflang="x-default" href="https://dominio.com.br/pt/blog/seo-tecnico-checklist/" />

3. Rendering: ready HTML beats JavaScript

Google can execute JavaScript, but it does so in a second stage, with a queue and a budget. Other crawlers, including most AI crawlers, do not even try. So the rule is simple: the main content must be in the HTML the server sends.

Strategy	What the crawler receives	When to use it
SSG (static)	Full HTML, generated at build time	Blogs, portfolios, landing pages
SSR	Full HTML, generated per request	Content that changes constantly
SPA (client only)	An empty <div> and a JS bundle	Dashboards behind a login

For content sites, SSG is almost always the best choice: even data coming from a database can be read at build time and ship pre-rendered.

4. Core Web Vitals: the three metrics that count

Google uses Core Web Vitals as a page experience signal. The “good” thresholds, measured at the 75th percentile of real users:

Metric	What it measures	Good
LCP	Time until the largest visible element renders	≤ 2.5 s
INP	Delay between an interaction and the visual response	≤ 200 ms
CLS	How much the layout shifts while loading	≤ 0.1

INP replaced the old FID in March 2024 and is the one that hurts JavaScript-heavy sites the most. What fixes things in practice:

• LCP: hero image with fetchpriority="high" and preload, in WebP or AVIF, and fonts with display=swap.
• INP: less client-side JavaScript. Load scripts only for components that truly need interaction; everything else should be plain HTML.
• CLS: width and height on every image and reserved space for anything that loads later.

5. Metadata: title, description and Open Graph

The title is still one of the strongest on-page signals and is the clickable text in results. My pattern: main subject first, brand last, around 60 characters. The meta description does not rank, but it becomes the snippet and influences clicks, so I write it as an honest 140–160 character ad.

Open Graph (og:title, og:description, a 1200×630 og:image) defines how the link looks on WhatsApp, LinkedIn and other networks. Each article on this blog has its own image, made in the same visual style as the site.

6. Structured data: spell it out

JSON-LD is a data block in the <head> that describes the page in a vocabulary machines understand (schema.org). On this blog, every article publishes three:

• BlogPosting with title, author, published and modified dates, image and language;
• BreadcrumbList with the Home → Blog → article trail;
• FAQPage with the questions at the end of the text.

An honest caveat: since 2023 Google shows FAQ rich results only for some government and health sites. It is still worth keeping, because the markup makes the question → answer structure explicit, which helps any system reading the page, AI included. That is the topic of the next article, on GEO.

7. Accessibility is SEO

Correct heading hierarchy (one h1, then h2 and h3 in order), descriptive alt text, link text that makes sense out of context and the right lang on <html>. All of this helps screen readers and crawlers for the same reason: it makes the document structure explicit.

The checklist on one screen

• robots.txt without accidental blocks and with the sitemap declared
• Sitemap generated at build time
• 301 redirects to the canonical URL and rel="canonical" on every page
• Reciprocal hreflang and x-default on multilingual sites
• Main content in server HTML (SSG or SSR)
• LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1
• Unique title and description per page
• Open Graph with a 1200×630 image
• JSON-LD for the person or organization and the page type
• One h1 per page, alt on images, correct lang

If you want a site that ships with all of this solved from day one, that is exactly the kind of project I build.