Checklist-ul SEO pentru Next.js pe care îl folosim efectiv

Next.js este bun pentru SEO și este folosit în mod curent prost pentru asta. Acesta este checklist-ul pe care îl parcurgem înainte de lansare, în ordinea în care îl parcurgem.

Randare: conține HTML-ul conținutul?

Primul test nu costă nimic: ia pagina cu curl și citește răspunsul. Dacă textul principal nu este în HTML, nicio muncă de metadate nu va ajuta. În App Router, componentele de server randează implicit — problema este aproape întotdeauna o graniță use client pusă prea sus sau date luate într-un efect, în loc de pe server.

Decide strategia de caching pe rută, nu global. Paginile de prezentare se potrivesc cu generarea statică și revalidare. Orice este cu adevărat per utilizator ar trebui să fie dinamic și, oricum, de regulă nu vrei să fie indexat.

Metadate: unice, generate și corecte pe fiecare limbă

Fiecare rută indexabilă are nevoie de titlu și descriere proprii, luate din conținut, nu dintr-un șablon cu numele site-ului repetat. Folosește generateMetadata, ca să urmeze datele. Titluri sub aproximativ șaizeci de caractere, descrieri sub aproximativ o sută șaizeci, ambele scrise pentru un om care decide dacă dă clic.

Setează metadataBase o singură dată, ca URL-urile Open Graph relative să se rezolve absolut — este cea mai frecventă cauză a preview-urilor stricate pe rețelele sociale.

Canonical: o singură adresă per pagină

Canonical auto-referențial pe fiecare pagină, absolut, identic cu URL-ul pe care chiar vrei să-l indexezi. Fii atent la slash-ul final, la căile cu majuscule și la parametrii de urmărire — alege o formă, redirecționează restul și asigură-te că elementul canonical este de acord cu ținta redirectării, nu în conflict cu ea.

hreflang: partea pe care o greșesc cele mai multe site-uri

Pentru un site multilingv, fiecare pagină are nevoie de legături alternative către fiecare versiune de limbă și către ea însăși, plus x-default. Trebuie să fie reciproce: dacă pagina în engleză arată către cea în română, pagina în română trebuie să arate înapoi. Reciprocitatea ruptă înseamnă că Google ignoră tot grupul.

Este mult mai ușor când CMS-ul stochează limbile ca un singur document, pentru că atunci URL-ul alternativ este o proprietate a conținutului, nu ceva ce întreține un dezvoltator manual. Exact așa își rezolvă pagina pe care o citești corespondentul în engleză.

Date structurate: descrie ce este pagina

Organization și WebSite pe prima pagină, BreadcrumbList pe orice pagină imbricată, Service sau Product pe șabloanele relevante, Article pe articole și FAQPage acolo unde există efectiv o secțiune de întrebări și răspunsuri în pagină. Validează-le — JSON-LD invalid este ignorat tăcut, ceea ce arată identic cu lipsa lui.

Sitemap-uri și robots

Generează sitemap.xml din aceeași sursă de date ca rutele, ca să nu poată devia. Include alternativele de limbă. Exclude tot ce este noindex. Ține robots.txt onest — blocarea unei căi în robots nu o scoate din index, doar împiedică Google să citească noindex-ul pe care l-ai pus acolo.

Core Web Vitals

Folosește next/image cu dimensiuni explicite, ca să elimini deplasarea layout-ului. Folosește next/font, ca fonturile să fie self-hosted și preîncărcate, nu aduse de la un terț. Pune priority doar pe imaginea din hero. Auditează sincer bundle-ul de JavaScript — un tag de analytics, un widget de chat și un banner de consimțământ pot depăși cu ușurință toată aplicația.

Apoi măsoară pe date de teren din Search Console, nu pe un Lighthouse rulat local, pe un laptop rapid. Cifrele de laborator sunt pentru depanare; cele de teren sunt cele care se clasează.

Înainte de lansare

Parcurge site-ul de staging cu un crawler real și compară lista lui de URL-uri cu sitemap-ul tău. Verifică dacă paginile 404 returnează 404 și nu 200 cu un mesaj prietenos. Confirmă că redirectările sunt dintr-un singur pas. Iar dacă migrezi, mapează fiecare URL vechi către unul nou înainte de comutare, nu după ce scade traficul.