Cum am folosit Claude Code pentru SEO și am crescut afișările blogului de aproape 7 ori

Am folosit Claude Code ca unealtă de SEO pe blogul acestui site, zi de zi, timp de o lună și jumătate — nu ca să scriu articole, ci ca să repar ce ținea site-ul departe de Google. Rezultatul, verificat în Google Search Console pe ferestre de 28 de zile, fără nicio cifră aproximată: de la 12 afișări/zi (7 iulie 2026) la 82 afișări/zi (25 august 2026) — aproape de șapte ori mai mult, iar clicurile au urcat de la 8 la 42 în aceleași ferestre.

Pe scurt

• Nu conținutul a fost gâtuirea principală — au fost lucruri tehnice ascunse: robots.txt rescris de Cloudflare, sitemap-uri căzute în tăcere, meta descrieri lipsă pe 79 de pagini, boți AI blocați cu 403 de găzduire.
• Fiecare reparație a fost verificată cu o comandă, nu presupusă — curl cu user-agent de bot, citirea logurilor brute ale serverului, interogarea directă a Google Search Console prin API.
• Instrumentul (Claude Code) a scris cod PHP pentru temă, scripturi Python de întreținere și a citit mii de linii de log — dar decizia de business a rămas mereu a omului: ce se publică, ce se șterge, ce risc se acceptă.

Cifrele, exact cum au fost măsurate

Metoda: sumă de afișări/clicuri pe fereastra mobilă de 28 de zile, împărțită la 28, din exportul zilnic al Google Search Console. Nu e o singură zi bună aleasă din context — e trendul, verificat la fiecare pas.

Ce a reparat, de fapt, Claude Code

1. Un sitemap care răspundea 200, dar era înghețat

Cel mai periculos defect găsit: post-sitemap.xml răspundea corect (200, text/xml), dar lastmod rămăsese blocat cu ore în urmă — articolele noi publicate prin API nu mai apăreau în el. Un răspuns 200 trece de orice verificare superficială, în timp ce Google nu mai vedea nimic nou. Cauza: cache-ul intern de sitemap al pluginului SEO nu se golea la publicare prin REST API. Rezolvarea a intrat direct în codul temei — o linie care golește cache-ul de sitemap odată cu restul, la fiecare save_post.

2. Boți AI blocați cu 403, de către găzduire — nu de site

Testul simplu care a descoperit problema: curl -A "GPTBot/1.2" https://site.ro/ întorcea 403, în timp ce un browser obișnuit primea 200. Verificat pe logurile brute ale serverului (22.176 de linii, o zi întreagă): GPTBot, OAI-SearchBot, ClaudeBot și PerplexityBot erau respinși sistematic, la nivel de server, deși robots.txt le permitea explicit accesul. Găzduirea a confirmat: blocaj global, indiferent de conținutul robots.txt.

Soluția n-a cerut schimbarea găzduirii — un Cloudflare Worker simplu, care rescrie User-Agent-ul doar pentru acei cinci boți, înainte ca cererea să ajungă la server. Cod scurt, cont gratuit, verificat imediat cu același curl: 200, conținut identic cu ce vede un browser.

3. Meta descrieri lipsă pe 79 de pagini — reparate prin API, nu manual

Un audit tehnic arăta 79 de pagini fără meta descriere. Reparate una câte una ar fi fost o zi de muncă mecanică; prin REST API al WordPress-ului, cu un script care citește fiecare articol și scrie câmpul lipsă direct în pluginul SEO, timpul a scăzut la câteva minute — verificat după aceea că numărul a ajuns la zero.

4. Schema FAQPage, generată automat din text — nu din plugin

Pluginul de SEO nu putea genera automat schema FAQPage pe articolele scrise în markdown (nu în blocuri native WordPress). Soluția: o funcție în tema site-ului care caută în conținut secțiunea „Întrebări frecvente” și extrage automat întrebările și răspunsurile în JSON-LD, la afișarea paginii — fără muncă suplimentară la fiecare articol nou, cât timp respectă structura.

5. Conținut extins acolo unde datele arătau exact ce lipsea

Nu „mai mult conținut”, ci conținut care răspunde la formulările reale căutate. Un articol stătea la poziția 43-57 pentru un grup de căutări înrudite. Citind în Search Console formulările exacte care aduceau afișări fără clicuri, s-a văzut ce lipsea din articol: numele oficiale ale registrelor citate, o secțiune care răspundea direct la o întrebare frecventă neacoperită. După completare, aceleași căutări au urcat la poziția 20-29 — verificat, nu presupus.

Vrei să măsori și tu? De unde iei acces la Google Search Console, Bing și LinkedIn

Măsurarea impactului nu se face din articolul de pe blog — se face din trei surse separate, fiecare cu propriul mod de acces. Niciuna nu e o singură „cheie” pe care o copiezi de undeva, ca la un serviciu simplu; fiecare are propriul flux, o singură dată la configurare, apoi rulează singur.

