Google a clarificat în octombrie 2026 trei chestiuni care afectează direct site-urile: la downtime pentru patch PHP trebuie servit un 503, robots.txt controlează doar accesul crawlerelor (nu training-ul AI), iar bracket-urile brute și cele encodate sunt URL-uri diferite. Aplicarea corectă ține de execuție, nu de uneltele AI.

Contextul: o săptămână de semnale, nu de lansări

Search Engine Journal a publicat pe 24 octombrie 2026 un rezumat săptămânal (SEO Pulse) care adună mai multe comunicări oficiale Google, plus două noutăți adiacente despre crawleri și AI. Materialul sursă este Google Explains 503s, Robots.txt Limits & Bracket URLs, semnat de Matt G. Southern.

Este important de spus de la început: nu avem aici o lansare de produs, ci o serie de clarificări operaționale. Pentru un marketer, valoarea nu stă în „știre”, ci în faptul că aceste clarificări schimbă decizii concrete de configurare: ce status code returnezi în timpul unui patch de securitate, cum blochezi selectiv un crawler AI, cum normalizezi URL-urile cu paranteze drepte și ce format de imagine folosești în img.

Le luăm pe rând și, după fiecare, ne întrebăm ce verificăm în contul sau pe site-ul nostru.

503 la downtime pentru patch PHP: regula și capcana

Pe 21 octombrie 2026, Google Search Central a revenit cu un reminder pe LinkedIn: cine scoate serverele offline pentru patch-uri PHP trebuie să returneze un status 503. Postarea a apărut în aceeași zi în care PHP a publicat fix-uri de urgență pentru două vulnerabilități critice. Mesajul Google: 503 „păstrează în Search URL-urile deja indexate în timp ce lucrezi”. Se evită 404-urile generalizate și paginile 200 care maschează o eroare. John Mueller a adăugat pe Bluesky un detaliu tehnic util: 503 nu trebuie servit neapărat prin PHP.

Aici e capcana practică. Dacă PHP-ul e oprit, cum generezi 503? Trebuie să vină dintr-o entitate care rămâne disponibilă: o regulă de rutare la CDN sau un server temporar către care duci DNS-ul. Altfel, spui că ai 503, dar de fapt ai timeout sau 500.

A doua capcană: documentația Google despre crawl rate recomandă să nu menții 503 mai mult de 1-2 zile, pentru că un URL care returnează 503 mai multe zile poate fi scos din index. Iar în ghidul despre pauzarea unui site, Google notează că un 503 servit și pentru cererile către robots.txt blochează tot crawling-ul. Deci nu e „pune 503 peste tot și dormi liniștit”.

Ce propunem concret, ca pași de verificat înainte de următorul patch:

  1. Confirmă cine răspunde cu 503 când aplicația e jos (CDN, load balancer, pagină statică).
  2. Testează pe un subdomeniu că răspunsul e 503 real, cu Retry-After, nu 200 cu text de eroare.
  3. Stabilește o fereastră de mentenanță sub 48 de ore și un plan de revenire.
  4. Verifică separat ce răspunde /robots.txt în timpul ferestrei.

Nuanță de verificare ALLSoft Media: un test pe un singur mediu nu dovedește comportamentul în producție. Dacă nu ai probă pe CDN-ul real, tratează configurarea ca ipoteză, nu ca fapt.

robots.txt: acces, nu permisiune de utilizare

Gary Illyes a explicat pe 21 octombrie 2026, într-un video Search Central, că directivele standard din robots.txt, conform RFC 9309, spun doar ce au voie să crawl-eze crawlerele conforme. Nu controlează cum e folosit conținutul după crawl. Illyes a numit robots.txt „un protocol de preferință de acces”.

Traducere pentru marketer: Disallow sub tokenul unui crawler ține acel crawler departe de anumite căi. Atât. Dacă vrei să limitezi modul în care Google folosește conținutul crawl-at pentru Gemini, instrumentul e Google-Extended, care nu e un crawler separat și nu are user-agent HTTP propriu, și care, conform Google, nu afectează includerea în Search. Un standard formal pentru a exprima preferințe de utilizare (regula Content-Usage) există doar ca document de lucru IETF, neaprobat.

Asta leagă direct de discuția mai largă despre SEO și AI Search, unde granița dintre „mă găsește” și „îmi folosește conținutul” devine o decizie de business, nu doar tehnică.

În aceeași săptămână, Cloudflare și OpenAI au anunțat rezultatele unui pilot de descoperire care a ajutat OpenAI să găsească și să indexeze sute de milioane de pagini noi. Pilotul a implicat aproximativ 1% din rețeaua Cloudflare. Postarea din 15 octombrie, co-semnată de doi angajați OpenAI, spune două lucruri esențiale: descoperirea poate crește inițial crawling-ul, iar „un semnal despre o pagină nu acordă permisiunea de a o accesa”. Nu se raportează cât de des sunt citate acele pagini și nici traficul generat.

Practic: Allow pentru OAI-SearchBot și Disallow pentru GPTBot e o configurare care separă căutarea de training. Dar descoperirea nu garantează citare, pentru că OpenAI rankează după regulile ei.

Bracket URL: brut vs. encodat, două adrese diferite

Pe 19 octombrie 2026, John Mueller a scris pe Bluesky că parantezele drepte brute dintr-un URL și formele lor percent-encodate (%5B și %5D) creează URL-uri diferite. A recunoscut că el însuși ar fi presupus că sunt echivalente și probabil a dat oamenilor răspunsul greșit în trecut. Referința e RFC 3986, standardul de sintaxă URI, care rezervă parantezele și semnul plus.

