Testkeskkond ja toodang: kuidas Disallow: / live-saidile ei jõua

Lühike vastus

Testkeskkond suletakse parooliga veebiserveri seadetes (basic-auth nginxis või Apaches), mitte robots.txt-i reaga Disallow: /. Parool elab testserveris ega satu repositooriumisse, seega ei saa deploy seda live-saidile viia. Fail robots.txt ja noindex-metasilt asuvad projekti koodis ning liiguvad toodangusse koos kõige muuga.

Pärast iga avaldamist on live-domeenil vaja kolme kontrolli: robots.txt faili sisu, noindex-i otsing avalehe koodist ja serveri vastuse päised curl-iga. Kokku kulub 5 minutit.

Miks Disallow: / testsaiti ei kaitse

Real Disallow: / on testkeskkonnas kaks viga. Esimene: see ei sulge indekseerimise eest. Google Search Central kirjutab otse, et robots.txt juhib roomamist ja blokeeritud URL võib indeksisse jõuda, kui sellele viitavad lingid. Testalamdomeen leitakse lingist e-kirjas, avaliku tahvliga ülesannete haldurist, ekraanipildist või Referer-päisest. Siis ilmub otsingusse dev.sait.ee märkega, et kirjeldus pole saadaval.

Teine viga on kallim. Fail on repositooriumis ja avaldamisel kopeeritakse see toodangusse. Sait töötab, avaneb, vorm saadab, brauseris ei märka keegi midagi. Probleem selgub ühe-kahe nädala pärast Search Console'i näitamiste graafikult. Veebilehe kolimise kontrollnimekirjas nimetasin seda kolimise kõige sagedasemaks ebaõnnestumise põhjuseks ja aastatega pole see muutunud.

Kuidas testkeskkond sulgeda, et keeld kaasa ei liiguks

Mul on üks töötav skeem: basic-auth nginxi tasemel ainult testkeskkonna seadetes. Next.js-i või WordPressi projektis pole ühtegi indekseerimist puudutavat rida, mis testkeskkonnas ja toodangus erineks.

server {
    server_name dev.example.ee;
    auth_basic "Staging";
    auth_basic_user_file /etc/nginx/.htpasswd-staging;
    # ...
}

Kui sait on Cloudflare'is, lahendab sama ülesande Cloudflare Access testalamdomeenil: ligipääs e-posti või ühekordse koodiga, jällegi väljaspool repositooriumi. Vercelis annavad eelvaate-buildid vaikimisi päise X-Robots-Tag: noindex, kuid toodangu omadomeenile seda ei lisata. Seal on risk teist laadi: suletud on eelvaade, mille saatsid kliendile kui „peaaegu valmis saidi“.

Kui ilma metasildita koodis ei saa (näiteks üks Next.js-i mall buildib kõik keskkonnad), lülitub noindex sisse ainult selgesõnalise muutujaga, näiteks SITE_ENV=staging. Muutuja puudumine peab tähendama „indekseeri“, mitte vastupidi. Kui loogika on pööratud, on esimene server, kus muutuja jäi määramata, suletud.

Kus keeld avaldamisel peidus on

Kui liiklus pärast avaldamist langes, kontrollin 5 kohta selles järjekorras: kõige sagedasemast kõige märkamatumani, robots.txt-ist Cloudflare'i reegliteni.

1. Fail robots.txt. Avan brauseris https://sait.ee/robots.txt ja otsin rida Disallow: / ilma teeta pärast kaldkriipsu. Kui fail genereeritakse (Next.js-is app/robots.ts), vaatan ka generaatori koodi: seal leidub keskkonnatingimus, mille harud on segi aetud.
2. Robots-metasilt. Otsin noindex avalehe ja ühe sisemise lehe lähtekoodist, mitte DevToolsist, vaid valikuga „Kuva lehe lähtekood“. Erinevad mallid võivad käituda erinevalt.
3. Päis X-Robots-Tag. Käsk curl -I https://sait.ee/ näitab vastuse päiseid. Seda keeldu ei näe lehe koodis ega brauseris, seepärast otsitakse seda viimasena, kuigi kontroll võtab sekundi.
4. WordPressi seade. Linnuke „Keela otsingumootoritel selle saidi indekseerimine“ on salvestatud andmebaasi valikusse blog_public. Andmebaasi viimisel testkeskkonnast toodangusse liigub see kaasa, isegi kui projekti failid laaditi üles puhtana. Alates versioonist 5.7 väljastab WordPress sel juhul noindex-metasildi, nii et punkti 2 kontroll püüab ka selle kinni.
5. CDN-i ja majutuse reeglid. Cloudflare'i Transform Rules, päised majutuse halduspaneelis, turvapluginad. Kui curl -I näitab X-Robots-Tag päist, aga nginxi seadetes seda pole, tuleb otsida siit.

