Dacă folosești meta tagul unavailable_after pe paginile tale și dai data mai departe la fiecare reînnoire, Google poate interpreta greșit semnalul. Gary Illyes de la Google a recunoscut că nu știe sigur cum reacționează crawlerul. Până la clarificări oficiale, riscul de deindexare accidentală este real și trebuie luat în serios.

Ce este unavailable_after și de ce contează

Tagul unavailable_after este o directivă de indexare pe care o poti plasa în antetul HTTP sau în meta tagul robots al unei pagini. Rolul lui este simplu: îi spui Googlebot că, după o anumită dată, pagina respectivă nu mai trebuie să apară în rezultatele de căutare.

Cazul clasic de utilizare este o promoție cu termen limitat, un eveniment care s-a terminat sau o ofertă sezonieră. Setezi data de expirare, Google o respectă, pagina dispare din index fără să fie nevoie de o redirecționare sau de o ștergere manuală.

Teoretic, mecanismul este elegant. Practic, apare o problemă atunci când pagina rămâne activă, dar tu împingi data mai departe în timp, la fiecare reînnoire a conținutului sau a ofertei.

Ce a spus Gary Illyes și de ce contează lipsa unui răspuns clar

Gary Illyes, inginer la Google și una dintre vocile tehnice cele mai credibile din ecosistemul de căutare, a fost întrebat direct dacă mutarea datei unavailable_after mai departe în viitor, la fiecare ciclu de reînnoire, poate cauza probleme. Răspunsul lui, relatat de Search Engine Journal (sursa originală), a fost că ar trebui să verifice. Nu a confirmat că totul este în regulă. Nu a infirmat că există un risc.

Acest tip de răspuns, aparent minor, are greutate tocmai pentru că vine de la cineva care cunoaște infrastructura Google din interior. Când un inginer de la Google zice „trebuie să verific", înseamnă că documentația internă fie nu acoperă scenariul respectiv, fie comportamentul nu este complet predictibil.

Pentru un site cu sute sau mii de pagini cu date de expirare gestionate automat, asta înseamnă că există un vector de risc neconfirmat și negestionat.

Cum funcționează crawlerul în raport cu această directivă

Googlebot nu recrawlează o pagină în timp real. Există un interval între momentul în care tu modifici o directivă și momentul în care Googlebot o citește efectiv și o aplică în index.

Dacă Googlebot vizitează pagina ta pe data de 10 a lunii și găsește unavailable_after: 15.06.2026, va nota că pagina trebuie scoasă din index după acea dată. Dacă tu, pe 14.06.2026, modifici tagul în unavailable_after: 15.09.2026, dar Googlebot nu recrawlează pagina înainte de 15.06.2026, pagina poate fi scoasă din index conform primei date citite.

Acesta este scenariul cel mai probabil problematic. Nu este vorba despre un bug deliberat, ci despre latența naturală a crawlării.

Cu atât mai mult, pe site-urile mari, unde prioritizarea crawlului este gestionată de bugetul de crawl, unele pagini pot fi recrawlate rar. O pagină de produs sau de ofertă care nu primește link-uri noi, nu are trafic semnificativ și nu a fost modificată recent poate fi vizitată de Googlebot o dată la câteva săptămâni sau chiar luni.

Dacă în acel interval data de expirare a trecut și tu nu ai reușit să o actualizezi înainte ca Googlebot să o proceseze, pagina dispare din index.

Ce inseamna pentru tine, ca antreprenor sau marketer din Romania

Să traducem asta în scenarii concrete, relevante pentru piața locală.

Ai un magazin online cu promotii recurente. Folosesti unavailable_after pe paginile de landing ale promotiilor, pentru că ai citit că e o practică bună. Promotia se reînnoiește lunar. Setezi o nouă dată la fiecare ciclu.

Dacă procesul este manual, riscul este că uiți sau întârzii actualizarea. Dacă procesul este automatizat printr-un script care modifică tagul în același timp cu prelungirea ofertei, depinzi de frecvența cu care Googlebot vizitează paginile respective.

Pe scurt: nu poți controla momentul crawlării. Poți controla doar momentul în care modifici tagul.

Recomandarea practică, până când Google clarifică oficial comportamentul, este una dintre următoarele trei:

Prima variantă. Nu folosești deloc unavailable_after pe pagini cu conținut recurent sau reînnoibil. Folosești în schimb noindex adăugat manual sau prin reguli CMS atunci când vrei să scoți pagina din index, și îl elimini când pagina redevine relevantă.

