Saytda katta o'zgarish qilishdan oldin uni alohida nusxada sinab ko'rish yaxshi odat. Ko'pincha buning uchun test.example.uz yoki staging.example.uz kabi subdomen ochiladi va unga asosiy saytning to'liq nusxasi qo'yiladi. Muammo shundaki, qidiruv tizimlari bu subdomenni ham topadi: unga bitta havola, sitemap fayli yoki brauzer kengaytmasi orqali yuborilgan manzil kifoya. Natijada Google'da bir xil matnli ikki sayt paydo bo'ladi, ba'zan esa mijoz qidiruvdan tugallanmagan test sahifasiga kirib, eski narxlar yoki "lorem ipsum" matnini ko'radi.
Nega robots.txt yetarli emas
Ko'pchilik birinchi bo'lib robots.txt fayliga Disallow: / yozadi. Bu qoida qidiruv robotiga sahifalarni o'qimaslikni aytadi, lekin ularni indeksga qo'shmaslikni kafolatlamaydi. Agar boshqa joyda test subdomeniga havola bo'lsa, Google manzilni mazmunsiz holda indeksga qo'shishi mumkin va natijalarda "Bu sahifa haqida ma'lumot mavjud emas" degan yozuv bilan chiqadi. Bundan ham muhimi, robot sahifani o'qiy olmagani uchun undagi noindex belgisini ham ko'rmaydi, ya'ni ikki usulni birga qo'llash bir-biriga xalaqit beradi.
Shuning uchun staging uchun ishonchli yondashuv ikki qatlamdan iborat: robotga sahifani o'qishga ruxsat beriladi, lekin har bir javobda "indekslama" degan belgi yuboriladi yoki, undan ham yaxshisi, sayt parol bilan yopiladi.
Birinchi usul: X-Robots-Tag sarlavhasi
X-Robots-Tag HTTP sarlavhasi meta tegning server darajasidagi muqobili hisoblanadi. Uning afzalligi shundaki, u HTML sahifalarga ham, PDF, rasm va boshqa fayllarga ham ishlaydi, shablonni tahrirlash esa talab qilinmaydi. Apache'da bu mod_headers moduli orqali staging papkasidagi .htaccess ga yoziladi, Nginx'da esa subdomenning server blokiga qo'shiladi.
# .htaccess (faqat staging papkasida!)
<IfModule mod_headers.c>
Header set X-Robots-Tag "noindex, nofollow"
</IfModule>
# Nginx: staging.example.uz server bloki
add_header X-Robots-Tag "noindex, nofollow" always;Sozlama ishlayotganini curl -I buyrug'i bilan tekshirasiz: javob sarlavhalari orasida X-Robots-Tag: noindex, nofollow qatori bo'lishi kerak. Bu qatorni asosiy domenning javobida ham tekshirib ko'ring, chunki noto'g'ri papkaga yozilgan qoida asosiy saytni qidiruvdan chiqarib yuborishi mumkin.
curl -sI https://staging.example.uz | grep -i x-robots
curl -sI https://example.uz | grep -i x-robots # bo'sh bo'lishi kerakIkkinchi usul: parol bilan himoya
Eng ishonchli yechim staging'ni parol bilan yopishdir. HTTP Basic Auth yoqilganda robot sahifa o'rniga 401 javobini oladi va hech narsani indekslay olmaydi, begona odamlar ham tugallanmagan sahifalarni ko'rmaydi. Parol fayli htpasswd yordamchi dasturi bilan yaratiladi va uni sayt papkasidan tashqarida saqlash tavsiya etiladi.
htpasswd -c /home/user/.htpasswd_staging tester
# .htaccess (Apache)
AuthType Basic
AuthName "Staging"
AuthUserFile /home/user/.htpasswd_staging
Require valid-user
# Nginx
auth_basic "Staging";
auth_basic_user_file /etc/nginx/.htpasswd_staging;
location /.well-known/acme-challenge/ { auth_basic off; }Oxirgi qatorga e'tibor bering: Let's Encrypt sertifikati HTTP orqali tekshirilganda tekshiruv serveri parolni bilmaydi, shuning uchun .well-known yo'li parolsiz qolishi kerak, aks holda SSL yangilanmay qolishi mumkin. Agar staging to'lov tizimi yoki tashqi API'dan qaytuvchi so'rovlarni (webhook) qabul qilishi kerak bo'lsa, ular uchun ham alohida istisno qilish lozim bo'ladi.
WordPress va boshqa CMS sozlamalari
WordPress'da "Sozlamalar → O'qish" bo'limida qidiruv tizimlariga saytni indekslamaslikni so'raydigan belgi bor. U sahifalarga noindex meta tegini qo'shadi va staging uchun qo'shimcha qatlam sifatida foydali. Lekin bu belgi faqat WordPress yaratgan sahifalarga ta'sir qiladi va ma'lumotlar bazasida saqlanadi, shuning uchun bazani staging'dan asosiy saytga ko'chirganda u ham birga ko'chadi. Ko'p jamoalar aynan shu sababli ishga tushirilgandan keyin bir necha hafta qidiruvdan g'oyib bo'lgan saytni qidiradi.
Allaqachon indeksga tushgan bo'lsa
Agar test subdomen Google natijalarida ko'rinib qolgan bo'lsa, avval yuqoridagi usullardan birini qo'llang, keyin Google Search Console'da subdomenni alohida resurs sifatida tasdiqlang. "Olib tashlash" (Removals) vositasi sahifalarni natijalardan vaqtincha yashiradi, doimiy natija esa robot sahifalarni qayta ko'rib, noindex yoki 401 javobini olgach keladi. Subdomenni tasdiqlash uchun DNS'ga TXT yozuv qo'shish kerak bo'ladi, buni sayt.uz kabinetidagi domen DNS bo'limidan qilish mumkin.
Misol: Namangandagi maktab sayti
Namangandagi xususiy maktab yangi dizaynni yangi.misol.uz subdomenida ikki oy davomida tayyorladi. Shu vaqt ichida o'qituvchilardan biri havolani ota-onalar guruhiga yubordi va bir necha haftadan keyin "qabul" so'zi bo'yicha qidiruvda asosiy sayt o'rniga test nusxasi chiqa boshladi. Dasturchi subdomenga parol qo'ydi, Search Console orqali test manzillarini vaqtincha olib tashladi va ishga tushirish kuni bazani ko'chirgach, asosiy saytda X-Robots-Tag yoki noindex yo'qligini curl bilan tekshirdi.
Ishga tushirish oldidan nazorat ro'yxati
- Asosiy domen javobida
X-Robots-Tagsarlavhasi yo'qligini tekshiring. - Sahifa kodida
<meta name="robots" content="noindex">qolmaganiga ishonch hosil qiling. - WordPress'da "indekslamaslik" belgisini o'chiring.
robots.txtda staging'dan qolganDisallow: /qatori yo'qligini ko'ring.- Kanonik havolalar (
rel="canonical") va sitemap ichida staging manzillari qolmaganini tekshiring.