Google a actualizat pe 16 octombrie documentația Indexing API pentru a prezenta limitele de utilizare și procedura curente. Compania a eliminat și un formular depășit. Actualizarea privește informațiile pentru dezvoltatori; accesul rămâne destinat paginilor cu anunțuri de angajare sau cu transmisiuni video în direct, în condițiile tehnice stabilite de Google.

Interfața permite administratorilor să anunțe individual apariția, modificarea sau eliminarea unei pagini eligibile. Este folosită pentru conținut cu o durată de viață scurtă, unde momentul publicării și cel al retragerii contează pentru informația afișată în căutare. Google poate programa o nouă accesare a paginii după primirea notificării.

Trei persoane lucrează la laptopuri și verifică documente într-un birou
Mikhail Nilov

Limitele sunt calculate pe proiect și pe tip de solicitare

Limita zilnică implicită este de 200 de solicitări către funcția de publicare, pentru fiecare proiect. Același plafon include notificările URL_UPDATED și URL_DELETED. Contorul se resetează la miezul nopții după ora Pacificului. Pentru citirea metadatelor sunt prevăzute 180 de solicitări pe minut per proiect, iar plafonul general este de 380 pe minut, pentru toate funcțiile. Utilizarea API-ului este gratuită, iar cotele proiectului pot fi consultate în Google API Console.

Documentația de referință descrie separat citirea metadatelor. Funcția getMetadata operează asupra adreselor pentru care Google a primit anterior o notificare reușită prin Indexing API. Solicitarea identifică adresa analizată și necesită autorizare. Astfel, verificarea unei notificări se raportează la istoricul acelui URL în interfață, în loc să reprezinte o analiză generală a oricărei pagini de pe internet.

Obiectul de răspuns păstrează adresa și cele mai recente notificări de actualizare, respectiv de eliminare. Aceste câmpuri oferă aplicației o evidență a operațiunilor transmise către Google. Un sistem care gestionează automat anunțuri de recrutare poate corela istoricul notificărilor cu propriile momente de publicare și retragere, fără să confunde aceste înregistrări cu prezența paginii în rezultatele căutării.

Eligibilitatea rămâne legată de conținutul paginii

Google precizează două configurații acceptate: date structurate JobPosting sau BroadcastEvent inclus într-un obiect VideoObject. Prin urmare, utilizarea Indexing API se leagă de tipul efectiv al paginii și de marcajul corespunzător. Serviciile comerciale, articolele obișnuite și categoriile unui magazin online nu intră în această listă doar pentru că administratorul le poate transmite tehnic printr-o integrare.

Pentru anunțurile de angajare, regulile de afișare cer informații complete despre un post real și o pagină dedicată anunțului. Marcajul JobPosting aparține paginii unui singur post, nu unei liste generale de locuri de muncă. Conținutul vizibil și datele structurate trebuie să descrie aceeași ofertă, astfel încât informațiile trimise motorului de căutare să corespundă celor citite de candidat.

Retragerea unui post închis are, la rândul ei, condiții concrete. Documentația pentru recrutare prevede actualizarea datei de expirare, eliminarea marcajului sau retragerea paginii, în funcție de situație. Pentru solicitarea de eliminare prin API, pagina trebuie să returneze 404 ori 410 sau să conțină directiva noindex. Semnalarea urmează schimbarea efectivă a paginii.

Accesul presupune verificarea proprietății și autentificare

Integrarea utilizează un proiect în care Indexing API este activat și un cont de serviciu. Proprietatea website-ului se verifică în Search Console, după care contul de serviciu primește dreptul de proprietar delegat. Apelurile sunt autentificate cu un token OAuth cu domeniul de acces dedicat indexării. Aceste cerințe leagă operațiunile de administratorul autorizat al website-ului și de proiectul care consumă cota.

Răspunsurile de eroare separă problemele de acces de cele de capacitate. Google documentează eroarea 403 pentru verificarea nereușită a proprietății adresei și eroarea 429 pentru depășirea cotei Indexing API. Solicitările respinse nu determină accesarea URL-ului. Un jurnal tehnic trebuie, așadar, să păstreze rezultatul operațiunii, pentru ca o trimitere eșuată să fie identificată corect.

Catalogul de erori include și codul 400 pentru cereri incorecte sau incomplete, precum lipsa adresei, și codul 401 pentru probleme de autentificare. Aceste răspunsuri descriu prelucrarea cererii de către interfață. Ele permit delimitarea unei configurări greșite a aplicației de atingerea limitei de utilizare și de situația unei pagini care a fost deja analizată de motorul de căutare.

Un răspuns HTTP 200 la notificarea de actualizare confirmă operațiunea acceptată și este asociat metadatelor acesteia. Google descrie etapa următoare drept o posibilă reexplorare a adresei. Trimiterea se face în format JSON, cu un singur URL în fiecare notificare. Mai multe notificări pot fi grupate, în limita a 100 de apeluri într-o cerere batch; instrucțiunile interzic ocolirea limitelor prin conturi multiple.

Starea indexării se urmărește în Search Console

Instrumentul de inspectare URL din Search Console arată informațiile disponibile despre versiunea unei pagini cunoscută de Google. El include starea indexării, ultima accesare și detalii despre adresa canonică. Testul live verifică pagina accesibilă în acel moment, în timp ce raportul de indexare se referă la versiunea procesată anterior. Cele două perspective au momente de referință diferite.

Google păstrează și cerințele tehnice generale pentru apariția în căutare: acces pentru Googlebot, răspuns HTTP 200 al paginii și conținut indexabil. Paginile care cer autentificare sau blochează accesul robotului au condiții de acces diferite de cele ale unei pagini publice. Aceste elemente sunt verificate la nivelul website-ului și rămân parte din administrarea SEO, inclusiv când există o integrare pentru notificări.

Pentru descoperirea paginilor obișnuite, Google folosește legăturile dintre pagini și informațiile din sitemapuri. Un sitemap poate descrie adrese importante, ultima actualizare și variantele lingvistice. Este util mai ales pentru website-uri mari, noi sau cu resurse media specializate. Această mecanică acoperă un domeniu mai larg de conținut decât paginile de recrutare și transmisiunile în direct acceptate de Indexing API.