ტექნიკური SEO ჩეკ-ლისტი საქართველოში საიტის გაშვებისთვის: სრული სახელმძღვანელო

შესავალი: რატომ არის ტექნიკური SEO თქვენი ონლაინ წარმატების საფუძველი

წარმოიდგინეთ, რომ ქალაქის ცენტრში ლამაზი მაღაზია ააშენეთ, მაგრამ შესასვლელი ან მიმართულების მაჩვენებლები დაავიწყდათ. დაახლოებით ასე მუშაობს საიტი სათანადო ტექნიკური ოპტიმიზაციის გარეშე — ის არსებობს, მაგრამ საძიებო სისტემები ვერ ხედავენ, ხოლო პოტენციური კლიენტები ვერ პოულობენ.

ტექნიკური SEO — ეს არის საფუძველი, რომელზეც აიგება თქვენი საიტის მთელი პროდვიჟება Google-ში. ეს არის ტექნიკური პარამეტრებისა და მოთხოვნების ნაკრები, რომელიც საშუალებას აძლევს საძიებო ბოტებს სწორად დაინდექსირება გააკეთონ, ხოლო მომხმარებლებს — კომფორტულად ისარგებლონ საიტით. ამ საფუძვლის გარეშე, ყველაზე მაღალი ხარისხის კონტენტიც და ძვირი რეკლამაც სასურველ შედეგს ვერ მოიტანს.

ეს სტატია წარმოადგენს ახალი საიტის გაშვების ტექნიკურ ჩეკ-ლისტს, რომელიც კარგად დაირეიტინგება საძიებო სისტემებში. ყველა ასპექტს მარტივი ენით განვიხილავთ, რათა გაიგოთ არა მხოლოდ „რა გააკეთოთ", არამედ „რატომ არის ეს საჭირო".

1. 301 გადამისამართება: ყველა გვერდისთვის ერთი გზა

რა არის 301 გადამისამართება და რატომ არის საჭირო?

301 გადამისამართება — ეს არის მუდმივი გადამისამართება ერთი გვერდის მისამართიდან მეორეზე. ეს ჰგავს მაჩვენებელს „ოფისი ახალ მისამართზე გადავიდა", რომელიც ვიზიტორს ავტომატურად სწორ ადგილას აგზავნის.

პრობლემა ის არის, რომ ტექნიკურად ერთი და იგივე გვერდი შეიძლება სხვადასხვა მისამართიდან იყოს ხელმისაწვდომი. მაგალითად:

• https://site.ge/
• http://site.ge/
• https://www.site.ge/
• https://site.ge/index.html

Google-სთვის ეს სხვადასხვა გვერდია ერთი და იმავე კონტენტით — დუბლიკატები. ეს ამცირებს გვერდის ძალაუფლებას და უარყოფითად მოქმედებს რეიტინგზე.

საიტისთვის სავალდებულო გადამისამართებები

1. Index-ფაილებიდან გადამისამართება

index.html ან index.php-ის ყველა ვარიანტი უნდა გადამისამართდეს სუფთა URL-ზე:

• https://site.ge/index.html-დან → https://site.ge/-ზე
• https://site.ge/blog/index.php-დან → https://site.ge/blog/-ზე

2. HTTPS-ზე გადამისამართება

2026 წელს SSL სერტიფიკატის გარეშე საიტი ცუდ პრაქტიკად ითვლება და უარყოფითად აღიქმება როგორც საძიებო სისტემების, ისე მომხმარებლების მიერ. Google ოფიციალურად HTTPS-ს რეიტინგის ფაქტორად იყენებს:

• http://site.ge/-დან → https://site.ge/-ზე

3. www/www-ის გარეშე გადამისამართება

აირჩიეთ ერთი ვერსია (www-ით ან გარეშე) და ამ ვერსიას придерживайтеს:

• https://www.site.ge/-დან → https://site.ge/-ზე (ან პირიქით)

4. URL-ის ბოლოს სლეშის გადამისამართება

მთავარი წესი — მთელი საიტისთვის ერთი ფორმატი აირჩიოთ და გადამისამართებები კანონიკური ვარიანტისკენ დააყენოთ. ორივე მიდგომა ტექნიკურად სწორია:

ვარიანტი A (რეკომენდებული):

• მთავარი გვერდი — ყოველთვის სლეშით: https://site.ge/
• ყველა სხვა გვერდი — ყოველთვის სლეშის გარეშე: https://site.ge/blog

ვარიანტი B:

• ყველა გვერდი ბოლოს სლეშით

ვარიანტ A-ს გირჩევთ, მაგრამ მთავარია მიდგომები არ შეურიოთ. თუ შიდა გვერდებისთვის სლეშის გარეშე ფორმატი აირჩიეთ, /blog/-დან /blog-ზე გადამისამართება ყველა URL-სთვის დააყენეთ.

მნიშვნელოვანია: მოერიდეთ გადამისამართების ჯაჭვებს

ხშირი შეცდომა — რამდენიმე თანმიმდევრული გადამისამართების დაყენება:

http://www.site.ge/blog/ → https://www.site.ge/blog/ → https://site.ge/blog/ → https://site.ge/blog

ეს 4 გადამისამართებაა! თითოეული ანელებს ჩატვირთვას და შეიძლება საძიებო ბოტმა გვერდის დათვალიერება შეწყვიტოს. წესები ისე დააყენეთ, რომ მაქსიმუმ 1-2 გადამისამართება იყოს.

2. საიტის ჩატვირთვის სიჩქარე: რატომ არის ეს კრიტიკულად მნიშვნელოვანი

სიჩქარის სამიზნე მაჩვენებლები

Google პირდაპირ აცხადებს: ჩატვირთვის სიჩქარე — ეს არის რეიტინგის ფაქტორი, განსაკუთრებით Core Web Vitals-ის პრიზმით — მეტრიკების ნაკრები, რომელიც რეალურ მომხმარებელთა გამოცდილებას ზომავს. განსაკუთრებით მნიშვნელოვანია მობილური მოწყობილობებისთვის.

თქვენი მიზნები:

• PageSpeed Insights: 70-75 ქულა მობილური ვერსიისთვის, 85+ დესკტოპისთვის
• TTFB (Time To First Byte): არაუმეტეს 0,6 წამისა
• First Interactive (TTI): არაუმეტეს 3-5 წამისა 4G-ს ემულაციისას

სიჩქარის სწორი გაზომვა

გამოიყენეთ ორი ინსტრუმენტი:

1. Google PageSpeed Insights (developers.google.com/speed/pagespeed/insights)
   აჩვენებს შეფასებას და კონკრეტულ გაუმჯობესების რეკომენდაციებს
2. WebPageTest.org
   დააყენეთ შემოწმება სამიზნე რეგიონიდან, ჩართეთ მობილური მოწყობილობის ემულაცია და 4G სიჩქარე. ყურადღება მიაქციეთ TTFB-სა და First Interactive-ს.

დაჩქარების პრაქტიკული ნაბიჯები

გაშვების შემდგომ საწყის ეტაპზე:

• დაუკავშირეთ CDN (Content Delivery Network) — თუნდაც უფასო CloudFlare მნიშვნელოვნად დააჩქარებს სტატიკური ფაილების ჩატვირთვას
• გაააქტიუHTTP/3 (QUIC) — 2026 წლისთვის ეს სტანდარტია, რომელიც მნიშვნელოვნად აჩქარებს ჩატვირთვას მობილურ ქსელებში (ან მინიმუმ HTTP/2)
• ჩართეთ Gzip ან Brotli კომპრესია ტექსტური რესურსებისთვის
• დააყენეთ სტატიკური ფაილების ქეშირება (მინიმუმ 3 დღე)

3. HTML კოდის ვალიდურობა: სისუფთავე „კაპოტის ქვეშ"

თქვენი საიტის HTML კოდი უნდა იყოს ვალიდური, ანუ W3C სტანდარტებს უნდა შეესაბამებოდეს. კოდში უხეში შეცდომები შეიძლება საძიებო ბოტმა გვერდის სტრუქტურა ვერ გაიგოს ან საერთოდ ვერ დაამუშავოს.

ვალიდურობის შემოწმება

გამოიყენეთ ოფიციალური ვალიდატორი: validator.w3.org

100%-იანი ვალიდურობა ყოველთვის მიღწევადი არ არის (ზოგიერთი თანამედროვე ტექნოლოგია შეიძლება გაფრთხილებებს იწვევდეს), მაგრამ კრიტიკული შეცდომები არ უნდა იყოს. Google პირველ რიგში სტრუქტურულ პრობლემებს ყურადღებას აქცევს — დაუხურავ თეგებს, ელემენტების არასწორ ბუდობას.

4. კონტენტის რენდერინგი: Google რას ხედავს თქვენს საიტზე

წესი: მნიშვნელოვანი კონტენტი HTML-ში უნდა იყოს

ხშირი შეცდომა — ტექსტების, სათაურების ან ნავიგაციის JavaScript-ით დაგვიანებით ჩატვირთვა (AJAX მოთხოვნები). Google-ის ბოტს JS სკრიპტების შესასრულებლად ძალიან მცირე ტაიმაუტი აქვს და შეიძლება მნიშვნელოვანი კონტენტის ჩატვირთვას ვერ დაელოდოს.

სწორი მიდგომა: SEO-სთვის ყველა მნიშვნელოვანი კონტენტი (H1-H6 სათაურები, ძირითადი ტექსტი, სხვა გვერდებზე ბმულები, მეტა-თეგები) გვერდის HTML კოდში უნდა იყოს.

სურათებისთვის Lazy Load: თანამედროვე მიდგომა

სურათების გადადებული ჩატვირთვა (Lazy Load) — ეს შესანიშნავი ტექნიკაა საიტის დასაჩქარებლად. ნუ ინერვიულებთ, ეს ადვილად შესამოწმებელია ბრაუზერების თანამედროვე ჩაშენებული შესაძლებლობებით.

რეკომენდებული გზა: გამოიყენეთ ნატიური ატრიბუტი loading="lazy":

<img src="image.jpg" alt="აღწერა" loading="lazy">

ეს ბრაუზერების ჩაშენებული ფუნქციაა, რომელიც სრულად არის მხარდაჭერილი Google-ის მიერ და არანაირ დამატებით სკრიპტებს არ საჭიროებს. სურათები ჩაიტვირთება მხოლოდ მაშინ, როდესაც მომხმარებელი მათამდე გადაახვევს გვერდს.