A doua variantă. Dacă vrei să păstrezi tagul, setezi data cu o marjă generoasă în viitor și o actualizezi cu cel puțin 7-10 zile înainte de expirare, nu în ziua expirării sau după.

A treia variantă. Dacă ai un site mare și procesul este automatizat, adaugi în pipeline-ul de actualizare și o cerere de recrawl prin Google Search Console, imediat după ce modifici tagul. Nu garantează că Googlebot vine instant, dar crești probabilitatea ca noua dată să fie citită la timp.

Același principiu de a nu presupune că Google interpretează directivele exact cum te aștepți apare și în alte contexte tehnice. De exemplu, disallow în robots.txt nu echivalează cu noindex, o confuzie care costă vizibilitate pe mulți proprietari de site-uri din România.

Cum monitorizezi situatia

Nu există un raport dedicat în Google Search Console care să îți arate paginile scoase din index din cauza unavailable_after. Trebuie să faci corelații manuale sau să construiești un sistem propriu de monitorizare.

Pașii minimi:

  1. Exportezi din Search Console lista de pagini cu acoperire redusă sau excluse din index.
  2. Compari cu lista de URL-uri care au tagul unavailable_after activ.
  3. Verifici dacă datele de expirare s-au suprapus cu momentele de scădere a indexării.

Dacă observi pierderi de trafic organice inexplicabile pe pagini care ar trebui să fie active, corelația cu datele de expirare expirate sau procesate cu întârziere este un punct de investigat. Contextul mai larg al volatilității din indexul Google este analizat în detaliu în articolul despre volatilitate Google din 2026 și ce faci când rankings-ul se mișcă.

Ce ar trebui sa faca Google

Comportamentul așteptat al unui sistem bine documentat este predictibil. Un webmaster care mută data unavailable_after înainte ca aceasta să expire ar trebui să aibă garanția că Google respectă noua dată, nu pe cea veche, dacă actualizarea este citită înainte de termenul inițial.

Problema nu este că mecanismul este greșit în principiu. Problema este că documentația oficială nu acoperă explicit scenariul de reînnoire repetată, iar răspunsul lui Illyes confirmă că nici intern nu există un răspuns documentat imediat disponibil.

Ce ar rezolva situația: o clarificare oficială în documentația Google pentru developeri, cu un exemplu explicit pentru cazul de reînnoire, și eventual un semnal în Search Console care să arate data la care Googlebot a citit ultima oară tagul și ce valoare a găsit.

Până atunci, tratezi unavailable_after ca pe o directivă cu comportament parțial impredictibil în scenariile de actualizare repetată.

FAQ

Pot folosi unavailable_after pe paginile de produs dintr-un magazin online?

Poți, dar nu este recomandat pentru produse cu disponibilitate fluctuantă. Tagul este potrivit pentru pagini cu dată de expirare clară și definitivă. Pentru produse care se reactivează periodic, gestionarea manuală a indexării prin noindex și index controlat este mai sigură.

Dacă trece data din unavailable_after, pagina se șterge automat de pe site?

Nu. Tagul influențează doar indexul Google, nu afectează pagina de pe serverul tău. Pagina rămâne accesibilă la URL, dar nu mai apare în rezultatele de căutare Google. Dacă vrei să o scoți și din index la alte motoare de căutare, ai nevoie de directive separate.

Cât de repede procesează Google o actualizare a tagului unavailable_after?

Depinde de frecvența de crawl a paginii respective. Nu există un termen garantat. Pe paginile crawlate frecvent, în câteva zile. Pe paginile cu crawl rar, pot trece săptămâni. Asta face ca actualizarea în ultimul moment să fie riscantă.

Pasul urmator: analiza, decizie, executie

Situațiile tehnice de acest tip, în care documentația oficială are goluri și nici reprezentanții Google nu au un răspuns imediat, necesită o abordare structurată. Un instrument AI poate scana rapid documentația disponibilă, poate identifica paginile cu taguri de expirare active și poate semnaliza riscurile potențiale.

Dar decizia despre cum structurezi directivele de indexare pe site-ul tău, ce pagini merită să rămână în index și cum construiești procesul de reînnoire fără să pierzi vizibilitate organică, aceea rămâne o decizie luată de un specialist, nu de un model de limbaj.

La ALLSoft Agency facem exact asta: audităm configurația tehnică SEO, identificăm vectorii de risc care nu apar în rapoartele standard și construim procese care să funcționeze în condiții de incertitudine, nu doar în scenariile documentate.