Ce se întâmplă dacă ambele variante returnează același conținut? Google crawl-ează fiecare versiune, elimină duplicatele și alege una singură. Recomandarea lui Mueller: alege o formă și folosește-o consistent, în linkuri, canonical, sitemap și date structurate. Mueller a spus că un site existent care folosește paranteze brute peste tot ar trebui să continue să funcționeze, dar că nu ar construi un site nou așa.

De ce contează? Pentru că mixul între forme (link intern brut, canonical encodat, sitemap cu a treia variantă) forțează Google să decidă ce versiune păstrează. Asta e o decizie pe care nu o controlezi. Pentru magazine online cu filtre și parametri, e un risc de fragmentare a semnalelor, care se vede în analytics ca trafic „pierdut” fără explicație.

Un pas de verificat, nu o certitudine: extrage din sitemap și din crawl-ul intern toate URL-urile cu paranteze, compară-le cu canonical-urile și clasifică-le. Dacă apar ambele variante, ai ipoteză de inconsistență. Nu înseamnă automat că ai problemă de indexare, dar merită curățat înainte de a scala conținutul.

JPEG XL: suport în browsere, nu în Google Images

Pe 15 octombrie 2026, Mueller a confirmat pe Bluesky că imaginile JPEG XL nu sunt suportate momentan în Google Images și nici ca preview-uri în Discover. Contextul: Chrome 155 a început distribuirea largă a suportului JPEG XL pe 6 octombrie, iar Firefox 158 pe 13 octombrie.

Documentația Google de image SEO listează pentru atributul src al unui element img formatele BMP, GIF, JPEG, PNG, WebP, SVG și AVIF. JPEG XL nu apărea în listă la 22 octombrie. Întrebat despre fallback-uri în elementul picture, Mueller a răspuns că elementul include un img, deci acel img funcționează pentru orice motor de căutare.

Recomandarea practică e simplă: servește JPEG XL ca sursă în picture, dar păstrează un JPEG, WebP sau AVIF în img. La fel pentru og:image și datele schema.org folosite de Discover. Câștigi performanță fără să pierzi vizibilitatea în Search și Discover.

Pentru un magazin online, asta e o decizie de conversie, nu doar de SEO. Imaginile mai mici înseamnă pagini mai rapide. Dar dacă formatul principal nu e citit de Google, ai optimizat jumătate din problemă. Merită verificat în Search Console ce imagini sunt indexate, nu presupus.

Ce înseamnă pentru tine, antreprenor sau marketer în România

Hai să traducem totul într-o zi de lucru pentru un business românesc cu magazin online pe WooCommerce sau un site de servicii.

Primul scenariu: vine un patch PHP de securitate într-o marți seara. Cineva din echipă oprește serverul, pune o pagină de mentenanță care returnează 200, iar Google vede conținut schimbat, nu indisponibilitate temporară. Rezultatul nu îl poți măsura imediat, dar regulile spun clar: 503 e semnalul corect, în fereastră scurtă. Întrebarea de verificat e dacă ai acum cine să configureze asta în CDN. Dacă răspunsul e „nu știm”, ai o lipsă de proces, nu o problemă SEO.

Al doilea: ai decis să limitezi accesul AI la conținut. Disallow în robots.txt e ușor de pus și dă senzația de control. Dar, conform celor spuse de Illyes, el controlează doar crawling-ul. Dacă vrei să conteze și pentru utilizare, trebuie să privești tokenul de tip Google-Extended și politica fiecărui furnizor. Nu există un buton universal.

Al treilea: ai linkuri cu paranteze în categorii de produs. Verifică dacă sunt consistente. Nu e sexy, dar e ieftin de curățat și previne o decizie luată de Google în locul tău.

Al patrulea: testezi JPEG XL. Folosește-l, dar nu în img ca singur format. Aici psihologia reclamelor sociale și viteza paginii se întâlnesc: imaginea rapidă ajută la atenție, dar dacă nu e citită de Google Images, pierzi un canal.

Aplicarea pe termen scurt nu cere buget mare. Cere un checklist și o persoană care răspunde de el. În paralel, dacă lucrezi cu TikTok sau alte platforme de performance, vezi și discuția despre unde se oprește performance marketing-ul: semnalele tehnice bune se văd în tot funnelul.

FAQ

Trebuie să pun 503 pe tot site-ul când fac un patch PHP? Doar dacă scoți efectiv serverul jos și doar pe durată scurtă, ideal sub 48 de ore, conform recomandării Google. Nu folosi 503 ca soluție permanentă și nu servi 503 și pentru robots.txt fără să înțelegi că blochezi crawling-ul.

robots.txt mă ajută să opresc antrenarea modelelor AI pe conținutul meu? Nu direct. robots.txt e un protocol de acces: spune crawlerele conforme ce au voie să acceseze. Pentru preferințe de utilizare există tokenuri precum Google-Extended și, la nivel de standard, doar un draft IETF neaprobat.

Pot folosi JPEG XL pe site fără să pierd vizibilitate în Google Images? Da, dacă îl pui ca sursă în picture și păstrezi un format suportat (JPEG, WebP, AVIF) în img, plus în og:image și datele structurate. Google Images nu citește JPEG XL momentan.

Arcul final: AI pentru analiză, omul pentru decizie

Uneltele AI sunt bune la triaj: pot scana un sitemap după URL-uri cu paranteze, pot genera un checklist de mentenanță, pot compara documentația Google cu configurația ta. Nu pot decide dacă downtime-ul de mâine merită 503 sau dacă blocarea unui crawler AI e o decizie de business sau o reacție. Aici intră omul, media buyer-ul sau SEO-ul senior, care cunoaște contextul comercial și își asumă execuția. Iar pasul concret, de la audit la implementare, îl face ALLSoft Agency.