Robots.txt nədir və SEO üçün necə istifadə olunur?

Saytda bəzi səhifələrin Googlebot tərəfindən crawl edilməsini istəməyə bilərik. Məsələn, daxili admin bölmələri, sonsuz filter kombinasiyaları və ya axtarış sisteminin crawl resursunu lazımsız istifadə edən müəyyən URL qrupları ola bilər. Bu zaman crawler-lərə hansı URL yollarına daxil olub-olmamaq barədə qayda vermək üçün robots.txt istifadə olunur.

Bəs robots.txt nədir və SEO üçün necə düzgün qurulmalıdır? Robots.txt saytın root hissəsində yerləşən sadə mətn faylıdır və crawler-lərə hansı hissələri crawl etməyə icazə verildiyini və ya verilmədiyini bildirən qaydalar saxlayır. Google Robots Exclusion Protocol qaydalarını oxumaq üçün saytı crawl etməzdən əvvəl robots.txt faylını əldə edib analiz edir.

Ən vacib məqam isə budur: robots.txt indexlənməni idarə edən əsas vasitə deyil. O, əsasən crawling-i idarə edir. Səhifənin Google nəticələrində görünməməsini istəyirsinizsə, uyğun vəziyyətdə noindex kimi başqa mexanizmdən istifadə etmək lazımdır.

Bu səbəbdən robots.txt-i ayrıca bir “SEO trick” kimi yox, Technical SEO strukturunun bir hissəsi kimi düşünmək daha düzgündür. Saytın crawling, indexing, sitemap, canonical və daxili link sistemi birlikdə işləməlidir.

Robots.txt nədir?

Robots.txt crawler-lərin saytın hansı hissələrinə daxil ola biləcəyini müəyyən etmək üçün istifadə olunan plain text fayldır.

Normal ünvan belə olur:

https://example.com/robots.txt

Google-un qaydalarına görə robots.txt saytın top-level, yəni root directory-sində yerləşməlidir. Məsələn:

https://example.com/robots.txt

düzgündür.

Amma:

https://example.com/folder/robots.txt

əsas sayt üçün robots.txt kimi qəbul edilmir.

Sadə robots.txt belə görünə bilər:

User-agent: *
Disallow: /admin/

Sitemap: https://example.com/sitemap.xml

Burada crawler-lərə /admin/ yolunu crawl etməmək bildirilib, eyni zamanda XML sitemap ünvanı göstərilib.

Robots.txt SEO üçün niyə vacibdir?

Robots.txt düzgün qurulduqda crawler-lərin saytın lazımsız hissələrinə vaxt sərf etməsinin qarşısını almağa və vacib URL-lərə daha aydın crawl strukturu yaratmağa kömək edə bilər.

Bu xüsusilə böyük saytlarda vacib ola bilər.

Məsələn e-commerce saytında belə URL-lər minlərlə kombinasiya yarada bilər:

/products?sort=price

/products?sort=name

/products?color=black

/products?color=black&size=42

Əgər bu URL-lərin hamısının crawler tərəfindən gəzməsi real SEO məqsədi daşımırsa, crawl strategiyasını ayrıca planlamaq lazım gələ bilər.

Amma robots.txt-i hər problemi həll edən fayl kimi görmək düzgün deyil. Məsələn, duplicate URL problemi varsa, robots.txt canonical strategiyasının əvəzi deyil.

Ümumi veb sayt optimallaşdırılması prosesində robots.txt crawlability ilə birlikdə qiymətləndirilməlidir; URL strukturu, indexability və canonical qərarları ayrıca nəzərə alınmalıdır.

User-agent nədir?

User-agent qaydanın hansı crawler-ə aid olduğunu göstərir.

Məsələn:

User-agent: *
Disallow: /private/

Buradakı * bütün uyğun crawler-ləri nəzərdə tutur.

Yalnız Googlebot üçün ayrıca qayda yazmaq da mümkündür:

User-agent: Googlebot
Disallow: /test/