Eraldi juhtum, mis ununeb: robots.txt on avatud, kuid selles on suletud CSS-i ja JS-i tee. Sait on indeksis, aga Google renderdab selle ilma stiilideta. Mida selles failis sulgeda ja mida mitte, kirjutasin artiklis sitemap.xml ja robots.txt seadistamisest.

Kontroll pärast avaldamist: viis minutit

Need 5 punkti käin käsitsi läbi pärast iga avaldamist, mis puudutas malle, nginxi seadistust või andmebaasi.

1. https://sait.ee/robots.txt brauseris: pole Disallow: /, on rida Sitemap: töötava aadressiga.
2. Avalehe ja ühe tootekaardi või artikli lähtekood: pole noindex, canonical viitab live-domeenile, mitte dev. aadressile.
3. curl -I https://sait.ee/: olek 200, pole X-Robots-Tag: noindex.
4. Search Console'i „URL-i kontrollimine“ avalehele nupuga „Testi URL-i reaalajas“: olek „URL-i saab indekseerida“.
5. Kahe-kolme päeva pärast aruanne „Lehtede indekseerimine“: ei kasva kategooria „Blokeeritud faili robots.txt poolt“ ega „Välistatud sildiga noindex“.

Punkt canonical-i kohta pole nimekirjas täielikkuse pärast. Next.js-i või WordPressi mall, mis ehitati testkeskkonnas, võtab vahel domeeni keskkonnamuutujast ja toodang saab canonical-i testaadressile. Google näeb siis sama teksti kahte versiooni ja valib kanoonilise ise; kuidas see aruannetes välja näeb, kirjeldasin artiklis duplikaatsisu leidmisest ja parandamisest.

Kui keeld on juba toodangus

Tegevuste järjekord sõltub sellest, kumb keeld rakendus: robots.txt või noindex. Seega kõigepealt diagnoos ülaltoodud 5 punkti järgi, siis parandus Search Console'is.

• Toodangusse jõudis Disallow: /. Paranda fail, ava Search Console'is robots.txt-i aruanne ja taotle uuesti roomamist. Google hoiab robots.txt-i vahemälus kuni 24 tundi ja ilma taotluseta võib robot veel ööpäeva vana versiooni järgi töötada.
• Toodangusse jõudis noindex. Eemalda see ja saada URL-i kontrollimisele avaleht ja põhirubriigid. Ülejäänu tuleb tavalise roomamisega järele.
• Mõlemal juhul esita sitemap.xml uuesti: see annab robotile nimekirja aadressidest, mis tuleb uuesti läbi käia.

Naasmise aega ei saa ennustada, see sõltub konkreetse saidi roomamissagedusest. Saidil, mida Googlebot külastab iga päev, tulevad esimesed lehed tagasi kiiremini kui 30-leheküljelisel saidil, kuhu robot satub kord nädalas. Kui kahe-kolme nädala pärast on lehed endiselt olekus „Roomatud – praegu indekseerimata“, pole põhjus enam keelus ja edasi aitab artikkel sellest, miks Google lehti ei indekseeri.

Kellele basic-auth ei sobi

Parool testkeskkonnas on ebamugav 3 olukorras ja neis valin Cloudflare Accessi, IP-nimekirja või eraldi test-URL-i.

• Klient või sisuhaldur vaatab testsaiti telefonist ja jääb autoriseerimisaknasse kinni. Siin sobib paremini Cloudflare Access e-postiga sisselogimisega.
• Väline teenus peab testkeskkonda pääsema ilma paroolita: makselahendus saadab webhooke, monitooring kontrollib kättesaadavust. Siis IP-nimekiri teenuse aadresside erandiga, mitte kaitse eemaldamine.
• Enne avaldamist on vaja kontrollida, kuidas Google lehte renderdab. URL-i kontrollimise tööriist parooliga suletud saidile ei pääse. Selline test tehakse eraldi avatud URL-il noindex-iga, mis kustutatakse kohe pärast testi, ja see on ainus koht, kus metasilt testkeskkonnas on põhjendatud.