1. Google Search Console — nu are cheie API clasică, ci autentificare OAuth. Intri în Google Cloud Console, creezi un proiect, activezi „Search Console API”, generezi credențiale OAuth de tip „Desktop app” și descarci fișierul de client. La prima rulare a scriptului care le folosește, se deschide browserul, te loghezi cu contul Google care are acces la proprietatea din Search Console, iar tokenul rezultat se salvează local — nu mai ceri login la fiecare rulare.
2. Bing Webmaster Tools — are cheie API propriu-zisă. Din contul de pe bing.com/webmasters, din setările contului, generezi cheia și o pui într-un fișier .env, alături de celelalte. Apelurile ulterioare trimit cheia ca parametru la fiecare cerere.
3. LinkedIn — API-ul oficial e restrictiv pentru un cont obișnuit (accesul la statistici de postare cere aprobare de partener, greu de obținut pentru o firmă mică). Pe acest site, publicarea și statisticile de pe LinkedIn (și Facebook, Instagram) trec printr-un instrument terț de publicare, cu propria cheie API — nu prin accesul direct la LinkedIn.

Nicio cheie nu se scrie direct în cod sau într-o conversație — toate stau în fișiere .env, care nu se urcă niciodată pe un depozit public de cod. Interfețele de mai sus se schimbă din când în când — verifică pagina oficială a fiecărui serviciu dacă un meniu nu mai corespunde exact cu ce scrie aici.

Patru prompturi simple, ca să pornești

Verifică dacă sitemap-ul de pe  răspunde cu cod 200 și
conține toate articolele mele publicate recent. Spune-mi exact ce
lipsește, dacă lipsește ceva, și cum ai verificat.

Testează cu curl accesul la  pentru user-agenții
GPTBot, ClaudeBot, PerplexityBot și Googlebot. Compară codurile de
răspuns cu ce primește un browser normal și spune-mi dacă vreunul
e blocat, cu dovada exactă (comanda + rezultatul).

Prin API-ul platformei mele (sau uneltele pe care le ai la
dispoziție), listează toate articolele publicate care nu au meta
descriere completată. Nu le modifica — arată-mi doar lista, decid
eu ce reparăm și în ce ordine.

Din tot ce ai găsit până acum, fă-mi o listă scurtă, ordonată
după impact: ce e stricat, de ce cred că a trecut neobservat până
acum, și ce reparăm primul.

Pentru un audit complet, cu toți pașii de mai sus legați într-un singur prompt, poți descărca promptul întreg de aici și-l lipești în Claude Code, cu adresa ta de site completată.

Ce NU face metoda

• Nu garantează creșterea pe alt site — punctul de plecare aici era aproape de zero (fără plugin SEO instalat inițial), deci orice reparație avea de unde să crească.
• Nu înlocuiește verificarea faptelor — fiecare cifră de lege sau de piață citată în articole a fost verificată la sursă, niciodată preluată direct dintr-un răspuns AI.
• Nu e „setează și uită” — sitemap-ul și robots.txt-ul s-au stricat din nou, de mai multe ori, din cauze diferite (schimbare de plugin, migrare de găzduire). Verificarea de rutină rămâne obligatorie, nu o dată, ci la fiecare sesiune.
• Nu a mutat încă traficul din Bing — indexul Bing a rămas aproape gol în tot acest interval, în ciuda acelorași reparații; problema acolo pare a fi bugetul de crawl/autoritatea site-ului, nu ceva tehnic rămas nereparat.

Întrebări frecvente

De unde știu că nu e doar coincidență, nu efectul reparațiilor?

Nu se poate separa perfect — reparațiile tehnice și publicarea constantă de conținut s-au făcut în paralel. Ce se poate spune cu certitudine: fără sitemap funcțional și fără acces pentru boții AI, conținutul nou n-ar fi avut cum să fie descoperit deloc, indiferent cât de bun era.

Are nevoie de abonament Semrush sau alt instrument plătit?

Nu, obligatoriu. Un audit tehnic plătit a ajutat la început să găsească problemele mari dintr-o singură scanare, dar reparațiile ulterioare s-au bazat pe instrumente gratuite: Google Search Console, Bing Webmaster Tools, curl din linia de comandă și citirea directă a logurilor serverului.

Cât durează o astfel de reparație?

Depinde de problemă. Un sitemap înghețat sau meta descrieri lipsă se rezolvă în ore. Blocajul de boți AI de la găzduire a cerut o zi de investigație (citirea logurilor, confirmarea cu găzduirea) plus o oră de implementare a soluției.

Ce se măsoară după publicare, ca să se știe dacă a mers?

Trei surse, verificate separat: Google Search Console (afișări, clicuri, poziție, pe ferestre de 28 de zile, nu pe o zi izolată), Bing Webmaster Tools (index, crawl, trafic) și, pentru distribuție, statisticile rețelelor sociale unde a fost publicat articolul.

Se poate face fără să știi să scrii cod?

Instrumentul scrie codul; omul verifică fiecare rezultat cu o comandă simplă înainte de a-l accepta — curl, un export din Search Console, o captură de ecran. Fără verificarea aceea, o reparație care pare corectă poate rămâne stricată în tăcere, exact cum a fost cazul sitemap-ului înghețat.

Ce legătură are cu firma ta?

Aceeași disciplină — verifică fiecare rezultat, nu presupune că a mers — e valabilă la orice automatizare construită cu AI pentru o firmă mică, nu doar la SEO. Dacă vrei să vezi ce se poate automatiza concret în firma ta, poți începe de la pagina de automatizări sau de la cursul de AI pentru firme.

Surse

• Datele proprii din Google Search Console (property simpluspv.eu), exportate și agregate în ferestre de 28 de zile.
• Loguri brute de acces ale serverului (Raw Access), analizate pentru identificarea boților AI blocați.