Google-un robots.txt spesifikasiyasında user-agent əsas dəstəklənən sahələrdən biridir.

Amma fərqli botlar üçün çox mürəkkəb qaydalar yazmazdan əvvəl buna həqiqətən ehtiyac olub-olmadığını müəyyən etmək lazımdır. Kiçik xidmət və portfolio saytında çox vaxt sadə struktur kifayət edir.

Disallow nədir?

Disallow müəyyən URL yolunun crawler tərəfindən crawl edilməməsini bildirir.

Məsələn:

User-agent: *
Disallow: /admin/

bu qayda /admin/ altında yerləşən yolların crawl edilməməsini bildirir.

Başqa nümunə:

User-agent: *
Disallow: /search/

sayt daxili search URL-lərinin crawl edilməsini məhdudlaşdıra bilər.

Burada path case-sensitive ola bilər. Google-un sənədlərinə görə allow və disallow qaydalarındakı path dəyərləri case-sensitive-dir.

Yəni:

/Admin/

və

/admin/

server strukturundan asılı olaraq eyni yol hesab edilməyə bilər.

Allow nədir?

Allow daha geniş Disallow qaydasının içində müəyyən URL yolunu yenidən crawl üçün açmağa imkan verir.

Məsələn:

User-agent: *
Disallow: /folder/
Allow: /folder/public-page/

Burada ümumi /folder/ bloklanır, amma /folder/public-page/ üçün crawl icazəsi verilir.

Bu xüsusilə mürəkkəb URL strukturlarında faydalıdır.

Amma sadə saytda həddindən artıq Allow və Disallow kombinasiyası yazmaq əlavə səhv riski yarada bilər. Robots.txt mümkün qədər aydın saxlanmalıdır.

Bütün saytı necə bloklamaq olar?

Bu qayda bütün saytı crawler üçün bloklaya bilər:

User-agent: *
Disallow: /

Bu ən təhlükəli robots.txt səhvlərindən biridir.

Development və staging mühitində bu qayda bilərəkdən istifadə oluna bilər. Problem staging konfiqurasiyasının production-a keçməsi zamanı yaranır.

Məsələn development zamanı:

User-agent: *
Disallow: /

istifadə edilib.

Sayt canlıya çıxarılıb, amma robots.txt dəyişdirilməyib.

Bu halda Googlebot bütün əsas URL-lərin crawling-indən bloklana bilər.

Yeni sayt və ya migration sonrası technical QA zamanı robots.txt-in ayrıca yoxlanmasının səbəblərindən biri budur.

Bütün saytı crawl üçün necə açmaq olar?

Əgər xüsusi blok qaydasına ehtiyac yoxdursa, belə sadə robots.txt istifadə etmək mümkündür:

User-agent: *
Disallow:

Boş Disallow path crawler üçün xüsusi blok olmadığını bildirir.

Google-un spesifikasiyasına əsasən path göstərilməyən Disallow qaydası crawl məhdudiyyəti yaratmır.

Saytda robots.txt ümumiyyətlə yoxdursa da Google bunu avtomatik olaraq “bütün sayt bloklanıb” kimi qəbul etmir. Google 404 kimi əksər 4xx cavablarında robots.txt faylı mövcud deyilmiş kimi davranır və crawl restriction olmadığını qəbul edir.

Robots.txt ilə noindex arasında fərq nədir?

Bu, mövzunun ən vacib hissəsidir.

robots.txt crawler-in URL-i crawl etməsini məhdudlaşdıra bilər.

noindex isə Google-a səhifənin search nəticələrinə daxil edilməməsini bildirir.

Məsələn səhifədə:

<meta name="robots" content="noindex">

varsa Google həmin direktivi görə bildiyi halda səhifəni indexdən çıxara bilər.

Amma həmin URL eyni zamanda robots.txt ilə bloklanıbsa Googlebot səhifəyə daxil olub noindex direktivini oxuya bilməyə bilər.

Bu səbəbdən robots.txt ilə indexation idarə etməyə çalışmaq səhv yanaşmadır.

