SEO tehnic pentru site-uri noi: ce trebuie verificat inainte si dupa lansare

Lansarea unui site nou sau a unui redesign este unul dintre momentele in care problemele SEO tehnice pot fi prevenite mult mai usor decat reparate ulterior. Un noindex ramas din mediul de test, o regula gresita in robots.txt, un redirect omis sau un canonical care indica spre staging pot afecta descoperirea si indexarea exact in perioada in care noul site incepe sa fie accesat de crawlere.

Pentru un redesign, miza este si mai mare: noua versiune trebuie sa pastreze relatia dintre URL-urile vechi si continutul nou. Nu este suficient ca noul site sa functioneze vizual. Trebuie verificat cum raspunde serverul, ce poate accesa Googlebot, ce URL-uri sunt declarate canonice, ce pagini apar in sitemap si cum sunt tratate adresele care nu mai exista.

SEO tehnic incepe inainte ca site-ul sa devina public

O verificare facuta dupa lansare poate descoperi problema, dar nu mai poate preveni perioada in care site-ul a fost publicat gresit. De aceea, auditul de pre-lansare ar trebui facut pe versiunea cat mai apropiata de productie, cu aceleasi template-uri, reguli de routing, canonical-uri si structura de URL.

Separati clar doua situatii:

• Site complet nou: accentul este pe descoperire, accesibilitate pentru crawlere, sitemap, linkuri interne, continut si indexabilitate.
• Redesign sau migrare: pe langa toate cele de mai sus, trebuie protejata relatia dintre URL-urile deja cunoscute de Google si noile destinatii.

In practica, redesignul necesita aproape intotdeauna un inventar al URL-urilor existente inainte de schimbare. Altfel, redirectarile ajung sa fie construite reactiv dupa ce apar 404-uri.

1. Poate Google sa ajunga efectiv la paginile importante?

Google descopera pagini prin linkuri, sitemap-uri si alte semnale. Pentru ca o pagina sa poata fi procesata normal, crawlerul trebuie mai intai sa o poata accesa.

Inainte de lansare, verifica daca paginile importante:

• sunt accesibile fara autentificare;
• nu necesita cookie-uri sau actiuni speciale pentru a afisa continutul principal;
• nu sunt blocate accidental in robots.txt;
• nu contin noindex daca trebuie sa fie indexabile;
• returneaza un raspuns HTTP potrivit;
• sunt accesibile prin linkuri HTML crawlable din structura site-ului.

Google recomanda folosirea linkurilor pe care crawlerul le poate interpreta normal si a HTML-ului semantic. Pentru site-urile construite puternic in JavaScript, este important sa verifici si continutul randat, nu doar ceea ce vezi in browser.

Staging-ul nu trebuie confundat cu productia

Este normal ca un mediu de test sa fie protejat prin autentificare sau noindex. Problema apare cand acele reguli sunt copiate in productie.

Un scenariu clasic este:

1. site-ul de staging are noindex;
2. template-ul este mutat pe domeniul public;
3. meta robots ramane neschimbat;
4. site-ul functioneaza perfect pentru vizitatori, dar paginile nu trebuie indexate conform directivei publicate.

De aceea, indexabilitatea trebuie verificata din nou pe domeniul final dupa lansare.

2. robots.txt controleaza crawlingul, nu trebuie folosit ca substitut pentru noindex

Google explica explicit ca robots.txt este destinat controlului crawlingului. O regula Disallow spune crawlerului sa nu solicite anumite resurse sau URL-uri, dar nu este metoda recomandata pentru a garanta eliminarea unei pagini din index.

Daca o pagina nu trebuie indexata, Google recomanda folosirea unei directive noindex sau restrictionarea accesului atunci cand continutul trebuie sa fie privat.

Verificari practice pentru robots.txt

• fisierul este accesibil la /robots.txt;
• nu exista un Disallow: / ramas din staging;
• nu sunt blocate accidental directoare care contin pagini importante;
• resurse esentiale pentru randarea paginii nu sunt blocate inutil;
• URL-ul sitemap-ului este corect daca este declarat in robots.txt.