მნიშვნელოვანია (LCP-ის გამონაკლისი): არასოდეს გამოიყენოთ loading="lazy" გვერდის პირველი სურათისთვის (მთავარი ბანერი, ლოგო ან პროდუქტის ფოტო). მისთვის უმჯობესია fetchpriority="high" გამოიყენოთ, რათა მყისიერად ჩაიტვირთოს.

რთული შემთხვევებისთვის: თუ ძველი ბრაუზერების მხარდაჭერა გჭირდებათ ან უფრო დახვეწილი კონფიგურაცია (მაგ. CSS-ის ფონური სურათებისთვის), შეგიძლიათ გამოიყენოთ JavaScript-ის გადაწყვეტა, მაგ. yall.js, მაგრამ დარწმუნდით, რომ არჩეული გადაწყვეტა SEO-ს მეგობარია.

მნიშვნელოვანია: ნებისმიერი Lazy Load-ის დანერგვის შემდეგ აუცილებლად შეამოწმეთ რენდერინგის სისწორე Google Search Console-ის URL შემოწმების ინსტრუმენტის გამოყენებით.

5. პაგინაცია: მრავალგვერდიანობის სწორი ორგანიზება

პაგინაცია — ეს არის გრძელი სიის (პროდუქტები, სტატიები, ღონისძიებები) რამდენიმე გვერდად დაყოფა. ბლოგისთვის ან კატალოგისთვის ეს სტანდარტული პრაქტიკაა, მაგრამ SEO-ს თვალსაზრისით აქ ბევრი ნიუანსია.

პაგინაციის ძირითადი წესები

1. ბმულები ბოტისთვის გასაგები უნდა იყოს

გამოიყენეთ ჩვეულებრივი HTML ბმულები:

<a href="/blog/?page=2">2</a>

ნუ გამოიყენებთ ნავიგაციას JavaScript-ის გამოყენებით HTML ბმულების გარეშე.

2. არარსებული გვერდები 404-ს აბრუნებს

თუ თქვენს ბლოგში 50 სტატიაა, 10 სტატია ერთ გვერდზე (5 პაგინაციის გვერდი), მაშინ:

• /blog/?page=6 უნდა დაუბრუნოს კოდი 404 Not Found
• /blog/?page=qwerty ან /blog/?page=-1 ასევე 404

3. მოერიდეთ დუბლიკატებს

/blog/ და /blog/?page=1 გვერდები — ეს ერთი და იგივე კონტენტია.

გამოსავალი: დააყენეთ 301 გადამისამართება /blog/?page=1-დან /blog/-ზე

პაგინატორში /?page=1-ზე ბმული არ უნდა იყოს — მხოლოდ სუფთა URL /blog/.

4. პაგინაციის გვერდებისთვის უნიკალური Title და Description

მეტა-თეგების შაბლონის შექმნის შესაძლებლობა დანერგეთ:

• გვერდი 1: „კომპანიის ბლოგი — სასარგებლო სტატიები მარკეტინგის შესახებ"
• გვერდი 2: „კომპანიის ბლოგი — გვერდი 2 | მარკეტინგის სტატიები"

ეს გეხმარებათ თავი აარიდოთ დუბლიკატი კონტენტის პრობლემებს, რომლებსაც „დუბლიკატებთან ბრძოლის" სექციაში დეტალურად განვიხილავთ.

6. მიკრომარკირება: Google-ს ვეხმარებით საიტის კონტენტის გაგებაში

Open Graph სოციალური ქსელებისთვის

Open Graph — ეს არის მეტა-თეგები, რომლებიც განსაზღვრავს, როგორ გამოჩნდება თქვენი გვერდი Facebook-ში, LinkedIn-ში ან მესენჯერებში გასაზიარებლად.

სავალდებულო თეგები:

<meta property="og:title" content="გვერდის სათაური" />
<meta property="og:description" content="გვერდის აღწერა" />
<meta property="og:image" content="https://site.ge/image.jpg" />
<meta property="og:url" content="https://site.ge/page" />

შემოწმება: გამოიყენეთ developers.facebook.com/tools/debug ან opengraphcheck.com

პურის ნამსხვრევები (Breadcrumbs) Schema.org მიკრომარკირებით

პურის ნამსხვრევები — ეს არის ნავიგაციური ჯაჭვი სახით:
მთავარი > სერვისები > SEO-პროდვიჟება

ისინი JSON-LD ფორმატში Schema.org-ის გამოყენებით უნდა იყოს მონიშნული:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [{
    "@type": "ListItem",
    "position": 1,
    "name": "მთავარი",
    "item": "https://site.ge/"
  },{
    "@type": "ListItem",
    "position": 2,
    "name": "სერვისები",
    "item": "https://site.ge/services"
  }]
}
</script>

მნიშვნელოვანია: გამოიყენეთ Schema.org, და არა მოძველებული data-vocabulary.org.

შემოწმება: search.google.com/structured-data/testing-tool

7. Hreflang და HTML lang: მრავალენოვანობაზე მუშაობა

თუ თქვენი საიტი რამდენიმე ენაზე მუშაობს (რაც აქტუალურია საერთაშორისო აუდიტორიაზე ორიენტირებული ბიზნესისთვის), ამის სწორად მიწოდება გჭირდებათ საძიებო სისტემებისთვის.

HTML lang ატრიბუტი

ყოველ გვერდზე

<html>

<html lang="ka"> <!-- ქართული ვერსიისთვის -->
<html lang="ru"> <!-- რუსული ვერსიისთვის -->
<html lang="en"> <!-- ინგლისური ვერსიისთვის -->

მნიშვნელოვანია: რეგისტრს მნიშვნელობა აქვს. სწორია: ka, en, არასწორია: KA, Ka.

hreflang ატრიბუტი

Hreflang Google-ს ამცნობს, რომ თქვენ გვერდის ალტერნატიული ენობრივი ვერსიები გაქვთ. Google-ის ოფიციალური დოკუმენტაციის მიხედვით, შეგიძლიათ მიუთითოთ ან მხოლოდ ენის კოდი, ან ენა + რეგიონი.

როდის კმარა მხოლოდ ენის კოდი:

უმეტეს შემთხვევაში საკმარისია მხოლოდ ენის მითითება (ka, ru, en):

<link rel="alternate" hreflang="ka" 
  href="https://site.ge/ka/page" />
<link rel="alternate" hreflang="ru" 
  href="https://site.ge/ru/page" />
<link rel="alternate" hreflang="en" 
  href="https://site.ge/en/page" />

როდის დაამატოთ რეგიონული კოდი:

რეგიონული კოდი (მაგ. ka-GE, ru-GE) ემატება მხოლოდ მაშინ, თუ კონტენტი კონკრეტული ქვეყნის აუდიტორიისთვის არსებითად განსხვავდება. მაგალითად, საქართველოში მომუშავე საიტისთვის:

• ფასები ლარებშია მითითებული და არა დოლარებში ან ევროში
• ახსენებს ადგილობრივ რეალობებს, კანონებს, მისამართებს
• კონტენტი ადგილობრივ ბაზარზეა გამახვილებული

<link rel="alternate" hreflang="ka-GE" 
  href="https://site.ge/ka/page" />
<link rel="alternate" hreflang="ru-GE" 
  href="https://site.ge/ru/page" />

x-default ატრიბუტი:

x-default — ეს არის hreflang-ის სპეციალური ატრიბუტი, რომელიც Google-ს ეუბნება, რომელი გვერდი აჩვენოს მომხმარებლებს, თუ მათი ენა/რეგიონი hreflang-ში მითითებულს არ ემთხვევა.

x-default-ის გამოყენება:

ვარიანტი 1: თუ თქვენი ბიზნესი საერთაშორისოა (სასტუმროები, IT, ექსპორტი)

თუ გინდათ ნებისმიერმა უცხოელმა (ფრანგმა, იაპონელმა, შვედმა) გაიგოს თქვენი კონტენტი, x-default-ში ინგლისური ვერსია მიუთითეთ.

<link rel="alternate" hreflang="x-default" 
  href="https://site.ge/en/" />
<link rel="alternate" hreflang="en" 
  href="https://site.ge/en/" />
<link rel="alternate" hreflang="ka" 
  href="https://site.ge/ka/" />
<link rel="alternate" hreflang="ru" 
  href="https://site.ge/ru/" />

ვარიანტი 2: თუ თქვენი ბიზნესი ადგილობრივია (საქართველოში მიწოდება, ადგილობრივი სერვისი)

თუ თქვენი სერვისები ქვეყანასთან არის კავშირი და გინდათ „ორიგინალი" აჩვენოთ, x-default-ში ქართული (ძირითადი ადგილობრივი) ენა მიუთითეთ.

<link rel="alternate" hreflang="x-default" 
  href="https://site.ge/ka/" />
<link rel="alternate" hreflang="ka" 
  href="https://site.ge/ka/" />
<link rel="alternate" hreflang="ru" 
  href="https://site.ge/ru/" />
<link rel="alternate" hreflang="en" 
  href="https://site.ge/en/" />

Self-referencing წესი: ყოველი გვერდი საკუთარ თავს უნდა მიუთითებდეს. ბმულების ეს ბლოკი ყველა ენობრივ ვერსიაზე იდენტური უნდა იყოს.

მაგალითად, ქართულ ვერსიაზე ის ინგლისური ვერსიის მსგავსად გამოიყურება:

<link rel="alternate" hreflang="ka" 
  href="https://site.ge/ka/page" />
<link rel="alternate" hreflang="ru" 
  href="https://site.ge/ru/page" />
<link rel="alternate" hreflang="en" 
  href="https://site.ge/en/page" />

8. დუბლიკატებთან ბრძოლა: ერთი კონტენტი — ერთი URL

დუბლიკატი კონტენტი — ეს ერთ-ერთი ყველაზე გავრცელებული პრობლემაა, რომელიც გვერდების ძალაუფლებას ამცირებს და პროდვიჟებაში ხელს უშლის.

დუბლიკატების გამოჩენის ტიპური მიზეზები

1. ბოლო სლეში

როგორც გადამისამართების სექციაში ვთქვით, აირჩიეთ ერთი ფორმატი და 301 გადამისამართება კანონიკური ვარიანტისკენ დააყენეთ.

2. URL-ში ასოების რეგისტრი