Google öz robots.txt sənədində də bildirir ki, crawl üçün bloklanan URL-in məzmunu indexlənməsə də URL başqa səhifələrdən gələn linklər əsasında search nəticəsində snippetsiz görünə bilər.

Praktik olaraq səhifəni nəticələrdən çıxarmaq istəyirsinizsə “Googlebot ora heç girməsin” və “Google bunu index etməsin” iki fərqli məqsəddir.

Robots.txt-də noindex yazmaq olar?

Etibarlı həll kimi yox.

Bəzən köhnə konfiqurasiyalarda belə bir sətir görünür:

Noindex: /folder/

Amma Google-un dəstəklədiyi robots.txt fields bunlardır:

• user-agent
• allow
• disallow
• sitemap

noindex robots.txt üçün Google tərəfindən dəstəklənən field deyil.

Indexing idarəsi üçün meta robots və ya HTTP X-Robots-Tag kimi uyğun mexanizmlərdən istifadə etmək lazımdır.

Sitemap robots.txt daxilində göstərilə bilərmi?

Bəli.

Məsələn:

User-agent: *
Disallow: /admin/
Sitemap: https://example.com/sitemap.xml

Google, Bing və digər əsas search engine-lər robots.txt daxilində sitemap field-i dəstəkləyir. Sitemap ünvanı fully qualified URL olmalıdır.

Birdən çox sitemap varsa bir neçə sətir istifadə etmək mümkündür:

Sitemap: https://example.com/post-sitemap.xml

Sitemap: https://example.com/product-sitemap.xml

Sitemap: https://example.com/category-sitemap.xml

Sitemap-ın ayrıca necə qurulduğunu technical SEO strukturunda ayrıca qiymətləndirmək lazımdır. Robots.txt sadəcə onun ünvanını göstərmək üçün əlavə yol təqdim edir.

Robots.txt subdomain-lərə də təsir edirmi?

Xeyr, avtomatik olaraq yox.

Məsələn:

https://example.com/robots.txt

qaydaları:

https://example.com/

üçün keçərlidir.

Amma:

https://shop.example.com/

üçün ayrıca:

https://shop.example.com/robots.txt

lazım ola bilər.

Google robots.txt qaydalarının yalnız həmin host, protocol və port üçün keçərli olduğunu bildirir.

Bu detal xüsusilə aşağıdakı strukturlarda vacibdir:

• blog.example.com
• shop.example.com
• app.example.com
• staging.example.com

Hər host öz robots qaydalarını ayrıca tələb edə bilər.

HTTP və HTTPS üçün eyni robots.txt işləyirmi?

Avtomatik olaraq yox.

Google qaydaları protocol səviyyəsində də ayırır.

Məsələn:

https://example.com/robots.txt

HTTPS host üçün keçərlidir, amma ayrıca:

http://example.com/

versiyasına avtomatik tətbiq olunan universal robots faylı deyil.

Normal olaraq sayt artıq HTTPS-ə redirect olunursa bu məsələ idarə olunur, amma migration audit zamanı protocol və host davranışını ayrıca yoxlamaq faydalıdır.

Robots.txt-də CSS və JavaScript bloklamaq düzgündür?

Çox vaxt yox.

Google səhifəni render edərkən CSS və JavaScript resurslarına ehtiyac duya bilər.

Məsələn, saytın əsas CSS və JS fayllarını belə bloklamaq:

User-agent: *
Disallow: /assets/

problem yarada bilər, əgər /assets/ altında Google-un səhifəni normal render etməsi üçün lazım olan CSS və JavaScript faylları yerləşirsə.

Google-un robots.txt nümunəsində də crawler üçün bloklanmış directory daxilində rendering üçün vacib CSS/JS fayllarına Googlebot üçün ayrıca Allow verilməsi nümunəsi göstərilir.

Frontend layihəsində robots.txt düzəlişi edərkən yalnız URL-lərə yox, səhifənin render etdiyi resurslara da baxmaq lazımdır.