Nu bloca prin robots.txt o pagina pe care Google trebuie sa o acceseze pentru a vedea un noindex. Directivele de crawling si cele de indexare trebuie gandite impreuna.

3. Canonical-ul trebuie sa indice versiunea pe care chiar vrei sa o consolidezi

Google foloseste mai multe semnale pentru canonicalizare, inclusiv redirectari, rel="canonical" si includerea URL-urilor in sitemap. Daca mai multe URL-uri contin acelasi continut sau continut foarte apropiat, Google poate grupa aceste versiuni si poate selecta una drept canonical.

La lansare, fiecare template important trebuie verificat individual. Nu presupune ca daca homepage-ul are canonical corect, toate paginile il au.

Erori de canonical care apar frecvent la lansare

• canonical catre domeniul de staging;
• toate paginile au canonical catre homepage;
• HTTP este declarat canonical in timp ce site-ul functioneaza pe HTTPS;
• versiunile cu si fara slash sunt tratate inconsistent;
• parametrii produc duplicate fara o strategie clara;
• paginile noi indica accidental spre URL-uri vechi;
• redirectul duce la o pagina, dar canonical-ul paginii tinta indica alta destinatie.

Pentru paginile unice, un canonical self-referencing coerent este o practica utila. In cazul duplicatelor intentionate, trebuie aleasa versiunea preferata in functie de arhitectura reala a site-ului.

4. Redirectarile trebuie proiectate inainte de schimbarea URL-urilor

Daca un URL vechi se transforma intr-un URL nou echivalent, redirectarea permanenta este instrumentul potrivit pentru a transmite utilizatorilor si motoarelor de cautare noua locatie. Google recomanda redirectarile permanente server-side, precum 301 sau 308, atunci cand mutarea este permanenta.

Un redesign este momentul in care se pierd frecvent URL-uri valoroase pentru simplul motiv ca echipa a modificat structura fara un mapping complet.

Exemplu simplu de redirectare corecta

Daca vechiul URL era:

/servicii/dezvoltare-web.php

iar noua pagina echivalenta este:

/servicii/dezvoltare-website-custom/

vechiul URL ar trebui directionat permanent spre noua pagina relevanta, nu spre homepage doar pentru ca vechea cale nu mai exista.

Nu transforma homepage-ul intr-o destinatie universala pentru paginile disparute

Daca o pagina a fost eliminata si nu exista un inlocuitor relevant, un raspuns 404 sau 410 poate fi mai corect decat o redirectionare fara legatura. Google recomanda redirectarea catre o noua locatie atunci cand pagina s-a mutat sau exista un inlocuitor clar.

Pentru proiectele de redesign, un audit SEO tehnic inainte si dupa lansare poate verifica mapping-ul URL-urilor, canonical-urile, indexabilitatea si erorile aparute dupa migrare.

5. Codurile HTTP trebuie sa descrie corect ce s-a intamplat cu URL-ul

Codul HTTP este unul dintre cele mai clare semnale tehnice pe care serverul le transmite unui crawler.

Google foloseste codurile HTTP pentru a intelege daca o pagina poate fi procesata, daca s-a mutat sau daca nu mai exista. Un URL care afiseaza vizual „pagina nu a fost gasita”, dar returneaza 200, poate fi interpretat drept soft 404.

Atentie la paginile 404 care returneaza 200

Un template personalizat de eroare este util pentru utilizatori, dar serverul trebuie sa returneze si codul HTTP corespunzator. Google recomanda 404 pentru paginile care nu exista si avertizeaza asupra raspunsurilor 200 care afiseaza de fapt o eroare.

6. Sitemap-ul trebuie sa contina URL-urile canonice pe care vrei sa le descopere Google

Un sitemap XML ajuta motoarele de cautare sa descopere URL-urile importante si poate transmite informatii precum data ultimei modificari. Pentru un site nou, este una dintre metodele directe prin care poti indica structura paginilor importante.

