Arhitectura pSEO: dataset + template, pas cu pas

Programmatic SEO sună simplu: un template, un dataset, mii de pagini. În practică, distanța dintre „merge pe trei pagini de test" și „Google indexează zece mii de pagini care aduc trafic" e plină de decizii tehnice. Cum legi exact datasetul de template. Când generezi paginile la build și când la cerere. Cum faci fiecare pagină să merite indexată, nu doar să existe. Aici începe implementarea reală — partea pe care fundamentele pSEO o lasă deoparte.

Arhitectura pSEO: cele trei straturi

Orice sistem pSEO are aceleași trei straturi, indiferent de stack:

Sursa de date — un dataset structurat: rânduri cu câmpuri identice (un rând = o pagină viitoare). Poate fi o colecție în baza de date, un fișier sau un spreadsheet.
Template-ul — un singur șablon de pagină cu locuri goale (variabile) care se umplu din câmpurile fiecărui rând.
Output-ul — paginile generate, fiecare la propriul URL, plus rutele și sitemap-ul care le fac ușor de găsit.

Logica e: iei un rând, îl torni în template, obții o pagină. Repeți pentru toate rândurile. Diagrama de mai jos arată fluxul complet, de la dataset până la indexare, cu reperele care țin sistemul onest.

Pipeline pSEO în cinci etape: dataset, template, N pagini SSG/ISR, sitemap dinamic, indexare Google

Schema dataset-ului: ce câmpuri devin variabile

Începe de la date, nu de la template. Schema datasetului decide ce poate fi diferit de la o pagină la alta — deci cât valorează fiecare pagină.