/services და /Services — ტექნიკურად სხვადასხვა გვერდია. URL ყოველთვის მცირე ასოებში (lowercase) გამოიყენეთ.

3. გაუთავებელი სლეში

ზოგიერთი საიტი ასეთ მოთხოვნებზე 200 OK კოდს აბრუნებს:
/blog/////article/////

გამოსავალი: ნორმალიზებულ URL-ზე 301 გადამისამართება დააყენეთ.

4. ძიების გვერდები

საიტის ძიების შედეგების გვერდები (/search?q=keyword) დუბლიკატების გაუთავებელ რაოდენობას ქმნის. ბიზნესის ბევრი მფლობელის ხშირი „ტკივილი" ის არის, რომ ეს გვერდები შემთხვევით ინდექსში ხვდება და ძირითად გვერდებს ეჯიბრება.

გამოსავალი:

• <head>

  -ში დაამატეთ:

  <meta name="robots" content="noindex, nofollow" />

• robots.txt-ში დახურეთ: Disallow: /*?search=

5. GET-პარამეტრები თვითნებური მნიშვნელობებით

თუ გაქვთ დალაგება /catalog?sort=price, მაშინ /catalog?sort=blahblah გვერდი 200 OK-ს არ უნდა აბრუნებდეს — მხოლოდ 404 ან 301 გადამისამართება ნაგულისხმევ მნიშვნელობაზე.

გამონაკლისი: UTM-მარკირება (მაგ. ?utm_source=facebook) ნებისმიერ მნიშვნელობას შეიძლება შეიცავდეს — ეს ნორმალურია.

9. Canonical URL: გვერდის მთავარი ვერსიის მითითება

Canonical — ეს სპეციალური თეგია, რომელიც Google-ს ეუბნება: „თუ რამდენიმე მსგავსი გვერდი გვაქვს, ეს — მთავარია".

Canonical-ის გამოყენების ძირითადი წესები

1. ყველა გვერდს canonical უნდა ჰქონდეს

თუნდაც გვერდი დუბლიკატი არ იყოს, canonical საკუთარ თავს უნდა მიუთითებდეს:

<link rel="canonical" href="https://site.ge/page" />

2. პაგინაცია: canonical საკუთარ თავზე

ზოგიერთი ძველი რეკომენდაციისგან განსხვავებით, ჩვენი აზრით, პაგინაციის ყოველი გვერდი კონტენტს ცვლის, ამიტომ:

/blog/?page=2 → canonical https://site.ge/blog/?page=2-ზე

3. კონტენტზე გავლენის არმქონე GET-პარამეტრები

UTM-მარკირებისა და სხვა პარამეტრებისთვის, რომლებიც კონტენტს არ ცვლიან:

/page?utm_source=fb → canonical https://site.ge/page-ზე

4. მხოლოდ აბსოლუტური URL-ები

არასწორია:

<link rel="canonical" href="/page" />

<link rel="canonical" href="https://site.ge/page" />

5. მხოლოდ მთავარ სარკეზე მითითება

თუ HTTP და HTTPS ვერსიები ხელმისაწვდომია, ორივეზე canonical HTTPS-ზე უნდა მიუთითებდეს.

10. საიტის უსაფრთხოება: SSL და დაუცველობებისაგან დაცვა

SSL სერტიფიკატი — სავალდებულოა

2026 წელს HTTPS — ეს ვარიანტი კი არ არის, არამედ ძირითადი მოთხოვნა. Google ღიად ამცირებს SSL-ის გარეშე საიტების რეიტინგს, ხოლო ბრაუზერები საშინელ გაფრთხილებებს აჩვენებს.

SSL-ის შემოწმება:

• SSL Labs — შეფასება A-ზე დაბალი არ უნდა იყოს
• htbridge.com — პარამეტრების სისწორის შემოწმება

დაუცველობებზე შემოწმება

აუცილებლად შეამოწმეთ საიტი:

• pentest-tools.com
• bbs.ptsecurity.com

დაუცველი საიტი — ეს არა მხოლოდ გატეხვის რისკია, არამედ Google-ის სანქციების პოტენციური საფრთხეც.

11. მობილური ადაპტაცია: ტრაფიკის უმეტესობა ტელეფონებიდანაა

მობილური ვარგისობის ტესტი

თქვენი საიტის ყოველი გვერდი უნდა გაიაროს შემოწმება:
search.google.com/test/mobile-friendly

კონტენტი იდენტური უნდა იყოს

Google Mobile-First Index-ის კრიტიკული წესი: კონტენტი მობილურ და დესკტოპის ვერსიებზე იდენტური უნდა იყოს.

ეს ნიშნავს:

• ყველა H1-H6 სათაური
• Title და Description მეტა-თეგები
• ძირითადი ტექსტი
• სურათები
• გვერდებს შორის ბმულები
• მიკრომარკირება

მობილურ ვერსიაზე კონტენტი ჩანართებში ან სპოილერებში შეიძლება დაიმალოს, მაგრამ ის გვერდის HTML კოდში უნდა იყოს (არა AJAX-ით).

აკრძალულია: მობილურ ვერსიაზე კონტენტის მნიშვნელოვანი ბლოკების მუდმივი დამალვა.

12. URL-ების ფორმირების მოთხოვნები

URL-ში რისი გამოყენება შეიძლება

„?" ნიშნამდე:

• ლათინური ასოები (a-z)
• ციფრები (0-9)
• დეფისი (-)
• ქვედა ხაზი (_) — დასაშვებია, მაგრამ არ არის რეკომენდებული

GET-პარამეტრებში („?"-ის შემდეგ):

• ლათინური ასოები
• ციფრები
• დეფისი
• ქვედა ხაზი

რა არ არის დასაშვები

• სფეისები
• წერტილები, მძიმეები
• ბრჭყალები
• სპეცსიმბოლოები (#, %, &, GET-პარამეტრების გამყოფების გარდა)
• Unicode სიმბოლოები (კირილიცა, ემოჯი)

ყველა დაუშვებელი სიმბოლო დეფისით შეცვალეთ ან წაშალეთ.

URL-ის სტაბილურობა

კრიტიკულად მნიშვნელოვანია: გვერდის კონტენტის შეცვლისას (მაგ. პროდუქტის სახელის შეცვლა) URL უცვლელი უნდა დარჩეს. მისამართების შეცვლა მხოლოდ უკიდურეს შემთხვევებში შეიძლება, 301 გადამისამართების სავალდებულო დაყენებით.

13. დამატებითი ტექნიკური მოთხოვნები

H1-H6 სათაურების სტრუქტურა

• H1 — გვერდზე მხოლოდ ერთი (ძირითადი სათაური)
• H2-H6 — გამოიყენება მხოლოდ კონტენტის სათაურებისა და ქვესათაურების გასაფორმებლად
• სათაურები მენიუსთვის ან გამჭოლი ელემენტებისთვის არ უნდა გამოიყენებოდეს

გარე CSS და JavaScript

• სტილები ცალ .css ფაილებში გამოიტანეთ
• JavaScript .js ფაილებში გამოიტანეთ
• გარე ფაილების რაოდენობა მინიმალურად შეამცირეთ (სადაც შესაძლებელია, გააერთიანეთ)
• მოერიდეთ inline-სტილებს

კოდირება

ყველა გვერდისთვის UTF-8 გამოიყენეთ:

<meta charset="UTF-8">

ფრეიმები

ნუ გამოიყენებთ ფრეიმებს (

<frame>

<iframe>

მეტა-თეგების რედაქტირება

გჭირდებათ შესაძლებლობა:

• ყოველი გვერდისთვის ინდივიდუალურად დაარედაქტიროთ Title, Description, Keywords, H1
• ერთი ტიპის გვერდებისთვის (მაგ. ყველა პროდუქტისთვის) მეტა-თეგების შაბლონები დააყენოთ

სურათებისთვის ALT

ყველა მნიშვნელოვან სურათს უნდა ჰქონდეს alt ატრიბუტი აღწერით:

<img src="product.jpg" 
  alt="წითელი დივანი მისაღები ოთახის ინტერიერში" />

შიდა ბმულები

• თქვენი საიტის სხვა გვერდებზე ყველა ბმული

  <a href="...">

  -ის გამოყენებით უნდა იყოს
• ბმულები HTML-ში ხილული უნდა იყოს (მხოლოდ JavaScript-ით არ გენერირდებოდეს)
• მოერიდეთ

  rel="nofollow"

  -ს შიდა ბმულებზე

404 გვერდი

• უნდა აბრუნებდეს HTTP კოდ 404 (არა 200 ან 302)
• საიტის სტილში უნდა იყოს გაფორმებული
• უნდა შეიცავდეს ნავიგაციას და მთავარ გვერდზე დაბრუნების შეთავაზებას

Sitemap.xml

• სასურველია ავტომატურად გენერირდებოდეს
• უნდა გაიაროს ვალიდაცია
• უნდა შეიცავდეს ყველა ძირითად გვერდს (სექციები, პროდუქტები, სტატიები)
• არ უნდა შეიცავდეს პაგინაციას, დუბლიკატებს, გატეხილ ბმულებს, noindex გვერდებს

Favicon

საიტის root-ში უნდა იყოს (/favicon.ico) და მინიმუმ 32x32 პიქსელის ზომა უნდა ჰქონდეს.

Google Analytics

დააინსტალირეთ Google Analytics კოდი (Google Tag Manager-ის გამოყენება გირჩევთ) პროდვიჟების ეფექტიანობის სადევნებლად.

14. საიტის სატესტო ვერსიის მოთხოვნები

თუ საიტს ავითარებთ, ეს წესები სატესტო ვერსიისთვის აუცილებლად დაიცავით:

1. განთავსება: მხოლოდ ძირითადი საიტის სუბდომენზე (test.site.ge)
2. წვდომა: მხოლოდ ავტორიზაციის შემდეგ
3. Meta robots: ყოველ გვერდზე

   <meta name="robots" content="noindex, nofollow" />

4. X-Robots-Tag: HTTP სათაურებში დაამატეთ

   X-Robots-Tag: noindex, nofollow

ეს კრიტიკულად მნიშვნელოვანია, რათა Google-მა საიტის დაუმთავრებელი ვერსია არ დაინდექსოს.

ხშირად დასმული შეკითხვები (FAQ)

1. HTTP-დან HTTPS-ზე გადამისამართება დავაყენე, მაგრამ Search Console-ში ორივე საიტის ვერსია ცალ-ცალკე ობიექტად ვხედავ. ეს ნიშნავს, რომ გადამისამართება არ მუშაობს, თუ Google-მა მონაცემები ჯერ ვერ განაახლა?

ეს ნორმალური სიტუაციაა, რომელიც ხშირად საიტების მფლობელებს ბნევს.

Google Search Console საშუალებას იძლევა სხვადასხვა ვერსიები დაემატოს ცალ-ცალკე „ობიექტებად" — HTTP, HTTPS, www-ით და გარეშე. ეს არ ნიშნავს, რომ გადამისამართება არ მუშაობს. ორივე ვერსიის Search Console-ში ყოფნა — ეს მხოლოდ ძველი URL-ების სტატისტიკის სანახავი გზაა, რომლებიც ჯერ კიდევ შეიძლება იყოს ინდექსში.

გადამისამართების მუშაობის შემოწმება:

1. გამოიყენეთ HTTP-სათაურების შემოწმების ინსტრუმენტი (httpstatus.io)
2. შეიყვანეთ http://site.ge და დარწმუნდით, რომ სერვერი 301 (არა 302) კოდს აბრუნებს https://site.ge-ზე გადამისამართებით
3. Search Console-ში შეამოწმეთ „Coverage" სექცია — HTTP ვერსიაში გადამისამართების დაყენებიდან რამდენიმე კვირის შემდეგ ნულოვანი გვერდები უნდა გამოჩნდეს

რა გავაკეთოთ:

• თუ გადამისამართება სწორად მუშაობს (301 კოდი), უბრალოდ დაელოდეთ. Google თანდათანობით ყველა გვერდს ახალ ვერსიაზე გადაინდექსებს
• sitemap.xml მხოლოდ HTTPS ვერსიისთვის გაგზავნეთ
• Search Console-ში „მისამართის შეცვლა" ფუნქცია გამოიყენეთ (თუ დომენებს შორის გადაადგილება მოხდა)

სრული გადასვლა, როგორც წესი, 2 კვირიდან 2 თვემდე გრძელდება, საიტის ზომის მიხედვით.

2. PageSpeed Insights მობილური ვერსიისთვის 48 ქულას იძლევა „გამოუყენებელი JavaScript"-ის გამო, მაგრამ ამ სკრიპტების გამორთვა ფუნქციონალს გატეხავს. რა არის მნიშვნელოვანი რეიტინგისთვის — სიჩქარე თუ სამუშაოუნარიანობა?

ეს საიტების აუდიტის ერთ-ერთი ყველაზე ხშირი დილემაა.

მოკლე პასუხი: სამუშაოუნარიანობა ყოველთვის PageSpeed Insights-ის ქულაზე მნიშვნელოვანია.

დეტალური განმარტება:

Google სიჩქარეს რეიტინგის ფაქტორად იყენებს, მაგრამ ეს ერთადერთი და ძირითადი ფაქტორიც კი არ არის. 48 ქულიანი საიტი შესანიშნავი კონტენტით და კარგი მომხმარებლის გამოცდილებით, 95 ქულიანი, მაგრამ უსარგებლო კონტენტის მქონე საიტზე უკეთ დაირეიტინგება.

სწორი სტრატეგია:

1. სრულყოფილ ქულას ნუ ეჭერიხართ. 48 ქულა კატასტროფა არ არის, განსაკუთრებით თუ ის საჭირო ფუნქციონალით (კალათა, კალკულატორი, ფორმები) არის გამოწვეული. 60-70 ქულისკენ ისწრაფვოდეთ — ეს უკვე კარგი შედეგია.
2. ოპტიმიზაცია ფუნქციონალის გატეხვის გარეშე:
   • არაპრიორიტეტული სკრიპტების ჩატვირთვა გადადეთ defer ან async ატრიბუტით
   • მძიმე ბიბლიოთეკები (რუქები, სოციალური ქსელების ვიჯეტები) მხოლოდ მაშინ ჩატვირთეთ, როცა მომხმარებელი მათამდე გადაახვევს
   • JS ფაილები მინიფიკაციას გაუკეთეთ
   • ბიბლიოთეკების გამოუყენებელი ნაწილების ამოსაღებად tree-shaking გამოიყენეთ
3. ფოკუსირდით Core Web Vitals-ის რეალურ მეტრიკებზე:
   • LCP (Largest Contentful Paint) — ძირითადი კონტენტის ჩატვირთვის დრო (მიზანი: < 2,5 წმ)
   • INP (Interaction to Next Paint) — ინტერაქციის შემდეგ დაყოვნება (მიზანი: < 200 მწ). ეს მეტრიკა 2024 წლის მარტში ოფიციალურად ჩაანაცვლა მოძველებულ FID-ს.
   • CLS (Cumulative Layout Shift) — ვიზუალური ჩატვირთვის სტაბილურობა (მიზანი: < 0,1)

   ეს მეტრიკები PageSpeed-ის საბოლოო ქულაზე მნიშვნელოვანია.

50-60 ქულიანი საიტი სწრაფი LCP-ით (2 წამი) შესანიშნავად დაირეიტინგება. ხოლო 90 ქულიანი საიტი, მაგრამ LCP-ით 5 წამი (მთავარ გვერდზე მძიმე სლაიდერის გამო) — გაიძულება.

3. W3C ვალიდატორი 200+ გაფრთხილებას აჩვენებს, ძირითადად CMS შაბლონის მოძველებული ატრიბუტების გამო. მთელი კოდის გადაწერა სჭირდება თუ Google მხოლოდ კრიტიკულ შეცდომებს, მაგ. დაუხურავ თეგებს, ყურადღებას აქცევს?

Google W3C-ს ვალიდურობას კი არ უყურებს, არამედ გვერდის სწორად დამუშავების შესაძლებლობას.

კრიტიკული შეცდომები (გამოსასწორებელია):

• დაუხურავი თეგები (

  <div>

  დამხურავი

  </div>

  -ის გარეშე)
• არასწორი ბუდობა (მაგ.

  <p>

  სხვა

  <p>

  -ს შიგნით)
• ელემენტების ID-ების დუბლიკატები
• ცხრილების არასწორი სტრუქტურა
• სავალდებულო ატრიბუტების არარსებობა (მაგ. alt მნიშვნელოვანი სურათებისთვის)

ეს შეცდომები ბრაუზერსა და საძიებო ბოტს გვერდის სტრუქტურის სწორად გაგებაში ხელს უშლის.

არაკრიტიკული გაფრთხილებები (შეიძლება დარჩეს):

• მოძველებული ატრიბუტები (მაგ. align, valign — მუშაობს, უბრალოდ არ არის რეკომენდებული)
• W3C-ს მიერ არაღიარებული ექსპერიმენტული HTML5 ელემენტები
• CSS-ის თვისებებზე გაფრთხილებები
• Vendor-პრეფიქსები

თუ 200 გაფრთხილება CMS-ის შაბლონის (მაგ. WordPress, Joomla) მოძველებული ატრიბუტების გამო გაქვთ, ყველაფრის გადაწერა სავალდებულო არ არის.

რა გავაკეთოთ:

1. შეამოწმეთ კრიტიკული შეცდომების არსებობა. W3C ვალიდატორის ანგარიშში ისინი ჩვეულებრივ წითლად არის გამოყოფილი.
2. კრიტიკული შეცდომები გამოასწორეთ (დაუხურავი თეგები, არასწორი ბუდობა).
3. Search Console-ში რენდერინგი შეამოწმეთ. „URL შემოწმება" ინსტრუმენტი გამოიყენეთ — თუ Google კონტენტს სწორად ხედავს, ყველაფერი რიგშია.
4. კოსმეტიკურ გაფრთხილებებზე დროს ნუ კარგავთ, თუ ფუნქციონალი მუშაობს.

გამონაკლისი: თუ საიტს ნულიდან ქმნით, დაუყოვნებლივ თანამედროვე სტანდარტებს მიჰყევით — ეს მომავალში მხარდაჭერას გაამარტივებს.

4. საიტის ტექსტი AJAX-ით იტვირთება 0,5 წამის დაყოვნებით გლუვი ანიმაციისთვის. Search Console-ის „URL შემოწმებაში" ტექსტი ჩანს, მაგრამ იღებს თუ არა ის ინდექსში იგივე წონას, რაც სუფთა HTML-ის კონტენტს?

Google-ის ოფიციალური პოზიცია: ბოტს JavaScript-ის შესრულება და დინამიური კონტენტის ინდექსირება შეუძლია, მაგრამ მნიშვნელოვანი ნიუანსები არსებობს.

რეალობა:

1. Google-ს JS-ის შესასრულებლად შეზღუდული ტაიმაუტი აქვს — ჩვეულებრივ დაახლოებით 5 წამი. თქვენი 0,5 წმ დაყოვნება ეტევა, მაგრამ:
   • თუ გვერდზე ბევრი სკრიპტია, ბოტმა შეიძლება ვერ დაელოდოს
   • თუ დაყოვნება გარე ფაქტორებზეა დამოკიდებული (ნელი სერვერი, API), ბოტმა შეიძლება კონტენტი ვერ დაინახოს
2. ორფაზიანი ინდექსირება. Google პირველ რიგში HTML-ს ინდექსირებს, შემდეგ გარკვეული ხნის (საათები/დღეები) შემდეგ JS-ის სარენდერინგებლად ბრუნდება. თუ თქვენი კონტენტი გვერდის თემის გაგებისთვის კრიტიკულად მნიშვნელოვანია, ინდექსირებაში დაყოვნება ზიანს მიაყენებს.
3. კონტენტის წონა. თუ „URL შემოწმება" ტექსტს აჩვენებს, ის ინდექსში მოხვდება. თუმცა ოფიციალური დადასტურება არ არსებობს, რომ დინამიური კონტენტს სტატიკური HTML-ისა და ერთი და იმავე წონა ჰქონდეს. ჩვენი აზრით, სხვაობა თუ არსებობს, მინიმალურია.

ჩვენი რეკომენდაცია:

• კრიტიკულად მნიშვნელოვანი კონტენტი (H1-H6 სათაურები, ძირითადი ტექსტი, პირველი ეკრანი) სუფთა HTML-ში უნდა იყოს.
• დამატებითი კონტენტი (მიმოხილვები, კომენტარები, დაკავშირებული სტატიები) AJAX-ით შეიძლება ჩაიტვირთოს.
• თუ ანიმაცია UX-სთვის მნიშვნელოვანია, დატოვეთ, მაგრამ კონტენტი HTML-ში ფარული სახით (მაგ.

  display: none

  გამოჩენის ანიმაციის შემდეგ) მაინც დარჩეს.

შემოწმება:

1. გვერდი „კოდის ნახვა" რეჟიმში გახსენით (Ctrl+U ბრაუზერში)
2. მნიშვნელოვანი ტექსტი ძიებით (Ctrl+F) იპოვეთ
3. თუ ტექსტი საწყის HTML-ში არ არის — ეს ნიშნავს, რომ JS-ით იტვირთება

თუ ტექსტი JS-ით იტვირთება და ეს ბიზნესისთვის კრიტიკულია, განიხილეთ სერვერული რენდერინგი (SSR) ან ჩატვირთვის ლოგიკა გადააკეთეთ.

5. ჩემს ბლოგში 500 სტატიაა, 50 პაგინაციის გვერდად გაყოფილი. Google მხოლოდ პირველ 10 გვერდს ინდექსირებს. ეს crawling-ის ბიუჯეტის პრობლემაა თუ პაგინაციის ღრმა გვერდები საერთოდ ინდექსში ვერ ხვდება?

ეს ტიპური სიტუაციაა დიდი ბლოგებისა და კატალოგებისთვის.

პრობლემა არ არის ის, რომ Google-მა პაგინაციის ღრმა გვერდები არ უნდა დაინდექსოს, არამედ ის, რომ შეიძლება ამის crawling-ის ბიუჯეტი ან მოტივაცია არ ჰქონდეს. 2026 წელს Google კიდევ უფრო იშვიათად ასკანირებს პაგინაციის ღრმა გვერდებს.

რა არის crawling-ის ბიუჯეტი:

ეს გვერდების პირობითი რაოდენობაა, რომლის განხილვასაც Google გარკვეული პერიოდის განმავლობაში ემზადება. მცირე საიტებისთვის (10 000 გვერდამდე) ეს ჩვეულებრივ პრობლემა არ არის, მაგრამ დიდებისთვის — შეიძლება იყოს.

რატომ ჩერდება Google პაგინაციის მე-10 გვერდზე:

1. ღრმა გვერდების დაბალი ღირებულება. Google იცის, რომ მომხმარებლების უმეტესობა 2-3 გვერდს არ სცდება, ამიტომ პირველი გვერდების ინდექსირება პრიორიტეტული ხდება.
2. Crawling-ის პრობლემები. შეამოწმეთ:
   • პაგინაციის ღრმა გვერდებზე ბმულები HTML კოდში არის (მხოლოდ JS-ით ხომ არ გენერირდება)
   • ეს გვერდები robots.txt-ში ხომ არ არის დახურული
   • აბრუნებს თუ არა 200 კოდს (არა 404, არა 302)
3. შიდა ლინქბილდინგის არარსებობა. თუ 40-50 პაგინაციის გვერდებზე მე-39 გვერდიდან გარდა სხვა ბმული არ არის, Google შეიძლება ვერ იპოვოს.

გამოსავლები:

1. პაგინაციის ყველა გვერდი sitemap.xml-ში დაამატეთ — ეს Google-ს სიგნალს მოახდენს, რომ ისინი მნიშვნელოვანია.
2. შიდა ლინქბილდინგი გააუმჯობესეთ:
   • პაგინატორი ნახტომებით დაამატეთ (1, 2, 3 ... 25, 26, 27 ... 48, 49, 50)
   • შექმენით „სტატიების არქივის" გვერდი ყველა პაგინაციის გვერდზე ბმულებით
   • კატეგორიები ან ტეგები დაამატეთ, რომლებიც 500 სტატიას უფრო მცირე ჯგუფებად დაყოფს
3. ინდექსირების პრიორიტეტი გაზარდეთ:
   • საიტის სიჩქარე გაზარდეთ (ნელი საიტები ნაკლებ crawling ბიუჯეტს იღებს)
   • ყველა 404 შეცდომა, დუბლიკატი, გადამისამართება გამოასწორეთ — ისინი crawling-ის ბიუჯეტს „ჭამს"
4. კლასიკური პაგინაციის ალტერნატივა განიხილეთ:
   • Infinite scroll სწორი განხორციელებით (ყოველი სტატუსისთვის URL)
   • სტატიების უფრო დეტალური კატეგორიზება

მნიშვნელოვანია: თუ პირველი 10 გვერდი ინდექსირდება, ეს უკვე 100 სტატიაა. დარწმუნდით, რომ დანარჩენი 400 სტატია სხვა სექციებიდან (კატეგორიები, ტეგები, საიტის ძიება) ხელმისაწვდომია.

6. Canonical ყველა გვერდზე სწორად მიუთითებს, მაგრამ Search Console წერს „გვერდი დუბლიკატია, სხვა გვერდი შეირჩა". რატომ უგულებელყოფს Google ჩემს canonical-ს და შეიძლება ამის გამოსწორება?

ეს SEO სპეციალისტების ერთ-ერთი ყველაზე ხშირი „ტკივილია". გავარკვიოთ, რატომ ხდება ეს.

მნიშვნელოვანია გავიგოთ: canonical — ეს დირექტივა კი არ არის, არამედ რეკომენდაცია.

Google-მა შეიძლება თქვენი canonical უგულებელყოს, თუ ჩათვლის, რომ სხვა გვერდი ინდექსისთვის უფრო შესაფერისია. ამას „Google-selected canonical" (Google-ის მიერ არჩეული კანონიკური URL) ეწოდება.

მიზეზები, რატომ უგულებელყოფს Google თქვენს canonical-ს:

1. გვერდები მართლაც დუბლიკატია.
   • შეამოწმეთ, ორივე გვერდის კონტენტი იდენტურია თუ არა
   • შესაძლოა canonical არასწორად მიუთითებს (შედარებითი და არა აბსოლუტური URL)
   • Canonical შეიძლება სხვა სიგნალებთან (მაგ. hreflang) კონფლიქტშია
2. გადამისამართებები canonical-ს ეწინააღმდეგება.
   თუ canonical A გვერდს მიუთითებს, მაგრამ B გვერდზე გადამისამართება არსებობს, Google გაიბნევა
3. გარე და შიდა ბმულები სხვა ვერსიაზე მიდის.
   თუ საიტის ყველა ბმული /page/-ზე მიდის, canonical კი /page-ზე მიუთითებს, Google შეიძლება /page/-ს, როგორც პოპულარულ ვერსიას, აირჩევს
4. Sitemap.xml კანონიკურ-არარსებულ ვერსიას შეიცავს.
   შეამოწმეთ, sitemap.xml-ში მხოლოდ კანონიკური URL-ებია
5. მობილური ვერსიის პრობლემები.
   თუ მობილური და დესკტოპის ვერსიები ძლიერ განსხვავდება, Google შეიძლება სხვა გვერდი კანონიკურად აირჩიოს

გამოსწორება:

1. Search Console → Coverage → „Excluded" → „Duplicate, submitted URL not selected as canonical" პრობლემის კონკრეტული URL-ები იპოვეთ.
2. ორივე გვერდი შეადარეთ (ის, რომელიც canonical-ში მიუთითეთ, და ის, რომელიც Google-მა აირჩია):
   • კონტენტი იდენტურია?
   • რომელ ვერსიას მეტი შიდა ბმული ჰყავს?
   • რომელი ვერსიაა sitemap.xml-ში?
3. ყველა სიგნალი გაამთლიანეთ:
   • Canonical სასურველ ვერსიაზე უნდა მიუთითებდეს
   • ყველა შიდა ბმული ამ ვერსიაზე უნდა მიდიოდეს
   • sitemap.xml-ში მხოლოდ ეს ვერსია უნდა იყოს
   • ყველა ალტერნატიული ვერსიიდან 301 გადამისამართება დააყენეთ
4. დაელოდეთ. გამოსწორების შემდეგ Google-ს გვერდების გადაინდექსირება 2-4 კვირა სჭირდება.

როდის არ ღირს ნერვიულობა:

თუ Google-მა კანონიკურ გვერდად ის ვერსია აირჩია, რომელიც თქვენთვის მისაღებია (მაგ. HTTPS HTTP-ის ნაცვლად, სლეშის გარეშე სლეშიანის ნაცვლად) და კონტენტი იდენტურია — პრობლემა არ არის. უბრალოდ Google-მა გადაწყვეტილება თქვენს მაგიერ მიიღო.

7. robots.txt-ში /admin/ დირექტორია ინდექსირებისთვის დავხურე, მაგრამ სერვერის ლოგებში ვხედავ, რომ Googlebot ამ URL-ებზე მაინც მიდის. ეს ნიშნავს, რომ ფაილი არ მუშაობს, თუ ბოტი დაბლოკილ გვერდებზეც ხელმისაწვდომობას ამოწმებს?

მნიშვნელოვანი წესი: robots.txt კრძალავს ინდექსირებას, მაგრამ არ კრძალავს crawling-ს (დათვალიერებას).

რას ნიშნავს ეს:

• ინდექსირება — ეს არის გვერდის Google-ის მონაცემთა ბაზაში შინაარსიანად დამატება.
• Crawling — ეს არის ბოტის ტექნიკური ვიზიტი ბმულების, გადამისამართებებისა და სხვა სიგნალების შესამოწმებლად.

თუნდაც გვერდი robots.txt-ში დახურული იყოს:

• Googlebot-ს შეიძლება მიმართოს (ლოგებში ამას დაინახავთ)
• Google შეიძლება robots.txt-ის წესები შეიცვალა თუ არა შეამოწმებს
• Googlebot-ს შეიძლება ამ გვერდიდან გადამისამართებები შეამოწმოს

მაგრამ გვერდის შინაარსი ინდექსირებული არ იქნება.

robots.txt-ის სწორი კონფიგურაცია შეამოწმეთ:

User-agent: *
Disallow: /admin/

დარწმუნდით:

• ბოლო სლეში (/admin/) — /admin/-ით დაწყებულ ყველაფერს ხურავს
• ფაილი ხელმისაწვდომია https://site.ge/robots.txt-ზე
• სინტაქსური შეცდომები არ არის

robots.txt-ის მუშაობის შემოწმება:

1. Google Search Console-ში გადადით → „URL შემოწმება"
2. შეიყვანეთ /admin/ დირექტორიის ნებისმიერი URL
3. „URL-ის შემოწმება" დააჭირეთ
4. თუ „URL robots.txt ფაილით არის დაბლოკილი" გამოჩნდა — ყველაფერი სწორად მუშაობს

როდის არ მუშაობს დაბლოკვა:

თუ /admin/page-ზე სხვა საიტებიდან გარე ბმულები არსებობს, Google-მა შეიძლება ის ინდექსში დაამატოს crawling-ის გარეშეც, URL-ს აღწერის გარეშე ჩვენებით (ამას „soft indexing" ეწოდება).

სრული დაცვის გამოსავალი:

თუ დირექტორია მართლაც სრულად დამალვა გჭირდებათ:

1. robots.txt-ში დახურეთ (ინდექსირებისაგან)
2. .htaccess-ით ან სერვერის კონფიგურაციით პაროლით დახურეთ (წვდომისაგან)
3. დირექტორიის ყველა გვერდზე დაამატეთ

   <meta name="robots" content="noindex, nofollow" />

   (ორმაგი დაცვა)

8. ჩემს sitemap-ში 8000 URL-ია, მაგრამ რეკომენდაცია — 50 000-ზე ნაკლები. ახლავე რამდენიმე ფაილად გავყო თუ მხოლოდ მაშინ, როცა URL-ების რაოდენობა გარკვეულ ზღვარს გადაცდება?

Google-ის ოფიციალური ლიმიტები:

• ერთ sitemap.xml-ში მაქსიმუმ 50 000 URL
• ფაილის მაქსიმალური ზომა — 50 MB (შეუკუმშავი)

8000 URL-ით ლიმიტიდან შორს ხართ, მაგრამ ნიუანსები არსებობს.

როდის ღირს ახლავე sitemap-ის დაყოფა:

1. სხვადასხვა ტიპის კონტენტი.
   თუ გაქვთ:
   • 3000 პროდუქტის გვერდი
   • 2000 ბლოგის სტატია
   • 2000 კატეგორია
   • 1000 სერვისის გვერდი
   სჯობს ყოველი ტიპისთვის ცალ-ცალკე sitemap შეიქმნას:

   • sitemap-products.xml

   • sitemap-blog.xml

   • sitemap-categories.xml

   ეს მართვასა და Search Console-ში ინდექსირების თვალყურის დევნებას გაამარტივებს.
2. განახლების სხვადასხვა სიხშირე.
   • პროდუქტები ყოველდღე ახლდება →

     sitemap-products.xml

     (ხშირად Google-ზე გაგზავნეთ)
   • სტატიები კვირაში ერთხელ ემატება →

     sitemap-blog.xml

   • სტატიკური გვერდები არ იცვლება →

     sitemap-static.xml

3. ფაილის ზომა 10 MB-ს უახლოვდება.
   8000 URL-ისასაც კი, თუ ყოველ ელემენტს სურათები აქვს (თეგები

   <image:image>

   ), ფაილი მძიმე შეიძლება იყოს.

როდის შეიძლება ერთი ფაილი დარჩეს:

• თუ ყველა 8000 URL დაახლოებით ერთი ტიპისაა (მაგ. მხოლოდ ბლოგის სტატიები)
• თუ საიტი ნელა იზრდება (წელიწადში 100-200 გვერდი)
• თუ ფაილი 5 MB-ზე ნაკლებია

სწორი გაყოფა:

შექმენით sitemap ინდექსი (

sitemap-index.xml

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex 
  xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://site.ge/sitemap-products.xml</loc>
    <lastmod>2026-02-15</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://site.ge/sitemap-blog.xml</loc>
    <lastmod>2026-02-14</lastmod>
  </sitemap>
</sitemapindex>

Search Console-ში მხოლოდ ინდექსური ფაილი გაგზავნეთ.

ჩვენი რეკომენდაცია:

თუ საიტის აქტიური ზრდა იგეგმება (მომავალ წელს 20 000-ზე მეტი URL), sitemap ახლავე გაყავით. ეს მომავალში მართვას გაამარტივებს. თუ საიტი სტაბილურია — ერთი ფაილი დატოვეთ და 15-20 ათასი URL-ის მიღწევისას გაყავით.

9. საიტი ადაპტიურია, მაგრამ Google Search Console ზოგიერთ გვერდზე „კონტენტი ეკრანზე განიე" შეცდომებს გვაჩვენებს. როგორ ვიპოვო კონკრეტული ელემენტები, რომლებიც ამ პრობლემას იწვევს, თუ ვიზუალურად ყველაფერი ნორმალურად გამოიყურება?

მობილური ვერსიასთან მუშაობის ხშირი „ტკივილი".

„კონტენტი ეკრანზე განიე" შეცდომის მიზეზები:

• სურათები viewport-ზე დიდი ფიქსირებული სიგანით
• ადაპტიური გარსის გარეშე ცხრილები
• width: 1000px ან ეკრანზე დიდი min-width-ის მქონე ბლოკები
• ელემენტები პიქსელებში უარყოფითი margin ან padding-ით
• Responsive გარსის გარეშე ჩასმული ვიდეო ან რუქები

ცხრილებისთვის:

<div style="overflow-x: auto;">
  <table>...</table>
</div>

ჩასმული iframe-ებისთვის (ვიდეო, რუქები):

<div style="position: relative; 
  padding-bottom: 56.25%; height: 0;">
  <iframe src="..." style="position: absolute; 
    top: 0; left: 0; width: 100%; height: 100%;">
  </iframe>
</div>

გამოსწორების შემდეგ:

1. ემულაციის რეჟიმში ხელახლა შეამოწმეთ
2. 1-2 კვირის შემდეგ Search Console-ში „URL შემოწმება" → გადაინდექსირება მოითხოვეთ
3. შეცდომა „Coverage" ანგარიშიდან 2-4 კვირაში გაქრება

10. Product მარკირება ფასითა და რეიტინგით დავამატე, მაგრამ ძიების შედეგებში ვარსკვლავები არ ჩნდება. Schema.org ვალიდატორი გვიჩვენებს, რომ ყველაფერი სწორია. რაზეა დამოკიდებული, Google-მა ფართო სნიპეტი ჩვენება გადაწყვიტოს?

მნიშვნელოვანია გავიგოთ: ვალიდური მარკირება ≠ ფართო სნიპეტის ჩვენების გარანტია.

Google მიკრომარკირებას rich snippet-ის ჩვენების შესაძლებლობად იყენებს, მაგრამ ვალდებული არ არის ამ ჩვენოს.

რატომ შეიძლება Google-მა ფართო სნიპეტი არ ჩვენოს:

1. გვერდი ახლახანს ინდექსირდა
   • Rich snippets-ის გამოჩენისთვის ჩვეულებრივ ინდექსირებიდან 2-4 კვირაა საჭირო
   • Google ჩვენებას თანდათანობით ტესტავს
2. მარკირებაში მონაცემები არ არის საკმარისი

   პროდუქტებისთვის (Product) სავალდებულო ველები:

   • name — პროდუქტის სახელი
   • image — სურათი
   • offers ველებით:
     • price — ფასი
     • priceCurrency — ვალუტა (GEL, USD)
     • availability — ხელმისაწვდომობა

   ვარსკვლავების ჩვენებისთვის დამატებით საჭიროა:

   • aggregateRating — საშუალო რეიტინგი
     • ratingValue — შეფასება (მაგ. 4.5)
     • reviewCount — მიმოხილვების რაოდენობა (მინიმუმ 1)
3. მიმოხილვები არ არის საკმარისი

   Google შეიძლება ვარსკვლავები არ აჩვენოს, თუ:

   • 5-ზე ნაკლები მიმოხილვაა
   • ყველა მიმოხილვა ერთი და იმავე რეიტინგისაა (საეჭვოდ გამოიყურება)
   • მიმოხილვები ძალიან სწრაფად დაემატა (ყველა ერთ დღეში)
4. Rich snippets-ზე კონკურენცია

   თუ თქვენი მოთხოვნის მიხედვით უკვე 2-3 ფართო სნიპეტიანი შედეგია, Google შეიძლება თქვენს ვარიანტს არ აჩვენებდეს, გაცემის გასამრავალფეროვნებლად.

5. სპამი ან მანიპულაცია

   Google-მა შეიძლება მარკირება უგულებელყოს, თუ:

   • გვერდზე და მარკირებაში რეიტინგი არ ემთხვევა
   • მიმოხილვები აშკარად ყალბია
   • მარკირება გვერდზე გამოყენებულია, რომელიც პროდუქტი არ არის (მაგ. მთავარ გვერდზე)
6. რეგიონული თავისებურებები

   Rich snippets შეიძლება ერთ რეგიონში ჩნდებოდეს და სხვაში არ ჩნდებოდეს. გაიდეთ გამოცდა სწორედ სამიზნე რეგიონიდან (VPN ან ძიებაში

   &gl=XX

   პარამეტრი გამოიყენეთ).

ჩვენება-ს შანსების გასაზრდელად:

1. მარკირების სისწორე შეამოწმეთ:
   Rich Results Test (ვალიდატორის ახალი ვერსია) გამოიყენეთ
2. რეალური მიმოხილვები დაამატეთ:
   • მინიმუმ 5-10 მიმოხილვა
   • სხვადასხვა თარიღებით
   • სხვადასხვა შეფასებებით (ძირითადად 4-5 ვარსკვლავი, მაგრამ 3 ვარსკვლავიც უნდა ეყოს)
3. მარკირებისა და ვიზუალის შესაბამისობა შეამოწმეთ:
   • თუ მარკირებაში 4.8 ვარსკვლავია, გვერდზე ამ რეიტინგის ვიჯეტი უნდა იყოს
   • მარკირებაში ფასი = გვერდზე ფასი
4. გადაინდექსირება მოითხოვეთ:
   Search Console → URL შემოწმება → „ინდექსირების მოთხოვნა"
5. ყველა გამოსწორების შემდეგ 4-6 კვირა დაელოდეთ.

Google-ი მარკირებას ხედავს თუ არა შემოწმება:

Search Console → „Enhancements" → „Products"
აქ გამოჩნდება Product მარკირების მქონე ყველა გვერდი და შესაძლო შეცდომები.

11. საიტზე სამი ენაა: ქართული (ძირითადი), რუსული და ინგლისური. hreflang-ში x-default თეგი უნდა დაემატოს და რომელ ენობრივ ვერსიაზე უნდა მიუთითებდეს — ქართულზე ან ენის შერჩევის ცალკე გვერდი შეიქმნას?

ყველაფერი მაქსიმალურად მარტივია. x-default — ეს გვერდია, რომელსაც Google ნებისმიერ მომხმარებელს აჩვენებს, რომლის ენა თქვენ პარამეტრებში არ გაქვთ გათვალისწინებული.

კონკრეტული ენის არჩევა ამ ატრიბუტისთვის მხოლოდ იმაზეა დამოკიდებული, ვინ არის თქვენი ძირითადი კლიენტი:

1. ინგლისური x-default-ში აირჩიეთ, თუ:

თქვენი საიტი მთელ მსოფლიოზეა ორიენტირებული.

• ლოგიკა: ინგლისური საერთაშორისო ენაა. თუ საიტზე შვედი, ჩინელი ან თურქი შემოვა, მათ ინგლისურის გაგება ნებისმიერ სხვა ლოკალურ ენაზე უფრო ადვილია.
• ვისთვის ვარგა: სასტუმროები, ექსპორტის კომპანიები, IT-სერვისები, საერთაშორისო ბლოგები.

2. ქართული (ადგილობრივი) x-default-ში აირჩიეთ, თუ:

თქვენი ბიზნესი კონკრეტულ ქვეყანასთანაა დაკავშირებული.

• ლოგიკა: თქვენი სერვისი მხოლოდ საქართველოში ხორციელდება. თუ უცხოელი ქვეყანაში რაიმეს ეძებს, ადგილობრივი მონაცემებით საიტის „ორიგინალური" ვერსია უნდა დაინახოს, თუნდაც ენა არ ესმოდეს (ბრაუზერი ავტო-თარგმანს შეთავაზებს).
• ვისთვის ვარგა: ქალაქში კვების მიწოდება, ადგილობრივი იურიდიული სერვისები, სახელმწიფო სერვისები, მხოლოდ ადგილობრივი ინტერნეტ-მაღაზია.

3. რუსული x-default-ში აირჩიეთ, თუ:

თქვენი აუდიტორია — დსთ-ს ქვეყნებია.

• ლოგიკა: თუ ყაზახეთზე, სომხეთსა და უზბეკეთზე ყიდით, მაგრამ ამ ეროვნულ ენებზე ვერსიები არ გაქვთ, რუსული ამ რეგიონისთვის საუკეთესო „საერთო მნიშვნელი" იქნება.
• ვისთვის ვარგა: საბითუმო ვაჭრობა დსთ-ს ფარგლებში, რეგიონული მედიარესურსები.

5 წამში გადაწყვეტა?

დაუსვით საკუთარ თავს კითხვა: „რა ენაზე ლაპარაკობს ჩემი „შემთხვევითი" ვიზიტორი, რომლის ენაც მე არ გავითვალისწინე?"

• თუ ეს „მსოფლიოს ადამიანია" — ინგლისური ჩადეთ.
• თუ ეს „ადამიანია, რომელიც ახლა ჩემს ქვეყანაში იმყოფება" — ადგილობრივი ენა ჩადეთ.

ტექნიკური წესი: x-default-ში ყოველთვის ის ვერსიის ბმული ჩადეთ, რომელიც თქვენს hreflang-ის სიაში უკვე არსებობს.

დამატებითი რჩევები:

1. ბრაუზერის ენის ავტო-განსაზღვრება:
   JavaScript გამოიყენეთ პირველი ვიზიტისას შესაბამის ვერსიაზე ავტომატური გადამისამართებისთვის (მაგრამ ყოველ ჯერ ენის შერჩევის გვერდი ნუ გამოჩნდება).
2. ყველა გვერდზე ენების შეცვლა:
   საიტის სათაურში ყველა გვერდზე ხილული ენის შეცვლის ღილაკები/დროშები უნდა იყოს.
3. hreflang-ის შემოწმება:
   სწორი კონფიგურაციის შემოწმებისთვის Hreflang Tags Testing Tool გამოიყენეთ.
4. Search Console:
   „International Targeting" სექცია შეამოწმეთ — იქ hreflang-ის შეცდომები გამოჩნდება, თუ არსებობს.

მოსარიდებელი შეცდომები:

• ჩაკეტილი წრე ნუ შექმნათ: ka მხოლოდ ka-ს ასახავს, ru მხოლოდ ru-ს — ყველა ვერსია ყველას უნდა ასახავდეს
• self-referencing ნუ დაგავიწყდებათ — ყოველი გვერდი საკუთარ თავს ასახავს
• დარწმუნდით, hreflang-ის ყველა URL ხელმისაწვდომია (200 კოდს აბრუნებს, არა 404 ან 301)

12. Alt ატრიბუტები ყველა სურათს დაემატა, მაგრამ Google Images ძიებაში ჩემი ფოტოები არ ჩნდება. ეს სურათების ოპტიმიზაციის (ზომა, ფორმატი) პრობლემაა, თუ ინდექსირებიდან ჯერ საკმარისი დრო არ გასულა?

Google Images-ი ძიება — ეს ცალკე სისტემაა თავისი წესებით. განვიხილოთ ყველა ფაქტორი.

ინდექსირების დრო:

Google Images-ში გამოჩენისთვის ჩვეულებრივ საჭიროა:

• ახალი საიტისთვის 2-4 კვირა
• კარგი რეპუტაციის მქონე არსებული საიტისთვის 1-2 კვირა

თუ ერთ თვეზე ნაკლები გავიდა, დაელოდეთ.

Google Images-ში რეიტინგის ფაქტორები:

1. სურათის ხარისხი და ოპტიმიზაცია
   • ფორმატი: JPEG ფოტოებისთვის, PNG გრაფიკისთვის, WebP თანამედროვე საიტებისთვის
   • ზომა: მინიმუმ 300x300 პიქსელი (სასურველია 800x600+)
   • წონა: 200 KB-ზე ნაკლები (TinyPNG-ით ოპტიმიზება)
   • ფაილის სახელი: tsiteli-divani.jpg, და არა IMG_12345.jpg
2. Alt ატრიბუტი (სწორი)

   alt-ის უბრალოდ დამატება საკმარისი არ არის — ის აღწერითი და უნიკალური უნდა იყოს:

   ❌ ცუდია:

   alt="სურათი"

   
   ❌ ცუდია:

   alt="პროდუქტი"

   
   ✅ კარგია:

   alt="სკანდინავიური სტილის წითელი ტყავის დივანი"

3. სურათის გარშემო კონტექსტი

   Google ყურადღებას აქცევს:

   • გვერდის სათაურს (H1)
   • სურათის გარშემო ტექსტს (50-100 სიტყვის რადიუსი)
   • სურათის ქვეწარწერას (

     <figcaption>

     თუ

     <figure>

     გამოიყენება)

   თუ სავარძლის სურათი მაგიდების გვერდზეა, Google გაიბნევა.

4. ტექნიკური ხელმისაწვდომობა
   • სურათი robots.txt-ში არ უნდა იყოს დახურული
   • სურათიანი გვერდი ინდექსირებული უნდა იყოს
   • სურათი შეცდომების გარეშე უნდა ჩაიტვირთოს (არა 404)
   • სურათის გზა HTML-ში უნდა იყოს (მხოლოდ CSS background-image-ის გარეშე)
5. სტრუქტურირებული მონაცემები (სავალდებულო არ არის, მაგრამ ეხმარება)

   პროდუქტებისთვის JSON-LD ფორმატში სურათიანი მიკრომარკირება დაამატეთ.

სურათების ინდექსირების შემოწმება:

1. URL-ით ძიება:
   Google Images-ში შეიყვანეთ:

   site:site.ge/images/

   
   ეს თქვენი საიტის ყველა ინდექსირებულ სურათს აჩვენებს.
2. Search Console:
   სამწუხაროდ, Search Console სურათების სტატისტიკას პირდაპირ არ აჩვენებს, მაგრამ შეგიძლიათ სურათების განთავსების გვერდების ინდექსირება შეამოწმოთ.
3. Google Lens:
   თქვენი სურათი Google Lens-ში ჩატვირთეთ — თუ Google-მა ის ამოიცნო, მსგავს შედეგებს ნახავთ.

ტიპური პრობლემები:

• Lazy Load არასწორად კონფიგურირებულია — Google JS-ით ჩატვირთულ სურათებს ვერ ხედავს
• სურათების დუბლიკატები — ერთი და იგივე სურათი საიტის 10 გვერდზე
• დაბალი ხარისხი — ბუნდოვანი, პატარა სურათები ინდექსირებული არ არის
• სურათების sitemap-ის არარსებობა — შექმენით ცალ image-sitemap.xml

რა გავაკეთოთ:

1. სურათები ოპტიმიზება გაუკეთეთ (ზომა, წონა, ფაილის სახელები)
2. alt ატრიბუტები გააუმჯობესეთ (უნიკალური, აღწერითი)
3. სურათების გარშემო კონტექსტი დაამატეთ (ტექსტი, სათაურები)
4. image sitemap შექმენით
5. 4-6 კვირა დაელოდეთ
6. site:site.ge/images/-ის გამოყენებით Google Images-ში შეამოწმეთ

13. Search Console დაკავშირებულია, მაგრამ „მონაცემები მუშავდება" უკვე ერთ კვირაა. ახალი საიტისთვის ეს ნორმალური ლოდინის დროა, თუ საკუთრების დადასტურების კონფიგურაციაში შეცდომაა?

ნუ ინერვიულებთ — ახალი საიტისთვის ეს სრულიად ნორმალური სიტუაციაა.

Search Console-ში მონაცემების გამოჩენის ტიპური ვადები:

• ახალი საიტისთვის (დომენი 3 თვეზე ნაკლები): 7-14 დღე
• არსებული საიტისთვის ხელახლა მიერთებისას: 2-3 დღე
• რედიზაინის შემდეგ: 3-5 დღე

რატომ სჭირდება ამდენი დრო:

Google-ს სჭირდება:

1. თქვენი საიტის აღმოჩენა (sitemap-ის ან სხვა საიტებიდან ბმულების გამოყენებით)
2. ძირითადი გვერდების მოვლა
3. კონტენტის ინდექსირება
4. ჩვენებებისა და კლიკების სტატისტიკის დაგროვება

ახალი საიტისთვის, რომელსაც ძიებაში ჯერ პოზიციები არ აქვს, პროცესი უფრო ნელა მიდის.

ყველაფერი სწორად კონფიგურირებულია თუ შემოწმება:

1. საკუთრების დადასტურება

   Search Console → Settings → „Ownership verification"-ზე გადადით
   დადასტურების თარიღით მწვანე ჩამრთველი უნდა იყოს.

   თუ არ არის — ერთ-ერთი გზით ხელახლა დაადასტურეთ:

   • HTML ფაილი
   • HTML თეგი

     <head>

     -ში
   • Google Analytics (თუ კოდი უკვე დაინსტალირებულია)
   • Google Tag Manager
2. Sitemap გაგზავნილია და მუშავდება

   „Sitemap" სექცია → შეიყვანეთ sitemap.xml-ის URL → „გაგზავნა"
   სტატუსი „წარმატებული" უნდა იყოს (შეიძლება გაგზავნიდან 1-3 დღის შემდეგ გამოჩნდეს)

3. ცალკეული გვერდების ინდექსირების შემოწმება

   „URL შემოწმება" ინსტრუმენტი გამოიყენეთ:

   • მთავარი გვერდი შეიყვანეთ https://site.ge/
   • „URL-ის შემოწმება" დააჭირეთ
   • თუ გვერდი ინდექსირებულია, „URL Google-ის ინდექსშია" გამოჩნდება

   თუ გვერდები ჯერ ინდექსში არ არის, „ინდექსირების მოთხოვნა" დააჭირეთ პროცესის დასაჩქარებლად.

4. robots.txt შეამოწმეთ

   დარწმუნდით, შემთხვევით მთელი საიტი ინდექსირებისთვის ხომ არ დახურეთ:

   გახსენით https://site.ge/robots.txt

   შეამოწმეთ, ასეთი სტრიქონი ხომ არ არის:

   User-agent: *
   Disallow: /

   ეს მთელ საიტს ხურავს. სწორი ვარიანტი:

   User-agent: *
   Allow: /
   Sitemap: https://site.ge/sitemap.xml

თუ 2 კვირის შემდეგ მონაცემები კვლავ არ არის:

1. ინდექსირება ძიებით შეამოწმეთ:
   Google-ში შეიყვანეთ: site:site.ge
   თუ თუნდაც მთავარი გვერდი ჩანს — საიტი ინდექსშია, Search Console-ში მონაცემები მოგვიანებით გამოჩნდება.
2. Coverage შეცდომები შეამოწმეთ:
   Search Console → „Coverage" → თუ ნულოვანი გვერდია, „Excluded" ჩანართი ნახეთ — იქ მიზეზები იქნება.
3. პროცესი დააჩქარეთ:
   • 5-10 ძირითადი გვერდი „ინდექსირების მოთხოვნით" გაგზავნეთ
   • საიტზე რამდენიმე ხარისხიანი გარე ბმული შექმენით (სოც. ქსელებში პროფილები, კომპანიების კატალოგები)
   • დარწმუნდით, ხარისხიანი, უნიკალური კონტენტი გაქვთ (სხვა საიტებიდან კოპირებული არ)

როდის ღირს ნამდვილად შეშფოთება:

თუ 3-4 კვირის შემდეგ:

• site:site.ge ძიებაში ვერც ერთი გვერდი არ ჩანს
• Search Console-ის „Coverage" სექციაში ნულოვანი გვერდია
• ინდექსირების ყველა მოთხოვნა იგნორირდება

მაშინ შეამოწმეთ:

• დომენს სანქციები ხომ არ დაადო (ცუდი ისტორიის მქონე დომენი იყიდეთ)
• სხვა თქვენი საიტის კონტენტს ხომ არ ანიჭებთ
• ყველა გვერდზე აგრესიული noindex ხომ არ გამოიყენება

14. სატესტო ვერსია test.site.ge სუბდომენზე Basic Auth-ით დახურულია, მაგრამ ლოგებში Googlebot-ის წვდომის მცდელობებს ვხედავ. ბოტს პაროლის დაცვის გვერდის ავლა შეუძლია, ან ეს სკანირების მცდელობებია, რომლებიც იბლოკება?

Googlebot-ს Basic Auth-ის გვერდის ავლა არ შეუძლია.

Basic Authentication (HTTP ავტორიზაცია) — ეს სანდო დაცვის მეთოდია, რომელიც ვებ-სერვერის დონეზე მუშაობს. Googlebot-ი 401 Unauthorized კოდს მიიღებს და კონტენტზე წვდომა ვერ ექნება.

ლოგებში რას ხედავთ:

ეს წვდომის მცდელობებია, რომლებიც სერვერს ბლოკავს. ეს ხდება:

1. Googlebot-ი URL-ს მიმართავს: GET https://test.site.ge/page
2. სერვერი ავტორიზაციას ამოწმებს → ვერ პოულობს → 401 კოდს აბრუნებს
3. Googlebot-ი 401-ს იღებს და მიდის (გვერდის შინაარსს ვერ ხედავს)
4. სერვერის ლოგებში წვდომის მცდელობის ჩანაწერი რჩება

რატომ მიმართავს Googlebot-ი სატესტო ვერსიას:

1. ძირითადი საიტიდან ბმულები

   თუ ძირითად საიტზე (site.ge) სადმე სატესტო ვერსიაზე ბმული არსებობს:

   <a href="https://test.site.ge/page">
     Test page
   </a>

   Googlebot-ი მას იპოვის და მოვლას შეეცდება.

   გამოსავალი: ძირითადი საიტი test. სუბდომენზე ბმულებზე შეამოწმეთ.

2. ძირითადი საიტის Sitemap.xml

   თუ ძირითადი საიტის sitemap-ში სატესტო ვერსიის URL-ები არის — წაშალეთ.

3. DNS ჩანაწერები საჯაროდ ხელმისაწვდომია

   თუნდაც საიტი პაროლით დახურული იყოს, test.site.ge DNS ჩანაწერები ყველასთვის ხილულია. Googlebot-ი ცნობილი დომენების სუბდომენებს პერიოდულად შეიძლება ამოწმებდეს.

4. გარე ბმულები

   თუ ვინმემ შემთხვევით სატესტო ვერსიაზე ბმული სხვა საიტზე მოათავსა, Googlebot-ი მის გავლას შეეცდება.

სატესტო ვერსიის დაცვის შემოწმება:

1. პასუხის კოდი შეამოწმეთ

   ბრაუზერში ინკოგნიტო რეჟიმი გახსენით (შენახული პაროლების გამოყენების თავიდან ასაცილებლად) და https://test.site.ge/-ზე გადადით

   ლოგინი/პაროლის შეყვანის ფანჯარა უნდა გამოჩნდეს. DevTools-ში (F12 → Network) პასუხის კოდი შეამოწმეთ — 401 უნდა იყოს.

2. Google Search Console შეამოწმეთ

   თუ test.site.ge სუბდომენი Search Console-ში ცალ ობიექტად არის დამატებული, „Coverage" სექცია შეამოწმეთ:

   • 0 ინდექსირებული გვერდი უნდა იყოს
   • ყველა გვერდი „Excluded" სექციაში „ავტორიზაციით დაბლოკილი" მიზეზით უნდა იყოს
3. ძიებით შეამოწმეთ

   Google-ში შეიყვანეთ:

   site:test.site.ge

   თუ თუნდაც ერთი გვერდი ჩანს — ეს ნიშნავს, რომ დაცვა სწორად კონფიგურირებული არ არის.

დამატებითი დაცვის ზომები:

თუ გინდათ Googlebot-ის სატესტო ვერსიაზე მიმართვა სრულად გამოირიცხოს:

1. სუბდომენზე Robots.txt:

   შექმენით ფაილი

   https://test.site.ge/robots.txt

   :

   User-agent: *
   Disallow: /

2. ყველა გვერდზე მეტა-თეგები:

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

3. HTTP სათაურებში X-Robots-Tag:

   სერვერი (Apache/.htaccess ან Nginx) კონფიგურირეთ, რომ დააბრუნოს:

   X-Robots-Tag: noindex, nofollow

4. IP Whitelist-ით დახურვა:

   თუ შესაძლებელია, წვდომა დამატებით მხოლოდ თქვენი გუნდის კონკრეტული IP მისამართებისთვის შეზღუდეთ.

დასკვნა:

Googlebot-ის სატესტო ვერსიაზე მიმართვა ნორმალურია და საშიში არ არის, თუ Basic Auth კონფიგურირებულია. ბოტი 401-ს იღებს და მიდის, კონტენტს ვერ ხედავს. მაგრამ სრული სიმშვიდისთვის robots.txt და noindex დამატებით დაამატეთ.

დასკვნა: ტექნიკური SEO — ეს ინვესტიციაა, რომელიც წლების განმავლობაში მუშაობს

საიტის ტექნიკური ოპტიმიზაცია შეიძლება რთული და შრომატევადი ჩანდეს, მაგრამ ეს ის საფუძველია, რომელიც ერთხელ ეყრება და მუდმივად მუშაობს. კონტექსტური რეკლამისგან განსხვავებით, სადაც ყოველ კლიკზე იხდით, სწორად კონფიგურირებული საიტი Google-ის ორგანულ ტრაფიკს მნიშვნელოვნად იაფად და თვე-თვე მოიზიდავს.

გირჩევთ ეს მოთხოვნები საიტის შემუშავების ეტაპზე დანერგოთ — პოსტ-ფაქტუმ შეცდომების გამოსწორება 3-5-ჯერ ძვირი ჯდება. თუ თქვენი საიტი უკვე მუშაობს, ჩაატარეთ ტექნიკური აუდიტი კრიტიკული პრობლემების გამოსავლენად და გამოსასწორებლად.

გაიგეთ, რომელი ტექნიკური შეცდომები უშლის ხელს თქვენს საიტს Google-ის პირველ გვერდზე ყოფნაში

შეუკვეთეთ ტექნიკური SEO-აუდიტი ჩვენგან:

• ✅ 48 საათში ყველა დუბლიკატს ვიპოვით
• ✅ გადამისამართებებს და canonical-ს დავაყენებთ
• ✅ .ge დომენებისთვის hreflang-ის დანერგვაში დაგეხმარებით

100 გვერდისთვის 500 ლარიდან | ოკუპაცია 1,5-3 თვეში