La lansare, verifica:

• sitemap-ul este accesibil public;
• contine doar URL-uri din domeniul final;
• foloseste HTTPS daca aceasta este versiunea publica;
• nu include pagini cu noindex;
• nu include URL-uri care redirecteaza;
• nu include pagini 404;
• include paginile canonice importante;
• lastmod, daca este folosit, reflecta modificari reale si este mentinut corect.

Google recomanda sitemap-ul pentru notificarea si descoperirea URL-urilor noi sau modificate, in special atunci cand exista multe pagini.

7. Metadata trebuie sa fie verificata pe template, nu doar pe cateva pagini

Un site poate avea design nou si continut corect, dar sa publice acelasi <title> pe sute de pagini din cauza unei erori de template.

Google recomanda ca fiecare pagina sa aiba un title descriptiv si concis. Pentru meta description, Google poate folosi continutul acesteia in snippet atunci cand considera ca descrie bine pagina, dar snippet-ul este generat automat in functie de contextul cautarii.

Ce verifici la nivel de metadata

• fiecare tip de pagina genereaza un <title> relevant;
• nu exista titluri goale precum „Home” sau „Pagina”;
• H1-ul si title-ul descriu aceeasi tema fara sa fie obligatoriu identice;
• meta description nu este duplicata mecanic pe toate paginile;
• titlurile si descrierile sunt generate din date reale, nu din campuri goale;
• Open Graph si imaginile sociale folosesc URL-uri valide daca sunt implementate.

La un site cu CMS custom, testarea trebuie facuta pe toate tipurile de continut: pagina statica, serviciu, articol, categorie, produs, portofoliu sau orice alt template public.

8. Datele structurate trebuie sa descrie ceea ce exista pe pagina

Datele structurate pot ajuta Google sa inteleaga explicit anumite entitati si tipuri de continut. Implementarea trebuie sa respecte documentatia tipului respectiv si sa reflecte informatia disponibila utilizatorilor pe pagina.

Nu adauga markup doar pentru ca exista un tip schema.org. Foloseste structured data care are sens pentru continutul real si, cand urmaresti functionalitati Google Search, verifica documentatia tipurilor suportate de Google.

Validarea practica

• testeaza cateva URL-uri reprezentative cu Rich Results Test pentru tipurile suportate;
• verifica erorile critice si avertismentele relevante;
• asigura-te ca valorile din markup exista si in pagina;
• verifica daca URL-urile, imaginile si identificatorii sunt de productie, nu staging;
• testeaza fiecare template care genereaza date structurate.

Pentru magazine online, implementarea Product, Offer, pretului, disponibilitatii si variantelor necesita verificari suplimentare. Ghidul despre date structurate Product, Offer si Merchant Listings detaliaza aceasta situatie.

9. In ziua lansarii, refa testele pe domeniul final

O verificare buna pe staging nu inlocuieste testul din productie. Schimbarea DNS-ului, configuratia serverului, regulile .htaccess, variabilele de mediu sau cache-ul pot modifica rezultatul.

Imediat dupa publicare, verifica manual cateva tipuri de URL:

• homepage;
• o pagina de serviciu;
• un articol;
• o pagina dintr-o categorie;
• un URL vechi care trebuie redirectat;
• un URL care nu exista si trebuie sa returneze 404;
• /robots.txt;
• sitemap-ul XML.

Nu verifica doar browserul

Browserul poate face un redirect sa para instantaneu si poate ascunde uneori complexitatea unui lant de redirectari. Verifica raspunsurile HTTP si lanturile efective. Un URL care face 301 → 302 → 301 → 200 poate fi simplificat daca destinatia finala este cunoscuta.

10. Search Console devine instrumentul principal de verificare dupa publicare

Dupa lansare, datele din Search Console iti permit sa vezi cum percepe Google site-ul real, nu mediul testat intern.

Verifica proprietatea si sitemap-ul