Ia un exemplu concret: un director de integrări („cum conectezi aplicația X cu aplicația Y"), pattern clasic de pSEO. Un rând arată așa:

1{
2  "slug": "stripe-to-slack",
3  "sourceApp": "Stripe",
4  "sourceCategory": "Payments",
5  "targetApp": "Slack",
6  "targetCategory": "Communication",
7  "trigger": "Plată nouă reușită",
8  "action": "Mesaj în canalul #finance",
9  "events": ["payment.succeeded", "invoice.paid"],
10  "setupSteps": 4,
11  "setupMinutes": 6
12}

1{
2  "slug": "stripe-to-slack",
3  "sourceApp": "Stripe",
4  "sourceCategory": "Payments",
5  "targetApp": "Slack",
6  "targetCategory": "Communication",
7  "trigger": "Plată nouă reușită",
8  "action": "Mesaj în canalul #finance",
9  "events": ["payment.succeeded", "invoice.paid"],
10  "setupSteps": 4,
11  "setupMinutes": 6
12}

Fiecare cheie devine o variabilă în template: {sourceApp} și {targetApp} în titlu și în primul H2, {trigger} → {action} în paragraful de deschidere, lista events într-o secțiune de detalii tehnice, setupSteps și setupMinutes într-un box de sumar. Regula de aur: cu cât un rând are mai multe câmpuri cu date reale (nu doar nume schimbate), cu atât pagina rezultată e mai diferențiată. Un dataset cu trei câmpuri produce pagini aproape identice. Unul cu cincisprezece câmpuri specifice produce pagini care chiar diferă.

Generarea paginilor: SSG, ISR sau SSR?

Trei moduri de a transforma rândurile în pagini, cu compromisuri diferite.

SSG (Static Site Generation) — toate paginile se construiesc la build. Cele mai rapide și mai ieftine de servit, livrate de pe CDN. Problema la scară: dacă ai 50.000 de rânduri, build-ul construiește 50.000 de pagini de fiecare dată și durează minute bune.

ISR (Incremental Static Regeneration) — tehnic, nu e un mod separat de randare, ci un strat de caching peste SSG, cum subliniază ghidurile Next.js: generezi pagina la prima cerere, o cache-uiești, și o regenerezi periodic (time-based) sau la nevoie (revalidateTag / revalidatePath). Pentru pSEO la scară, ăsta e răspunsul implicit: nu construiești zeci de mii de pagini la build, le generezi pe măsură ce sunt cerute.

SSR (Server-Side Rendering) — randezi la fiecare cerere. Justificat doar pentru conținut cu adevărat dinamic sau personalizat (prețuri live, pagini per utilizator). Pentru pagini de conținut pSEO e contraproductiv: TTFB mai mare, cost de server mai mare, fără beneficiu real.

Decizia, pe scurt: set mic și stabil → SSG; set mare sau date care se schimbă periodic → ISR; conținut per-request → SSR (rar). În App Router, scheletul arată așa:

1// app/integrari/[slug]/page.tsx
2export async function generateStaticParams() {
3  const rows = await getIntegrations(); // from your dataset / DB
4  return rows.map((r) => ({ slug: r.slug }));
5}
6
7export const revalidate = 86400; // ISR: regenerate daily, no full rebuild

1// app/integrari/[slug]/page.tsx
2export async function generateStaticParams() {
3  const rows = await getIntegrations(); // from your dataset / DB
4  return rows.map((r) => ({ slug: r.slug }));
5}
6
7export const revalidate = 86400; // ISR: regenerate daily, no full rebuild

Unicitate per pagină, altfel cazi în doorway

Aici se rupe majoritatea proiectelor pSEO. Dacă singura diferență dintre două pagini e variabila înlocuită — un oraș, un nume de produs — ai construit pagini doorway: șabloane goale, multiplicate ca să prindă keyword-uri.

Și Google a tras linia explicit. Politica de scaled content abuse, introdusă în martie 2024, vizează generarea multor pagini cu scopul principal de a manipula ranking-ul, fără valoare pentru utilizator — indiferent dacă sunt scrise de om, de AI sau hibrid. Exemplul tipic dat de analize: pagini „Cel mai bun [produs] în [oraș]" generate pentru sute de produse × sute de orașe, sute de mii de pagini aproape identice, cu valoare neglijabilă per pagină. Astfel de pattern-uri programatice au fost cele mai lovite.

Diferența reală față de SEO clasic nu e că automatizezi, ci că fiecare pagină trebuie să-și câștige existența. Testul practic: dacă ștergi numele variabilei, mai rămâne conținut util pe pagină? Dacă da, e o pagină. Dacă nu, e un doorway. Soluția stă în dataset, nu în template: date proprii per rând (exemple concrete, numere reale, sub-câmpuri specifice) care schimbă substanțial conținutul. Altfel paginile sunt crawl-ate și apoi lăsate neindexate — Google crawl-ează aproape tot pe site-urile de valoare, dar indexează doar o fracțiune din paginile auto-generate subțiri, oricât de „unice" tehnic ar fi.

Sitemap dinamic, internal linking și crawl budget

Paginile generate trebuie și găsite. Trei mecanisme, în ordine.

Sitemap dinamic. Generează-l din dataset, nu manual. În Next.js, sitemap.ts plus funcția generateSitemaps împarte automat la 50.000 de URL-uri per sitemap (limita Google) și servește un sitemap index:

1// app/sitemap.ts — Next.js splits automatically at 50,000 URLs per sitemap
2export async function generateSitemaps() {
3  const total = await countPages();
4  return Array.from({ length: Math.ceil(total / 50000) }, (_, id) => ({ id }));
5}

1// app/sitemap.ts — Next.js splits automatically at 50,000 URLs per sitemap
2export async function generateSitemaps() {
3  const total = await countPages();
4  return Array.from({ length: Math.ceil(total / 50000) }, (_, id) => ({ id }));
5}

Pune în sitemap doar URL-uri canonice și indexabile — duplicatele irosesc crawl budget. Google ignoră <priority> și <changefreq>; ce contează e <lastmod>, dacă e ținut sincron cu modificările reale.

Internal linking la scară. Sitemap-ul ajută descoperirea, dar nu e suficient. Fiecare pagină generată trebuie să fie accesibilă prin linkuri interne, nu doar listată în sitemap. O pagină fără niciun link intern către ea e o orphan page: Google o descoperă din sitemap, dar nu-i poate înțelege importanța în ierarhie și irosește crawl budget pe ea. Leagă paginile între ele (hub-uri de categorie → pagini de detaliu, pagini înrudite între ele), ține-le aproape de homepage (paginile la 3+ click-uri distanță sunt crawl-ate mai rar) și asigură-te că versiunea mobilă are aceleași linkuri ca desktop — Google indexează versiunea mobilă, iar linkurile lipsă acolo încetinesc descoperirea.

Crawl budget, realist. Pentru majoritatea site-urilor nu e o problemă. Google însuși spune că, sub ~10.000 de pagini și cu pagini noi crawl-ate în aceeași zi, e suficient să ții sitemap-ul la zi și să verifici raportul de indexare. Crawl budget devine important la site-uri mari sau care se schimbă des. Atunci nu-l irosi: blochează în robots.txt ce nu vrei crawl-at, întoarce 404/410 pentru pagini șterse definitiv (nu noindex, care tot consumă crawl) și elimină URL-urile cu parametri care produc duplicate.

Date structurate aplicate la build

Aceeași sursă de date alimentează și schema. Generezi date structurate la build, din dataset:

Pe paginile de listă / hub: ItemList, cu elementele care duc la paginile de detaliu.
Pe paginile de detaliu: tipul specific care se potrivește conținutului (de exemplu HowTo pentru un ghid de integrare, SoftwareApplication, sau FAQPage pentru secțiunea de întrebări).

Anatomia paginii de listing și datasetul care o alimentează e detaliată în ghidul despre marketplace-uri și directoare — acolo vezi ce tipuri de schema se potrivesc fiecărei pagini. Un singur lucru de reținut la implementare: JSON-LD-ul se injectează în <head>-ul paginii (sau printr-o componentă dedicată), nu în corpul de conținut — altfel rupi randarea.

Întrebări frecvente

Pot construi stratul ăsta fără cod, cu un tool no-code?

Da. Airtable sau Google Sheets ca dataset, plus Webflow/Framer sincronizate prin Whalesync (sau similar), generează pagini din rânduri. Pe scurt și neutru: no-code = rapid de pornit, dar limitat la volume foarte mari și la control fin pe rendering, sitemap și date structurate; cod (Next.js și altele) = mai mult efort inițial, dar control total pe SSG/ISR, sitemap dinamic și schema. Alegi după volum și după cât control îți trebuie.

Câte pagini pot genera „în siguranță"?

Nu numărul e problema, ci valoarea per pagină. Google penalizează volumul fără valoare, nu volumul în sine. Zece pagini cu date reale bat o mie de pagini subțiri.

SSG sau ISR pentru un dataset mare?

ISR, în general: eviți build-uri uriașe, generezi pagina la prima cerere și o cache-uiești. SSG rămâne bun pentru seturi mici și stabile.

Cum știu dacă paginile mele sunt doorway?

Testul: dacă diferența dintre două pagini e doar variabila înlocuită, sunt doorway. Dacă fiecare are date proprii care schimbă substanțial conținutul, nu.

De ce nu se indexează paginile, deși sunt în sitemap?

Sitemap-ul ajută descoperirea, nu garantează indexarea. Paginile subțiri sunt crawl-ate și lăsate neindexate. Adaugă orphan pages și crawl budget irosit pe URL-uri inutile și ai explicația completă.

Mai departe

Stratul template + dataset e jumătate din ecuație. Cealaltă jumătate e cât te costă să-l construiești și să-l întreții — build custom vs no-code vs agenție, cu prag de rentabilitate. Despre asta, în analiza de cost pSEO. Pentru harta completă, pornește de la serviciul pSEO sau explorează arhitectura pSEO.

Arhitectura pSEO: cum legi un dataset de un template