Yeddi dilə tərcümə edilmiş bir agentlik saytının tipik hekayəsi belədir: əsas dildə birtəhər iş görür, ingilis dilində güc-bəla ilə, qalan beş dildə demək olar ki, heç. Komanda əvvəlcə məzmunu günahlandırır, tərcüməni yeniləyir, bir neçə yazı da əlavə edir. Rəqəm tərpənmir. Çünki problem çox vaxt yazdığınız mətndə deyil, o mətnin axtarış sisteminə neçə ayrı ünvandan, hansı status kodu ilə və hansı dil etiketi ilə təqdim edilməsindədir.
Bu yazı yeddidilli bir səyahət proqram təminatı saytında başdan-başa apardığımız texniki auditin nəticələrini bələdçiyə çevirir. Rəqəmlərin hamısı ya həmin auditdən, ya da mənbəyi göstərilmiş xarici araşdırmalardan gəlir; heç biri təxmin deyil. Audit 1.088 canlı səhifəni, 1.469 sayt xəritəsi ünvanını və yeddi dilin hamısını əhatə etdi və ortaya çıxan mənzərə belə oldu: səhifələrin 85%-ində kanonik ünvan etiketi ümumiyyətlə yox idi, sayt iki ayrı host üzərindən tamamilə dublikat olunurdu, altı dildə elan edilən tərcümələr isə əslində "səhifə tapılmadı" mesajı qaytarırdı.
Aşağıdakı bölmələrin hər biri, heç bir proqram təminatı almasanız belə öz saytınızda bir brauzer və curl ilə tətbiq edə biləcəyiniz bir yoxlama, bir hədd və ya bir qərar qaydası verir. Sıra da vacibdir: texniki təmizlik aparılmadan məzmun dərinliyi işləmir, məzmun dərinliyi olmadan süni intellekt görünürlüyü işləmir.
Audit sırası: əvvəlcə tək həqiqət mənbəyi (kanonik ünvan, qarşılıqlı hreflang, dürüst status kodu), sonra məzmun, ən sonda süni intellekt görünürlüyü.
1. Əvvəlcə sayın: eyni səhifəyə neçə ünvandan çatmaq olur?
Auditə məzmundan yox, ünvan sayımından başlayın. Bir səhifənin neçə fərqli ünvandan açıla bildiyini ölçmək on dəqiqə çəkir və adətən ən böyük itkini elə ilk turda üzə çıxarır.
Ölçdüyümüz saytda iki əsas nasazlıq var idi. Birincisi: domenin www-lu və www-suz halı hər ikisi 200 qaytarırdı, yəni saytın hamısı iki dəfə əlçatan vəziyyətdə idi. İkincisi: köhnə və yeni yol adları birlikdə açıq buraxıldığı üçün /az/portfolio ilə /az/referanslar eyni məzmunu verirdi; təkcə bu şablon təxminən 1.713 kölgə ünvan yaradırdı.
Öz saytınızda aşağıdakı beş variantı ardıcıl olaraq sorğulayın və qayıdan status kodunu yazın:
| Variant | Nümunə | Gözlənilən nəticə |
|---|---|---|
| www-suz host | numune.com/az/blog |
301 → www-lu hal |
| www-lu host | www.numune.com/az/blog |
200 |
| Sonda kəsik xətt | www.numune.com/az/blog/ |
301 → xəttsiz hal |
| İzləmə parametri | www.numune.com/az/blog?utm=x |
200 + parametrsiz kanonik etiket |
| Köhnə yol adı | www.numune.com/az/yazilar |
301 → yeni yol |
Əmr sətrində tək sətirlə baxa bilərsiniz:
curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" -I <ünvan>
Beşdən ikisi və daha çoxu 200 qaytarırsa, axtarış sistemi sizin bir səhifənizin olduğunu deyil, bir-birinin surəti olan bir neçə səhifənizin olduğunu görür. Bu cəza məsələsi deyil; siqnalın bölünməsi məsələsidir. Eyni məzmuna gələn keçidlər, kliklər və tarama büdcəsi bir neçə ünvana yayılır.
Beş variantın hamısı 200 qaytarırsa siqnal beşə bölünür. Həll sırası: köhnə yollar 301 ilə birləşir, qalanlar özünə istinad edən canonical etiketi ilə toplanır.
Qərar qaydası
Bir səhifə üçün tam olaraq bir kanonik forma müəyyən edin və üç şeyi ona sabitləyin: host (www-lu və ya www-suz, ikisindən biri), sondakı kəsik xətt siyasəti (həmişə var və ya heç yox) və böyük/kiçik hərf. Bu üç qərar yazıya alınmadıqca hər yeni səhifə şablonu öz variantını yaradacaq.
2. Canonical əmr deyil, siqnaldır
Auditdəki ən çarpıcı rəqəm bu idi: 200 qaytaran 1.088 səhifənin 921-ində (85%) canonical etiketi ümumiyyətlə yox idi. Etiketi olan 167 səhifənin 60-ında isə etiket özünü göstərmirdi — səhifə www.numune.com/az ünvanından təqdim edilir, canonical olaraq isə https://numune.com/az/ yazılırdı. Yəni nə host, nə də kəsik xətt uyğun gəlirdi.
Bu məqamda iki texniki həqiqəti bilmək lazımdır. Google-ın öz sənədləşməsi rel="canonical" etiketini direktiv deyil, "göstərilən ünvanın kanonik olması lazım gəldiyinə dair güclü siqnal" kimi tərif edir; son qərarı axtarış sistemi verir. Eyni sənədləşmə kanonikləşdirmə üsullarını gücdən zəifə doğru sıralayır: yönləndirmə > canonical etiketi > sayt xəritəsində yer alma. Sayt xəritəsi açıq şəkildə "zəif siqnal" kimi keçir.
Bunun praktik nəticəsi budur: canonical etiketi tək başına təmizlik aləti deyil. Köhnə bir ünvanı bağlamaq istəyirsinizsə yönləndirmə istifadə edin; canonical-ı yalnız yönləndirilə bilməyən variantlar (parametrli hallar, filtr kombinasiyaları) üçün saxlayın.
İkinci həqiqət: Google kanonik səhifənin özünə istinad edən bir canonical daşımasını tövsiyə edir. Yəni "canonical yalnız surət səhifələrə yazılır" fərziyyəsi yanlışdır; əsas səhifə də özünü göstərməlidir.
Nədən əllə yazılan canonical qaçılmaz şəkildə pozulur
Audit etdiyimiz saytda canonical on ayrı səhifə şablonunda əllə yazılmışdı: birində kəsik xətlə, birində www-suz, birində artıq mövcud olmayan bir yol hissəsi ilə. On dörd şablonda isə heç yox idi. Bu diqqətsizlik deyil, struktur nəticədir: hər yeni səhifə şablonunu yazan adam qaydanı yenidən yadına salmalı olursa, qayda gec-tez unudulur.
Tətbiq oluna bilən qayda: canonical, hreflang və og:url üçlüsü səhifə şablonlarında yox, tək bir ortaq yerdə yaradılsın və səhifə başına yalnız bir dəfə basılsın. Bir səhifə öz canonical-ını yazmağa cəhd edərsə, yayım prosesi buna imkan verməməlidir. Auditdən sonra qurulan strukturda bu qayda bir yığma (build) yoxlamasına bağlandı; "intizamla" deyil, "quruluşla" təmin edildi.
3. hreflang: qarşılığı olmayan dili elan etməyin bədəli
Çoxdilli saytların ən bahalı səhvi buradadır. Audit etdiyimiz saytda bir Azərbaycan dilində bloq yazısı ingilis dilindəki qarşılığı olaraq bir ünvan elan edirdi. Həmin ünvan HTTP 200 qaytarırdı — amma gövdəsində "Blog Post Not Found" yazılırdı. Eyni şablon altı dildə təkrarlanırdı. Yəni sayt axtarış sisteminə öz əli ilə yüzlərlə boş səhifə bildirirdi.
Google-ın beynəlxalq versiyalar sənədləşməsi bu mövzuda dəqiqdir: "Əgər X səhifəsi Y səhifəsinə keçid verirsə, Y səhifəsi də X-ə geri keçid verməlidir. hreflang istifadə edən bütün səhifələr üçün bu belə deyilsə, bu qeydlər nəzərə alınmaya və ya düzgün şərh olunmaya bilər." Eyni sənəd daha qəti bir cümlə də qurur: "İki səhifə bir-birini göstərmirsə, etiketlər nəzərə alınmır."
Buradan çıxan üç qayda var:
| Vəziyyət | Doğru davranış | Yanlış davranış |
|---|---|---|
| Tərcümə var, yayımdadır | Qarşılıqlı hreflang yaz | Birtərəfli elan |
| Tərcümə yoxdur | Heç hreflang yazma | Eyni slug-ı o dilə də yaz |
| Tərcümə var, qaralamadır | Yayıma verilənə qədər yazma | "Necə olsa tezliklə" deyə yaz |
Solda: birtərəfli elan edilən dil, 200 qaytaran, lakin məzmunu olmayan bir ünvana işarə edir. Sağda: yalnız həqiqi tərcüməsi olan dillər qarşılıqlı elan edilir, alman dili sətri ümumiyyətlə yazılmır.
Google-ın saydığı digər iki geniş yayılmış səhv də diqqət tələb edir: dil kodlarının ISO 639-1 hüdudlarından çıxması və region kodu olaraq EU, UK, UN kimi rəsmi olmayan dəyərlərin istifadəsi. Region kodu ISO 3166-1 Alpha 2 olmalıdır və təkbaşına region göstərmək etibarlı deyil — hreflang="AZ" yazılmaz, hreflang="az" və ya hreflang="az-AZ" yazılır.
x-default isə dil seçimi mümkün olmayan istifadəçilər üçün ehtiyat ünvan təyin edir. Çoxdilli agentlik saytında ən məntiqli seçim beynəlxalq satış aparılan dilin (əksərən ingilis dilinin) ana səhifəsi, ya da varsa dil seçim ekranıdır.
4. Soft 404: "tapılmadı" yazıb 200 qaytarmaq
Soft 404, Google-ın tərifi ilə, məzmunun bir səhv mesajı və ya boş səhifə olmasına baxmayaraq serverin 2xx uğur kodu qaytarmasıdır. Aşkarlanması ən çətin nasazlıqdır, çünki heç bir monitorinq aləti həyəcan siqnalı vermir: səhifə "işləyir" görünür, insanlar isə onsuz da o ünvana getmir.
Audit etdiyimiz saytda mövcud olmayan məzmunlar 200 + "tapılmadı" qaytarırdı. Bunları dürüst 404-ə çevirdiyimizdə, əvvəllər tamamilə gizli qalmış üç nasazlıq eyni anda göründü:
| Ortaya çıxan nasazlıq | Təsirlənən ünvan |
|---|---|
| Faiz-kodlu yollar heç açılmırdı | 23 |
| Sayt xəritəsində qarşılığı olmayan kateqoriya səhifələri | 33 |
| Bazadakı sluglar məhsul tərifi ilə uyğun gəlmirdi | 10 |
Ən dramatik nəticə bu idi: ərəb dilindəki məhsul səhifələri yayıma girdiklərindən bəri heç bir real müştəri üçün işləməmişdi. Xam UTF-8 ilə sorğulandıqda 200 qaytarır, brauzerin əslində göndərdiyi faiz-kodlu halı ilə isə 404 qaytarırdılar. Soft 404 olduğu üçün heç kim fərq etməmişdi; komanda ərəb dilindəki səhifələrin "yayımda" olduğunu düşünürdü.
Qərar qaydası
Dürüst 404-ə keçməkdən qorxmayın. Qısa müddətdə səhv sayınız artacaq — bu pisləşmə deyil, ölçmənin dürüstləşməsidir. Qalıcı olaraq geri qayıtmayacaq ünvanlar üçün 410 daha da dəqiqdir; amma hansı ünvanın geri qayıtmayacağı bir məzmun qərarıdır, əvvəlcə onu verin.
5. Latın əlifbası xaricində URL: faiz-kodlama tələsi
Ərəb, rus və Azərbaycan dilinə xas hərflər (ə, ı, ğ, ş, ç, ö, ü) daxil olan yollar brauzer tərəfindən faizlə kodlanaraq göndərilir. Google-ın ünvan quruluşu sənədləşməsi bunu açıq şəkildə tövsiyə edir: "ASCII aralığından kənar simvollar faizlə kodlanmalıdır." Eyni sənəd hədəf auditoriyanın dilindəki sözlərin (və lazım gələrsə hərf transliterasiyasının) ünvanda istifadəsini də dəstəkləyir.
Problem ondadır ki, server tərəfi bu kodlamanı açmırsa, həmin dilin hamısı səssizcə ölür. Öz yoxlamanız üçün eyni ünvanı iki formada sorğulayın:
- Xam halı:
/az/blog/<azərbaycanca-slug> - Faiz-kodlu halı:
/az/blog/%C9%99...
İkisi də eyni status kodunu qaytarmırsa nasazlığınız var deməkdir. Yoxlanacaq dillərin sayı azdır, amma təsiri bütöv bir bazarı əhatə edir.
Tətbiq oluna bilən siyasət: latın olmayan və ya ASCII-dən kənar hərfli dillər üçün üç seçimdən birini şüurlu şəkildə seçin və yeddi dildə eyni cür tətbiq edin — (a) hədəf dilin öz əlifbası (faiz-kodlamanın işlədiyi təsdiqlənibsə), (b) hərf transliterasiyası (rus dili üçün budushcheye-..., Azərbaycan dili üçün gelecek-... kimi ASCII-yə endirilmiş forma), (c) ingiliscə slug + dil şəkilçisi. Yanlış olan seçim yoxdur; yanlış olan dildən-dilə fərqli davranmaqdır.
Bundan başqa Google söz ayırıcısı olaraq alt xətt yerinə tireni tövsiyə edir: "Ünvanlarınızda sözləri ayırmaq üçün alt xətt (_) yerinə tire (-) istifadə etməyinizi tövsiyə edirik." Səbəbi alt xəttin proqramlaşdırmada bir-birinə bağlı anlayışları göstərmək üçün istifadə edilməsidir.
6. Sayt xəritəsi siyahı deyil, öhdəlikdir
Sayt xəritəsinə qoyduğunuz hər ünvan üçün "bu real, indeksləşdirilməyə dəyər bir səhifədir" demiş olursunuz. Audit etdiyimiz saytda sayt xəritəsi 1.469 ünvan elan edirdi; təmizlikdən sonra 1.386-ya endi. Ayıqlananlar bunlar idi:
- 28 ünvan HTML deyil, xam məlumat (JSON) qaytarırdı — bir proqram interfeysi ucu səhifə kimi elan edilmişdi.
- 21 ünvan ümumiyyətlə render oluna bilmirdi.
- 33 ünvan qarşılığı olmayan kateqoriya səhifələri idi; gövdələri 21-25 söz idi və hamısı eyni "yüklənə bilmədi" şablonunu basırdı.
Bundan əlavə 1.469 ünvanın hamısı yanlış host ilə (www-suz) yayımlanırdı; yəni sayt xəritəsi saytın öz kanonik qərarına zidd bir siyahı elan edirdi.
İkinci səssiz səhv lastmod sahəsində idi: hər sorğuda "bu gün" dəyərini yaradırdı. Bu, sahəni tamamilə mənasız edir. lastmod həmin məzmunun real son yenilənmə tarixindən qidalanmalıdır; əks halda axtarış robotu bu siqnalı nəzərə almağı dayandırır.
Sayt xəritəsi yoxlama siyahısı
- Sayt xəritəsindəki host saytın kanonik hostu ilə birə-bir eynidirmi?
- Təsadüfi 10 ünvanı çəkin — hamısı 200 və
Content-Type: text/htmlqaytarırmı? - Sondakı kəsik xətt siyasəti sayt xəritəsində də tətbiq olunubmu?
lastmoddəyərləri bir-birindən fərqlidirmi, yoxsa hamısı eyni gündür?- Tərcüməsi olmayan dillər sayt xəritəsinə heç girmirmi?
noindexverilən səhifələr sayt xəritəsindən çıxarılıbmı?
7. robots.txt-in səssiz səhvi: qrup qaydası
Bu, auditdə tapdığımız ən ucuz, amma ən bahalı səhvlərdən biri idi: faylda bir Disallow sətri var idi, düzgün yazılmışdı, amma yanlış qrupa yazıldığı üçün Googlebot üçün tamamilə təsirsiz idi.
Səbəbi robots.txt-in RFC 9309 ilə standartlaşmış qrup məntiqidir. Standart bunu deyir: bir axtarış robotu öz məhsul tokeninə (product token) uyğun qrupu tapır və həmin qrupun qaydalarına tabe olur. Joker * qrupu yalnız uyğun gələn qrup yoxdursa işə düşür. Yəni:
Belə bir fayl təsəvvür edin:
| Qrup | İçindəki qaydalar |
|---|---|
User-agent: Googlebot |
Disallow: /axtar |
User-agent: * |
Disallow: /axtar və Disallow: /sebet |
Bu faylda Googlebot /sebet yolunu tarayabilər, çünki öz qrupunda o sətir yoxdur və joker qrupu ilə birləşdirmə aparılmır. Qayda sadədir: bir qaydanın etibarlı olmasını istəyirsinizsə, həmin qaydanı hər User-agent qrupunda ayrıca təkrarlayın.
Yoxlamanı əllə etmək əvəzinə faylınızı köçürüb Search Console-dakı robots.txt hesabatında hədəf yolu test edin. Gözlədiyinizlə nəticənin uyğun gəlmədiyi ilk sətir çox güman ki, məhz bu qruplaşdırma səhvidir.
8. CDN keşi: bir ziyarətçinin dili hamıya təqdim olunur
Auditdə ortaya çıxan ən qəribə davranış bu idi. Kök ünvan ziyarətçinin brauzer dilinə görə dəyişən bir 302 yönləndirməsi yaradırdı. Aralıq qat bu cavabı Vary başlığı göndərmədən bir saat boyunca keşdə saxlayırdı. Nəticə: həmin bir saat ərzində sayta ilk daxil olan adamın dili sonrakı hər kəsə təqdim edilirdi. Alman brauzeri ilə gələn korporativ müştəri türkcə sayta düşürdü və bunun səbəbini heç kim anlaya bilmirdi.
Vary başlığının funksiyası məhz budur: keşə, saxlanan cavabın hansı sorğu başlıqlarından asılı olduğunu bildirir. MDN-in tərifi ilə, Vary başlığının olması "cavabların Vary sahəsində sadalanan başlıqlara görə ayrı-ayrı keşlənməsini təmin edir". Başlıq göndərilmirsə, keş eyni ünvana gələn bütün sorğuları eyni sayır və dil, kuki və ya cihaz fərqinə baxmadan eyni cavabı verir.
Cavab dilə görə dəyişir, amma keş açarı yalnız ünvandır. İlk ziyarətçinin dili bir saat boyunca hamının dili olur.
İki həlldən birini seçin:
A — Cavabı ayırın. Dilə görə dəyişən hər cavaba Vary: Accept-Language əlavə edin. Keş dil başına ayrı qeyd saxlayar. Qiyməti: keş vurma nisbəti düşür.
B — Cavabı sabitləyin (üstünlük verilən). Kök ünvan dilə baxmadan tək bir qalıcı yönləndirmə etsin (məsələn, / → 301 → /az), dil seçimi səhifə daxilində həll olunsun. Beləliklə həm keş səmərəli qalır, həm də axtarış sistemi tək bir davranış görür.
İkinci qayda: ölçməni keş təmizləmədən etməyin
Bir CDN, HTML cavablarını iyirmi dörd saatadək saxlaya bilər. Yayıma verdiyiniz düzəlişi dərhal ölçsəniz köhnə halı ölçmüş olarsınız və "düzəlməyib" nəticəsinə gələrsiniz. Yayımdan sonrakı təsdiq sırası belədir: yayımla → aidiyyatı yolların keşini təmizlə → ölç. Bu addım atlandığı üçün düzgün işləyən bir düzəlişin geri alındığına bir neçə dəfə şahid olduq.
9. Yönləndirmə zəncirləri və kanonik olmayan hədəflər
Auditdən əvvəl kök ünvan belə davranırdı: / → 302 → /az/ → 308 → /az. Üç dayanacaq. Hər dayanacaq həm brauzer üçün əlavə gecikmə, həm də siqnal itkisidir; üstəlik ilk addımın 302 (müvəqqəti) olması, hədəfin qalıcı kanonik olduğunu deyil, olmadığını bildirir. Tək addıma endirildi: / → 301 → /az.
Daha sinsi olan tapıntı ikincisi idi. Saytda köhnə ünvanları yeniyə daşıyan bir yönləndirmə cədvəli var idi və bu cədvəldəki 329 hədəfin özü kanonik deyildi — yəni yönləndirmə qaydaları tətbiq olunanda hər biri ikinci bir yönləndirmə də yaradacaqdı. Kanonikləşdirmə yayıma verilməzdən əvvəl tutuldu; verilsəydi 329 yeni zəncir doğulacaqdı.
Qərar qaydası
Yönləndirmə cədvəlinizə yeni sətir əlavə etməzdən əvvəl hədəfin özünü kanonik formaya qarşı yoxlayın: doğru host, doğru kəsik xətt siyasəti, həqiqətən 200 qaytaran bir səhifə. Bu yoxlama cədvəli dəyişən hər işin məcburi addımı olmalıdır; sonradan bir-bir ayıqlamaq qat-qat bahalıdır.
10. Öz saytınızda itən səhifələr
Bir səhifənin sayt xəritəsində olması onun tapıla bilən olması demək deyil. Auditdə iki ayrı itki maddəsi çıxdı:
49 indeksləşdirilə bilən yetim ünvan. Sayt xəritəsində elan edilən, amma saytda bir dənə də keçid almayan səhifələr: bir yardım mərkəzi səhifəsi (7 dil), beş inteqrasiya kateqoriya səhifəsi (35 ünvan) və siyahılarla kod arasında ayrışmış 7 ünvan. Bunların bir hissəsi üçün ünvan yaradan funksiya yazılmışdı, hətta menyu komponentinə daxil edilmişdi, amma heç vaxt çağırılmamışdı.
70 sınıq daxili keçid. Yardım səhifəsindəki dörd kateqoriya kartı mövcud olmayan bir yola gedirdi (4 kart × 7 dil = 28 keçid). Xidmət detal səhifələrinin üst bölgüsü (breadcrumb) heç vaxt yazılmamış bir xidmət kataloq səhifəsini göstərirdi (2 məkan × 3 xidmət × 7 dil = 42 keçid) — və eyni sınıq ünvan struktur məlumata da daxil olurdu.
Üçüncü tapıntı daha incədir: 33 bloq yazısının 21-i klik dərinliyi 3-də idi və yeganə çıxış yolu noindex işarəli bir səhifələmə addımı idi. Keçidlər izlənə bilən olduğu üçün texniki olaraq taranırdılar, amma yazılara gedən real, indeksləşdirilə bilən daxili keçid yox idi.
Ölçmə üsulu
Sayt xəritəsi ünvan siyahısını bir tərəfə, saytınızın daxili keçid qrafını (hər səhifədəki <a href> cəmini) o biri tərəfə qoyun və fərqi alın. Sayt xəritəsində olub qrafda olmayanlar yetimdir; qrafda olub 200 qaytarmayanlar sınıq keçiddir. Bu iki çoxluğu ayda bir dəfə yaratmaq, əksər saytların fərq etmədiyi itkini görünən edir.
11. Nazik məzmun və "tərcümə olunub sanılan" səhifələr
Auditdən sonrakı ölçmədə sayt ortalaması 472 söz, 300 sözdən az olan 176 səhifə idi. Amma əsas tapıntı xam rəqəmin özü deyil, onu oxuma tərzi idi.
Birinci düzəliş: səhifə çərçivəsini çıxarın. Səhifə mətnini olduğu kimi saymaq, üst menyunu və alt məlumatı da məzmuna daxil edir. Ölçdüyümüz saytda bu sabit çərçivə dil başına 117-233 söz tuturdu. Yəni xam 300 söz, əslində təxminən 120 sözlük bir gövdəyə uyğun gəlirdi. Real həddi xam saya deyil, çərçivəsi çıxarılmış gövdəyə qurun.
İkinci düzəliş: dil morfologiyasını normallaşdırın. Xam saya baxıldıqda alman dilindəki tərcümələr əskik görünürdü (median 393-ə qarşı ispanca 610). Halbuki məzmun birə-bir eyni idi; fərq tamamilə söz quruluşundan gəlirdi: Flugbuchungssoftware bir sözdür, eyni ifadə ispancada beş söz. Tamamilə tərcümə edilmiş səkkiz səhifə üzərindən ölçdüyümüz əmsallar belə idi:
| Dil | Əmsal (en = 1,00) |
|---|---|
| Alman | 0,827 |
| Azərbaycan | 0,916 |
| Türk | 0,929 |
| Rus | 0,939 |
| Ərəb | 0,963 |
| İspan | 1,165 |
Bu düzəliş edildikdə alman və ispan dillərində tərcümə boşluğunun olmadığı, real boşluğun ərəb dilində (22 ünvan) və ingilis dilində (16 ünvan) toplandığı ortaya çıxdı.
Üçüncü tapıntı: xülasə tərcümə deyil. Ərəb versiyalarının bir çoxu tam tərcümə deyil, ingiliscə mətnin qısaldılmış halı idi — çoxluq medianının 38-48%-i. Bunlar texniki olaraq "tərcümə edilmiş" sayılırdı, praktikada isə heç bir sorğuda yarışa bilmirdi.
Dördüncü tapıntı: 7 qrup / 67 ünvan birə-bir eyni gövdəyə sahib idi. Çoxu tərcüməsi edilmədən açılmış dil versiyaları idi.
Qərar qaydası
Bir dili "açmaq" tərcümə edilmədən baş verirsə, həmin dil dublikat məzmun yaradır və mövcud dillərin də işinə yaramır. Yeni dili yayıma vermə həddi belə olmalıdır: həmin dildə gövdə, mənbə dilin normallaşdırılmış söz sayının ən azı 85%-i. Aşağıdırsa yayıma verməyin; yayıma vermədiyiniz dil üçün hreflang də yazmayın (bax: 3-cü bölmə).
12. Süni intellekt axtarışı: təmizlikdən sonra gələn iş
Buraya qədərki on bir maddəni bağlamadan bu bölməyə keçməyin. Süni intellekt axtarışı ayrı bir kanal deyil, eyni indeksin üzərinə qurulmuş bir qatdır; alt qat pozuqdursa üst qat da pozuq işləyir.
Rəqəmlər bunu deyir. BrightEdge-in fevral 2025 – fevral 2026 arasındakı izləməsinə görə süni intellekt icmalları izlənən sorğuların təxminən 48%-ində görünür (bir il əvvəl ~30% idi); sorğuların təxminən yarısında hələ də heç icmal çıxmır. Seer Interactive-in fevral 2026 ölçməsində icmal çıxan sorğularda orqanik klik nisbəti 2,4%, icmal çıxmayanlarda 3,8% oldu. Pew Research-ün ABŞ-dakı 900 nəfərlik panelində (mart 2025, 68.879 axtarış) süni intellekt icmalı görülən ziyarətlərin 8%-ində klassik bir nəticə linkinə klik edilmişdi; icmal görülməyənlərdə bu nisbət 15% idi. İcmalın içindəki bir linkə klik nisbəti isə cəmi 1%-dir.
Səyahət üçün əsas kritik rəqəm budur: BrightEdge məlumatına görə səyahət sorğularındakı süni intellekt icmalı sitatlarının yalnız 17,7%-i orqanik ilk 10 nəticədən gəlir (bir il əvvəl 5,7% idi). Yəni sitatların təxminən dörddə üçündən çoxu ilk səhifədə olmayan mənbələrdən çəkilir.
Yuxarıda orqanik klik nisbəti müqayisəsi, aşağıda səyahət sorğularında sitat mənbələrinin bölgüsü. Mənbələr: Seer Interactive və BrightEdge, fevral 2026.
Bu iki rəqəm bir yerdə oxunduqda praktik nəticə budur: sıralamada birinci olmaq sitat gətirilməyi zəmanət etmir, sitat gətirilmək də ayrı bir işdir. Və sitat gətirilməyin ölçülə bilən qarşılığı var — Seer Interactive-in aprel 2026 ölçməsinə görə eyni sorğuda sitat gətirilən brendlər, gətirilməyənlərə nisbətən göstəriş başına 120% daha çox orqanik klik alır.
Bəs nə etməli — və nə etməməli
Əvvəlcə etməməli olanı dəqiqləşdirək, çünki bu sahədə həddindən artıq səs-küy var.
llms.txt həll deyil. Ahrefs-in 137.000 domeni əhatə edən araşdırmasında llms.txt fayllarının 97%-i 2026-cı ilin mayında heç bir sorğu almadı; etibarlı faylı olan təxminən 38.000 domenin yalnız ~1.100-ünə tək bir sorğu gəlmişdi və həmin sorğuların 96%-i bot idi, çoxu da süni intellekt aləti deyil, audit/profil çıxarma alətləri idi. Google tərəfində də vəziyyət aydındır: rəsmi süni intellekt funksiyaları sənədləşməsi "Bu funksiyalarda görünmək üçün yeni maşınla oxuna bilən fayllar, süni intellekt mətn faylları və ya işarələmə yaratmağınıza ehtiyac yoxdur" deyir və əlavə edir: "Əlavə etməli olduğunuz xüsusi bir schema.org struktur məlumatı da yoxdur."
Faylı yaratmaq zərərsizdir, amma görünürlük strategiyanız onun üzərinə qurula bilməz. Həqiqətən işə yarayan dörd şey var:
- Hər səhifədə maşınla təmiz götürülə biləcək bir cavab abzası. Başlığın dərhal altında, 40-60 sözlük, təyinedici və öz-özünə mənalı. "Bu yazıda ələ alacağıq" cümlələri sitat gətirilə bilməz; "Void, biletləşdirmədən sonra biletin heç kəsilməmiş sayılmasıdır və yalnız təchizatçının təyin etdiyi pəncərə daxilində mümkündür" cümləsi sitat gətirilə bilər.
- Yoxlana bilən rəqəm və mənbə. Qurum adı və il daxil olan bir rəqəm, mənbəsiz bir iddiadan həm insan, həm maşın üçün daha dəyərlidir. Mənbəsini verə bilməyəcəyiniz rəqəmi yazmayın; keyfiyyət baxımından izah edin.
- Standart struktur məlumat, düzgün qurulmuş. Xüsusi bir sxem axtarmayın;
Organization,BreadcrumbList,FAQPagekimi standart tipləri düzgün və ardıcıl doldurun. Auditdə tapdığımız iki tipik səhv: qurum loqosunun mövcud olmayan bir faylı göstərməsi (axtarış sistemi loqonu çəkə bilməyəndə naşir görüntüsünü tamamilə düşürür) və üst bölgü məlumatının yanlış kateqoriyanı göstərməsi. - Təkrarsız məzmun, həqiqətən tərcümə edilmiş. Yeddi dildə eyni gövdəyə sahib 67 ünvanın heç biri sitat gətirilə bilən deyildi.
Snippet nəzarətləri də burada keçərlidir: Google, nosnippet, data-nosnippet və noindex-in süni intellekt funksiyaları üçün də işlədiyini bildirir. Yəni bir bölmənin icmallarda istifadə edilməsini istəmirsinizsə alətiniz onsuz da var.
13. İyirmi maddəlik texniki görünürlük yoxlama siyahısı
Brauzer və curl xaricində alət tələb etmir. Hər maddədə gözlənilən nəticə yazılıb.
| № | Yoxlama | Gözlənilən nəticə |
|---|---|---|
| 1 | www-suz host sorğulanır | 301 → www-lu hal (və ya əksi, ardıcıl) |
| 2 | Sonda kəsik xətli hal sorğulanır | 301 → tək formaya |
| 3 | Kök ünvan sorğulanır | Tək addımda 301, dilə baxmadan |
| 4 | Təsadüfi 10 səhifədə canonical sayılır | Hər səhifədə tam olaraq 1 ədəd |
| 5 | Canonical dəyəri səhifənin öz ünvanıdırmı | Bəli, host və kəsik xətt daxil |
| 6 | Məhsul/bloq səhifəsində hreflang dəsti | Yalnız həqiqi tərcüməsi olan dillər |
| 7 | Hər hreflang hədəfi bir-bir sorğulanır | Hamısı 200 və həqiqi məzmun |
| 8 | Hər hədəf geri işarə edirmi | Bəli, qarşılıqlı |
| 9 | Dil kodları ISO 639-1-dirmi | Bəli; region təkbaşına yazılmayıb |
| 10 | Mövcud olmayan bir ünvan uydurulub sorğulanır | 404 (200 + "tapılmadı" deyil) |
| 11 | Latın olmayan slug xam və kodlu sorğulanır | İki forma da eyni kodu qaytarır |
| 12 | Sayt xəritəsi hostu kanonik hostdurmu | Bəli |
| 13 | Sayt xəritəsindən 10 ünvan seçilir | Hamısı 200 və HTML |
| 14 | lastmod dəyərləri incələnir |
Bir-birindən fərqli, real tarixlər |
| 15 | robots.txt qrupları oxunur | Qayda hər qrupda ayrıca yazılıb |
| 16 | Dilə görə dəyişən cavabda Vary |
Var; ya da cavab dilə bağlı deyil |
| 17 | Yönləndirmə hədəfləri seçilir | Hamısı kanonik və 200 |
| 18 | Sayt xəritəsi − daxili keçid qrafı fərqi | Boş çoxluq (yetim yoxdur) |
| 19 | Menyu və bölgü keçidləri taranır | Heç biri 404 qaytarmır |
| 20 | Yayımdan sonrakı ölçmə sırası | Yayımla → keş təmizlə → ölç |
14. Audit təqvimi
Bu işi bir dəfəlik layihə kimi qursanız altı ay içində geri qayıdar. Ölçdüyümüz saytda pozulmanın yeganə səbəbi laqeydlik deyildi; hər yeni səhifə şablonu öz variantını yaratdığı üçün sistem öz-özünə yayınırdı.
| Tezlik | İş | Nə üçün |
|---|---|---|
| Hər yayımda | 1-5, 10, 20-ci maddələr | Yeni şablon köhnə qaydanı bilmir |
| Həftəlik | 7, 8, 19-cu maddələr | Tərcümə və məzmun əlavələri dəsti pozur |
| Aylıq | 12-14, 18-ci maddələr | Sayt xəritəsi ilə reallıq yavaşca ayrışır |
| Üç aylıq | 6, 9, 11, 15-17 | İnfrastruktur və yönləndirmə cədvəli dəyişir |
Mənbələr
- Google Search Central — Səhifələrin lokallaşdırılmış versiyaları (hreflang)
- Google Search Central — Təkrarlanan URL-lərin birləşdirilməsi (canonical)
- Google Search Central — HTTP status kodları və soft 404
- Google Search Central — URL quruluşu üzrə ən yaxşı təcrübələr
- Google Search Central — Süni intellekt funksiyaları və saytınız
- IETF — RFC 9309: Robots Exclusion Protocol
- MDN Web Docs — Vary başlığı
- BrightEdge — AI Overviews at the One-Year Mark: Presence, Size, and What They're Citing (fevral 2026)
- Seer Interactive məlumatı, ALM Corp təqdimatı — Google AI Overviews and Organic CTR in 2026
- Seer Interactive məlumatı, Omnibound təqdimatı — Google AI Overviews Statistics (aprel 2026)
- Pew Research Center — Google users are less likely to click on links when an AI summary appears
- Ahrefs — We Analyzed 137K Sites: 97% of llms.txt Files Never Get Read (iyun 2026)
Mənbəyi göstərilməyən bütün ölçmələr (1.088 səhifə, 921 əskik canonical, 1.469 → 1.386 sayt xəritəsi, 49 yetim, 70 sınıq keçid, 329 kanonik olmayan yönləndirmə hədəfi, dil əmsalları) yeddidilli bir səyahət proqram təminatı saytında 2026-cı ilin iyulunda apardığımız öz auditimizə aiddir.
Tez-tez verilən suallar
Canonical etiketi tam olaraq nə işə yarayır?
Eyni və ya çox oxşar məzmuna sahib bir neçə ünvan varsa, hansının "əsas" sayılmalı olduğunu axtarış sisteminə bildirir. Lakin bu əmr deyil, Google-ın öz ifadəsi ilə güclü bir siqnaldır; son qərarı axtarış sistemi verir. Qalıcı olaraq bağlamaq istədiyiniz ünvanlar üçün canonical yerinə 301 yönləndirmə istifadə edin — yönləndirmə daha güclü siqnaldır.
www-lu və www-suz ünvanın ikisinin də açıq olması nə üçün problemdir?
Çünki texniki olaraq bunlar iki fərqli saytdır. İkisi də 200 qaytarırsa hər səhifəniz iki dəfə əlçatan olur; gələn keçidlər, klik məlumatı və tarama büdcəsi ikiyə bölünür. Birini seçib digərindən 301 ilə yönləndirin, sayt xəritəsi və daxili keçidlər də seçdiyiniz halı istifadə etsin.
hreflang-i hər dilə eyni slug ilə yaza bilərəmmi?
Yalnız həmin slug həqiqətən o dildə işləyirsə. Google hreflang-i qarşılıqlılıq şərtinə bağlayır: iki səhifə bir-birini göstərmirsə etiketlər nəzərə alınmaya bilər. Tərcüməsi olmayan bir dil üçün hreflang yazmaq, axtarış sisteminə mövcud olmayan bir səhifə elan etmək deməkdir. Əskik hreflang, yanlış hreflang-dən yaxşıdır.
Soft 404 nədir, necə fərq edilir?
Məzmunun bir səhv mesajı olmasına baxmayaraq serverin 200 uğur kodu qaytarmasıdır. Fərq etmənin ən sürətli yolu, saytınızda mövcud olmayan bir ünvan uydurub sorğulamaqdır: qayıdan kod 404 deyilsə soft 404-ünüz var deməkdir. Search Console-un indeksləşdirmə hesabatı da bu səhifələri ayrıca kateqoriyada sadalayır.
Ərəb və ya rus hərfli ünvanlar niyə bəzən 404 qaytarır?
Brauzer bu simvolları faizlə kodlayaraq göndərir; server bu kodlamanı açmırsa ünvan tapılmır. Xam halı test edildikdə işlədiyi üçün problem uzun müddət gizli qala bilər. Nəzarət üsulu, eyni ünvanı həm xam, həm faiz-kodlu formada sorğulamaq və iki cavabın eyni status kodunu qaytardığını təsdiqləməkdir.
Süni intellekt icmalları yayımlandığından bəri orqanik trafikim niyə düşdü?
Ölçmələr struktur fərq göstərir: Seer Interactive-in fevral 2026 məlumatında icmal çıxan sorğularda orqanik klik nisbəti 2,4%, çıxmayanlarda 3,8% idi. Pew Research-ün panelində isə icmal görülən axtarışlarda nəticə linkinə klik nisbəti 8%, görülməyənlərdə 15% idi. Yəni eyni sıralamada qalsanız belə icmal çıxan sorğularda daha az klik alırsınız; hədəf, həmin icmalın içində sitat gətirilmək olmalıdır.
llms.txt faylı yaratmalıyammı?
Zərəri yoxdur, amma görünürlük planınızı buna bağlamayın. Ahrefs-in 137.000 domen üzərindəki araşdırmasında bu faylların 97%-i 2026-cı ilin mayında heç bir sorğu almadı. Google da rəsmi sənədləşməsində süni intellekt funksiyalarında görünmək üçün yeni maşınla oxuna bilən fayl, işarələmə və ya xüsusi struktur məlumat tələb olunmadığını açıq şəkildə bildirir.
Auditi hansı tezliklə təkrarlamalıyam?
Bir dəfəlik layihə kimi qurğulasanız bir neçə ay içində pozular, çünki hər yeni səhifə şablonu öz ünvan variantını yaratmağa meyllidir. Praktik bir qayda: ünvan və canonical yoxlamalarını hər yayımda, hreflang və daxili keçid yoxlamalarını həftəlik, sayt xəritəsi və yetim analizini aylıq, infrastruktur yoxlamalarını üç ayda bir işlətmək.
Sabah səhər edə biləcəyiniz beş şey
- Beş variant testini işlədin. Ən çox trafik alan üç səhifəniz üçün www-lu/www-suz, kəsik xətli/xəttsiz və varsa köhnə yol halını sorğulayın; qayıdan kodları bir cədvələ yazın. Birdən çox 200 varsa ilk işiniz bəllidir.
- On səhifədə canonical sayın. Səhifə mənbəyində neçə
rel="canonical"var və dəyəri səhifənin öz ünvanıdırmı? Sıfır və ya birdən çox çıxan hər səhifə bir tapıntıdır. - Bir yazının bütün hreflang hədəflərini bir-bir sorğulayın. Hamısı 200-dürmü, gövdələri həqiqi məzmundurmu, geri işarə edirlərmi? Qarşılığı olmayan dil varsa həmin sətri silin — bu, təkbaşına ən sürətli qazancdır.
- Mövcud olmayan bir ünvan uydurub sorğulayın. 404 gəlmirsə soft 404-ünüz var; bu bir düzəlişlə görünməyən bir neçə nasazlıq birdən ortaya çıxır.
- Sayt xəritəsindən on ünvan seçin. Host doğrudurmu, hamısı 200 və HTML-dirmi,
lastmoddəyərləri realdırmı? Sayt xəritəsi reallığı bildirmirsə qalan hər ölçməniz də yanlış təməl üzərinə oturur.