Bu səbəbdən sayt hazırlanması prosesində robots.txt development bitdikdən sonra əlavə edilən təsadüfi fayl kimi yox, production QA-nın bir hissəsi olmalıdır.

Crawl-delay istifadə etmək olar?

Googlebot üçün yox.

Bəzi robots.txt fayllarında belə sətir görmək mümkündür:

Crawl-delay: 10

Amma Google robots.txt daxilində crawl-delay field-ini dəstəkləmir. Google-un dəstəklədiyi əsas fields user-agent, allow, disallow və sitemap-dır.

Başqa crawler-lərin crawl-delay davranışı fərqli ola bilər, amma Google crawl rate idarəsini bu robots direktivi ilə etmir.

Ona görə internetdən hazır robots.txt template götürüb daxilindəki hər direktivi Google-un istifadə etdiyini düşünmək düzgün deyil.

Wildcard istifadə etmək olar?

Google robots.txt qaydalarında * wildcard və $ end-of-URL marker kimi pattern matching imkanlarını dəstəkləyir.

Məsələn müəyyən query pattern-i üçün qayda yaradıla bilər:

User-agent: Googlebot
Disallow: /*?sort=

və ya xüsusi extension pattern-i bloklamaq mümkündür.

Amma wildcard qaydaları diqqətlə test edilməlidir. Çox geniş pattern bilmədən vacib URL qruplarını da bloklaya bilər.

Məsələn:

Disallow: /*?

bütün query parametrli URL-lərə təsir edə bilər.

Əgər e-commerce saytında bəzi parameter səhifələri real search landing page kimi lazımdırsa bu qayda problem yarada bilər.

Robots.txt böyük e-commerce saytında necə istifadə olunur?

E-commerce saytında robots.txt daha çox ehtiyat tələb edir, çünki filter, sorting və search URL-ləri çoxlu crawl variantları yarada bilər.

Məsələn:

/products?sort=price

/products?sort=newest

/products?color=black

/products?size=42

/search?q=shoes

Bu URL-lərdən hansılarının search üçün dəyərli olduğunu əvvəlcə müəyyən etmək lazımdır.

Sadəcə:

“parameter var, hamısını robots.txt ilə bağlayaq”

yanaşması təhlükəlidir.

Çünki bəzi filter URL-ləri real organic landing page məqsədi daşıya bilər.

Praktik olaraq əvvəlcə:

1. URL pattern-lər çıxarılır.
2. Hansı URL-lərin indexlənməsi istənilir müəyyən edilir.
3. Canonical strategiyası yoxlanılır.
4. Internal linking və navigation analiz olunur.
5. Yalnız bundan sonra crawl restriction haqqında qərar verilir.

Robots.txt site architecture və faceted navigation qərarının əvəzi deyil.

WordPress-də robots.txt necə işləyir?

WordPress sistemində robots.txt virtual və ya fiziki formada yaradıla bilər. SEO plugin-ləri və hosting konfiqurasiyası da bu fayla təsir edə bilər.

WordPress saytında belə yolların bloklanmasına tez-tez rast gəlinir:

User-agent: * Disallow: /wp-admin/ Allow: /wp-admin/admin-ajax.php

Amma hazır template-i kor-koranə tətbiq etmək lazım deyil.

Xüsusilə yoxlanmalıdır:

• theme resursları bloklanmır?
• plugin resursları render üçün lazımdır?
• sitemap URL doğrudur?
• staging qaydası production-da qalmayıb?
• WordPress Settings → Reading altında search engine visibility ilə bağlı əlavə məhdudiyyət yoxdur?

WordPress-də SEO problemi yalnız robots.txt faylının özündən yox, başqa meta robots və plugin konfiqurasiyalarından da yarana bilər.

React və Next.js layihəsində robots.txt necə hazırlanır?

Custom frontend layihəsində robots.txt statik fayl və ya framework routing vasitəsilə yaradıla bilər.

Məsələn Next.js layihəsində framework versiyasından asılı olaraq metadata/file conventions və ya public fayl yanaşması istifadə oluna bilər.

Burada SEO baxımından əsas məsələ onun hansı texnologiya ilə yaradılması yox, final production URL-də belə əlçatan olmasıdır:

https://example.com/robots.txt

Sonra yoxlanmalıdır:

• HTTP 200 qaytarır?
• Content plain text-dir?
• production qaydaları düzgündür?
• sitemap URL düzgündür?
• vacib route-lar təsadüfən bloklanmayıb?
• CSS/JS asset-ləri bloklanmayıb?

Frontend deployment-dan sonra URL-in özünü yoxlamadan “kodda robots faylı var” demək kifayət deyil.

Staging saytını robots.txt ilə bağlamaq kifayətdirmi?

Tam təhlükəsizlik həlli kimi yox.

Məsələn staging mühitində:

User-agent: *
Disallow: /

istifadə etmək crawler-lərə crawl etməməyi bildirə bilər.

Amma robots.txt access control mexanizmi deyil. Fayl özü public-dir və crawling qaydalarına əməl etmək crawler-dən asılıdır.

Əgər staging həqiqətən public olmamalıdırsa, authentication və ya server səviyyəli access control daha sağlam yanaşmadır.

Həmçinin staging-dən production-a keçərkən Disallow: / qaydasının silindiyini ayrıca yoxlamaq lazımdır.

Robots.txt faylı 404 qaytarırsa nə olur?

Google-un hazırkı sənədlərinə əsasən robots.txt sorğusu 4xx cavabı qaytarırsa, 429 istisna olmaqla Google adətən robots.txt mövcud deyilmiş kimi davranır və crawl restrictions olmadığını qəbul edir.

Bu o demək deyil ki, robots.txt-in 404 olması ideal konfiqurasiyadır.

Sayt crawl qaydaları və sitemap location göstərmək istəyirsə işlək robots.txt faylı saxlamaq daha aydındır.

Amma audit zamanı:

“robots.txt 404 qaytarır, deməli Google bütün saytı crawl edə bilmir”

nəticəsi yanlışdır.

Əksinə, problem 5xx olduqda davranış daha fərqli ola bilər.

Robots.txt 5xx qaytarırsa nə baş verir?

Bu daha ciddi məsələdir.

Google sənədlərinə görə robots.txt server error ilə əlçatan deyilsə, ilk mərhələdə Google crawling-i dayandıra və faylı yenidən əldə etməyə çalışa bilər. Daha sonra əvvəlki işlək cached version varsa müəyyən müddət ondan istifadə edilə bilər.

Ona görə robots.txt sadə text fayl olsa da server tərəfdə etibarlı şəkildə əlçatan olmalıdır.

Audit zamanı robots URL-in status code-u ayrıca yoxlanmalıdır.

Robots.txt nə qədər tez yenilənir?

Google robots.txt faylını adətən cache edir. Rəsmi sənədlərə görə Google robots.txt content-ini ümumiyyətlə 24 saata qədər cache edə bilər, bəzi hallarda isə daha uzun qala bilər.

Bu səbəbdən robots.txt dəyişdirdikdən sonra bütün crawling davranışının həmin saniyə dəyişməsini gözləmək lazım deyil.

Dəyişiklik kritikdirsə:

• robots URL-in real content-i yoxlanılır;
• server cache/CDN yoxlanılır;
• Google-un sonrakı crawl davranışı izlənilir.

Cloudflare və digər CDN sistemlərində də köhnə robots.txt cache-də qalmaması ayrıca nəzərə alınmalıdır.

Robots.txt ölçü limiti varmı?

Google robots.txt üçün 500 KiB file size limiti tətbiq edir. Bu ölçüdən sonrakı content ignore edilir.

Praktik olaraq normal saytın robots.txt faylı bu ölçüyə yaxınlaşmamalıdır.

Əgər faylda minlərlə ayrı Disallow rule varsa, bu çox vaxt URL strukturunun özündə daha fundamental problem olduğuna işarə edir.

Mürəkkəb pattern-lər konsolidasiya edilməli və crawl strategiyası yenidən qiymətləndirilməlidir.

Robots.txt necə test edilir?

Robots.txt test edərkən sadəcə faylı browser-də açmaq kifayət deyil.

Praktik checklist:

1. https://domain.com/robots.txt açılır?
2. HTTP status 200-dür?
3. Fayl həqiqətən plain text qaytarır?
4. User-agent qrupları düzgündür?
5. Vacib page və asset-lər bloklanmayıb?
6. Sitemap URL düzgündür?
7. Host və protocol uyğun gəlir?
8. Wildcard qaydaları gözlənildiyi kimi işləyir?
9. Staging qaydaları production-da qalmayıb?
10. Site crawl nəticələri robots qaydaları ilə müqayisə olunub?

Screaming Frog kimi crawler vasitələri robots.txt qaydalarına görə bloklanan URL-ləri görmək üçün də faydalıdır.

Google Search Console robots.txt üçün necə kömək edir?

Search Console və URL Inspection konkret URL-in Google üçün əlçatanlığını yoxlamaqda əlavə kontekst verə bilər.

Məsələn vacib URL crawl edilmir və ya index problemi yaşayırsa, yoxlanmalı səbəblərdən biri robots.txt-dir.

Amma Search Console-dakı hər “blocked” vəziyyəti avtomatik robots.txt səhvi deyil. Page-level meta robots, authentication, server və digər problemlər də ayrıca araşdırılmalıdır.

Əsas yanaşma budur:

statusu gör → səbəbi müəyyən et → yalnız sonra qaydanı dəyiş.

Təsadüfi robots.txt düzəlişləri xüsusilə böyük saytda ciddi nəticələr verə bilər.

Robots.txt audit necə edilir?

SEO audit zamanı robots.txt üçün belə ardıcıllıq istifadə etmək olar:

1. Faylın əlçatanlığını yoxlayın

Root URL-də açılır:

/robots.txt

və 200 status qaytarır?

2. User-agent qruplarını yoxlayın

Qaydalar bütün botlara aiddir, yoxsa müəyyən crawler-ə?

3. Disallow qaydalarını çıxarın

Hansı yollar bloklanıb?

4. Vacib URL-ləri test edin

Service, product, category və blog page-lər təsadüfən bloklanmayıb?

5. CSS və JavaScript resurslarına baxın

Render üçün vacib asset-lər crawl edilə bilirmi?

6. Sitemap URL-i yoxlayın

Sitemap field-də URL düzgün və canlıdır?

7. noindex strategiyası ilə qarışdırılmayıb?

Indexdən çıxarmaq istənilən URL-lər sadəcə robots.txt ilə bloklanıb?

8. Crawl nəticələri ilə müqayisə edin

Blocked by robots.txt URL-lər həqiqətən bloklanmalı olan səhifələrdir?

9. Production/staging konfiqurasiyasını yoxlayın

Environment qaydaları qarışmayıb?

Bu auditin məqsədi robots.txt-də mümkün qədər çox rule yazmaq deyil. Əksinə, lazım olmayan qaydaları azaltmaq da yaxşı nəticə ola bilər.

Robots.txt-də ən çox edilən səhvlər

Production-da Disallow: / saxlamaq

Ən təhlükəli səhvlərdən biridir. Development və staging qaydası canlı sayta keçə bilər.

Robots.txt ilə deindex etməyə çalışmaq

Crawling və indexing fərqli anlayışlardır. Google bloklanan URL-i başqa linklər əsasında yenə tanıya bilər.

CSS və JS fayllarını bloklamaq

Google səhifəni normal render edə bilməyə bilər.

Sitemap URL-i səhv yazmaq

Köhnə HTTP, staging və ya artıq mövcud olmayan sitemap ünvanı qala bilər.

Subdomain üçün əsas domen robots.txt-inə güvənmək

Hər host üçün qaydaların scope-u ayrıca nəzərə alınmalıdır.

crawl-delay-i Google qaydası hesab etmək

Google bu field-i robots.txt daxilində dəstəkləmir.

Hazır template-i analiz etmədən kopyalamaq

Başqa sayta uyğun Disallow pattern-i sizin vacib URL-ləri bloklaya bilər.

Query parameter-lərin hamısını bloklamaq

Bəzi parameter və faceted URL-lər real SEO landing page ola bilər.

Praktik robots.txt nümunəsi

Sadə xidmət saytı üçün belə minimal struktur kifayət edə bilər:

User-agent: *
Disallow: /admin/
Disallow: /login/
Sitemap: https://example.com/sitemap.xml

WordPress tipli başqa nümunə:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://example.com/sitemap_index.xml

Amma bu nümunələri birbaşa öz saytınıza kopyalamaq lazım deyil.

Məsələn:

• /login/ səhifəniz yoxdur;
• sitemap URL fərqlidir;
• admin route fərqlidir;
• saytın bəzi xüsusi crawling ehtiyacları var.

Robots.txt site-specific olmalıdır.

Yeni sayt yayımlananda robots.txt checklist

Yeni sayt production-a çıxarılanda aşağıdakıları yoxlamaq faydalıdır:

• /robots.txt canlıdır;
• HTTP 200 qaytarır;
• Disallow: / yoxdur;
• əsas service və content URL-lər crawl üçün açıqdır;
• CSS və JS resursları bloklanmır;
• sitemap URL düzgündür;
• sitemap özü canlıdır;
• staging domain qaydaları qalmayıb;
• yanlış subdomain və HTTP URL-lər yoxdur;
• vacib səhifələrdə ayrıca noindex səhvi yoxdur.

Bu checklist SEO-friendly sayt hazırlanması prosesinin deployment və QA hissəsinə daxil edilməlidir.

Robots.txt və real SEO işi

Robots.txt yalnız nəzəri technical SEO elementi deyil. Saytın development və SEO tərəfi bir yerdə işlədikdə bu fayl deployment prosesinin bir hissəsinə çevrilir.

EmilGasarayev.com-un SEO və frontend yanaşmasında robots.txt crawlability, indexation, sitemap, Core Web Vitals və digər technical SEO elementləri ilə birlikdə iş istiqamətlərindən biri kimi göstərilir.

Bu yanaşma vacibdir, çünki robots.txt-də problem SEO report-da müəyyən edilə bilər, amma həll bəzən:

• server;
• WordPress;
• Next.js;
• deployment;
• CDN;
• environment configuration

səviyyəsində edilir.

Yəni “robots problemi var” diaqnozu ilə “problemi production-da düzgün düzəltmək” eyni mərhələ deyil.

Nəticə

Robots.txt nədir sualına qısa cavab versək, robots.txt axtarış sistemi crawler-lərinə saytın hansı URL yollarını crawl edib-etməmələri barədə qaydalar təqdim edən root-level mətn faylıdır.

Əsas direktivlər:

• User-agent
• Disallow
• Allow
• Sitemap

olaraq istifadə olunur.

Robots.txt-in ən vacib məqamı isə onun crawl control vasitəsi olmasıdır, index control vasitəsi yox. Səhifəni Google nəticələrindən çıxarmaq üçün robots.txt əvəzinə uyğun noindex mexanizmi lazım ola bilər.

Yaxşı robots.txt mümkün qədər sadə olmalı, vacib səhifə və resursları təsadüfən bloklamamalı, sitemap-a düzgün keçid verməli və saytın real texniki strukturuna uyğun qurulmalıdır.

Əgər saytınızda crawling və indexation problemi varsa, yalnız robots.txt-ə baxmaqla kifayətlənmək düzgün deyil. Canonical, sitemap, internal linking, meta robots, HTTP status və render vəziyyətini birlikdə analiz etmək daha sağlam yanaşmadır.

Xarici mənbə/link

• Google — How Google Interprets robots.txt —  Google robots.txt spesifikasiyası
• Google Search Central sənədləri —  Google Search Central