Asigura-te ca domeniul este disponibil in Search Console si ca sitemap-ul public poate fi trimis si citit. Pentru un redesign pe acelasi domeniu, proprietatea existenta continua sa fie utila pentru compararea comportamentului de dinainte si dupa lansare.

Inspecteaza URL-urile critice

URL Inspection poate arata daca Google cunoaste un URL, daca a putut sa-l acceseze, ce canonical a selectat si ce probleme de indexabilitate exista. Instrumentul permite si testarea versiunii live.

Pentru un site nou, incepe cu homepage-ul si paginile importante. Pentru un redesign, verifica suplimentar destinatiile redirecturilor si paginile care aveau vizibilitate sau trafic inainte de migrare.

Urmareste Page indexing, dar interpreteaza motivele

Nu orice pagina neindexata reprezinta o eroare. Google mentioneaza explicit ca duplicatele, paginile blocate intentionat, URL-urile cu noindex sau paginile eliminate pot fi corect absente din index.

Important este ca paginile pe care vrei sa le indexezi sa nu fie excluse din motive neasteptate.

Nu interpreta cateva ore fara indexare drept incident

Descoperirea, crawlingul si indexarea nu sunt instantanee. Google precizeaza ca trimiterea unei cereri de indexare nu garanteaza includerea paginii si ca procesul poate dura. Pentru multe URL-uri, sitemap-ul este metoda recomandata in locul solicitarii manuale pentru fiecare pagina.

Greseli frecvente care pot fi evitate cu un checklist

1. noindex ramas din staging

Este una dintre verificarile care ar trebui facute imediat dupa publicare, direct pe domeniul final.

2. robots.txt contine Disallow: /

Un fisier copiat din staging poate bloca crawlingul intregului site.

3. Canonical spre staging

Template-ul foloseste o variabila de configurare veche, iar toate paginile publice declara drept canonical domeniul de test.

4. URL-urile vechi sunt eliminate fara redirecturi

Daca pagina are un inlocuitor relevant, redirectul permanent trebuie pregatit inainte de migrare.

5. Toate URL-urile disparute sunt trimise spre homepage

Redirectarea trebuie sa aiba sens semantic pentru utilizator. Daca nu exista o pagina echivalenta, un raspuns de tip 404 sau 410 poate fi mai potrivit.

6. Sitemap-ul contine URL-uri vechi, redirectate sau noindex

Sitemap-ul trebuie sa reflecte setul de URL-uri canonice pe care site-ul doreste sa le faca descoperibile.

7. Pagina 404 returneaza 200

Designul paginii de eroare nu inlocuieste codul HTTP corect.

8. Echipa considera proiectul terminat in momentul publicarii

Primele zile dupa lansare sunt perioada in care trebuie urmarite indexarea, erorile, redirecturile si semnalele aparute in Search Console. O lansare tehnica buna include monitorizare post-lansare, nu doar deploy.

Checklist final: inainte si dupa lansare

Performanta merita verificata separat dupa publicare, deoarece infrastructura reala, scripturile externe si cache-ul pot produce rezultate diferite de staging. Pentru aceasta zona poti consulta serviciul de optimizare viteza website si Core Web Vitals.

SEO tehnic la lansare inseamna controlul riscurilor, nu o lista de trucuri

Un site nou nu are nevoie de configuratii sofisticate pentru fiecare detaliu. Are nevoie in primul rand de fundamente corecte: paginile potrivite sa poata fi accesate, URL-urile sa raspunda corect, continutul sa fie legat intern, canonical-urile sa fie coerente, sitemap-ul sa reflecte arhitectura reala, iar modificarile de URL sa fie gestionate prin redirectari relevante.

Cele mai periculoase probleme la lansare sunt de obicei cele simple si globale: o singura regula gresita poate afecta mii de URL-uri.

Din acest motiv, merita tratata lansarea ca un proces in trei etape: audit inainte de publicare, verificare imediata pe productie si monitorizare dupa ce crawlerele incep sa proceseze noua versiune.