ჩანაწერი · 12 მაისი, 2026 · 7 წუთი წასაკითხი

Canonical URL: როდის არის საჭირო, როდის აზიანებს

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

შევედი Google Search Console-ში, გავატარე URL Inspection. Google წერს: «User-declared canonical: https://example.com/». ანუ ჩემივე გვერდი ეუბნება Google-ს: «არ დააინდექსირო ჩემი, დააინდექსირე მთავარი». ვხსნი DevTools-ს, ვუყურებ <head>-ს — მართლაც დგას <link rel="canonical" href="https://example.com/">. ყველა გვერდზე. ერთი და იგივე canonical, რომელიც დომენის ფესვზე მიდის.

შემდეგ წავედი იმის ძიებაში, საიდან გამოვიდა ეს. აღმოჩნდა — ვიღაცამ შეასწორა next.config.js, დაამატა ბლოკი ნაგულისხმევი მეტატეგებით, ჩაწერა იქ canonical process.env.SITE_URL-ის გავლით path-ის გარეშე. შაბლონი მთელ საიტზე გავრცელდა. Google კი მორჩილად ააწება ყველაფერი ერთ გვერდად.

უკან დახევაზე და ხელახალ ინდექსაციაზე სამი კვირა წავიდა. ნაწილი პოზიციებისა დღემდე არ დამიბრუნებია.

ეს ტიპიური შემთხვევაა. Canonical — ძლიერი სიგნალია, და ერთ ხაზად კონფიგში მისი გატეხვა მარტივია. ბოლო ნახევარი წლის განმავლობაში ვშლიდი ასეთ ისტორიებს ხუთ სხვადასხვა პროექტზე. ყველგან მიზეზები განსხვავებულია — სადღაც WordPress-ის პლაგინი, სადღაც Next.js-ის კონფიგი, სადღაც Shopify-ის თემა, სადღაც პროგრამისტის შესწორება, რომელიც «უნდა გაეერთიანებინა ყველაფერი». შედეგი კი ერთნაირია: გვერდები ცვივა ინდექსიდან, შენ კი ვერ ხვდები რატომ, სანამ წყაროში არ შეიხედავ.

შემდეგ — რა არის ეს, როდის არის ნამდვილად საჭირო, და სად დამხმარედან ფეხში გასროლად გადაიქცევა.

რა არის canonical

Canonical — ეს არის Google-სთვის მითითება, გვერდის რომელი ვერსია მიიჩნიოს მთავრად, თუ ინდექსში რამდენიმე მსგავსი ან ერთნაირია.

ტექნიკურად ის ცხოვრობს ორ ადგილას. პირველი — HTML-ში, <head>-ში:

<link rel="canonical" href="https://example.com/product/red-shoes">

მეორე — HTTP-header-ში, არა-HTML რესურსებისთვის (PDF, სურათები, დოკუმენტები):

Link: <https://example.com/whitepaper.pdf>; rel="canonical"

რის გაგებაც მნიშვნელოვანია. Canonical — ეს არ არის გადამისამართება. ეს არ არის ბლოკი. ეს დირექტივაც კი არ არის. ეს არის სიგნალი, მინიშნება. Google უყურებს canonical-ს და წყვეტს, დაუჯეროს თუ არა. URL Inspection-ში ნახავ ორ ველს: «User-declared canonical» (რა გამოაცხადე შენ) და «Google-selected canonical» (რა აარჩია Google-მა). ისინი ხშირად არ ემთხვევა.

Google-ს შეუძლია უგულებელყოს შენი canonical, თუ:

ის მიდის noindex-გვერდზე
ის მიდის 404-ზე ან 5xx-ზე
გვერდების შინაარსი რადიკალურად განსხვავდება
canonical მიდის სხვა canonical-ების ჯაჭვზე
ერთ გვერდზე გიდგას რამდენიმე canonical სხვადასხვა URL-ით

ანუ ეს არის რეკომენდაცია, რომელსაც Google წონის ფაქტორების ერთობლიობით. მაგრამ 90% შემთხვევაში — უსმენს. სწორედ ამიტომ არის სახიფათო: დებ canonical-ს იმ იმედით, რომ Google-ს «მიანიშნებ», შედეგად კი ისე გამოდის, რომ რეალურად მთელი ძიების ტრაფიკი გადაამისამართე. უბრალოდ გადამისამართების გარეშე და სერვერის ლოგებში კვალის გარეშე.

ცალკე საკითხია canonical robots.txt-ის წინააღმდეგ noindex-ის წინააღმდეგ. ეს არის სხვადასხვა ინსტრუმენტი სხვადასხვა ამოცანისთვის. Robots.txt კრძალავს craw-ლინგს (Google საერთოდ არ ტვირთავს გვერდს). Noindex უშვებს craw-ლინგს, მაგრამ კრძალავს ინდექსაციას. Canonical უშვებს როგორც craw-ლინგს, ისე ინდექსაციას, მაგრამ ამბობს: «შედეგებში დაამატე აი ეს ვერსია». მათ აღრევას მოჰყვება ან გვერდები, რომელთაც Google ვერ ხედავს, ან გვერდები, რომელთაც ხედავს, მაგრამ არ აჩვენებს.

როდის არის canonical საჭირო

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

URL-ის დუბლიკატები query parameter-ებით. ყველაზე ხშირი შემთხვევა. გაქვს ონლაინ მაღაზია, პროდუქტის გვერდი /product/red-shoes. მომხმარებელი ფილტრავს — URL ხდება /product/red-shoes?size=42&color=red&utm_source=google. შინაარსი იგივეა. canonical-ის გარეშე Google-ს შეუძლია ორივე ვერსიის ინდექსაცია და მათ შორის რანჟირების გაყოფა. canonical-ით /product/red-shoes-ზე — Google ხვდება, რომ ეს ერთი გვერდია, და მთელი წონა ძირითად URL-ზე მიდის.

ძველი HTTP/HTTPS, www/non-www ისტორია. თუ საიტი გადავიდა HTTP-დან HTTPS-ზე ან www-დან მშიშარა დომენზე, და გადამისამართებები ყველგან არ არის — canonical-მა შეიძლება დაგეხმაროს. თუმცა გულახდილად: 301-გადამისამართება ამ შემთხვევაში ყოველთვის უკეთესია. Canonical — ეს არის სათადარიგო პარაშუტი, ძირითადი მექანიზმი უნდა იყოს გადამისამართება nginx-ის ან CDN-ის დონეზე.

Print-version, AMP, mobile-ვერსიები. თუ გაქვს გვერდის ცალკე print-friendly ვერსია — /article?print=1 — მან canonical-ით ძირითადს უნდა მიუთითოს. იგივე ისტორიაა AMP-ვერსიასთან: მასზე დგას canonical ძირითად HTML-ვარიანტზე. ეს სტანდარტული პრაქტიკაა.

A/B-ტესტები. ტესტავ ლენდინგის ორ ვარიანტს — /landing-a და /landing-b. ვარიანტ B-ს უნდა ჰქონდეს canonical ვარიანტ A-ზე (ან ორივეს — ნეიტრალურ URL-ზე). სხვა შემთხვევაში თვითონ შექმნი დუბლიკატს, და Google გაყოფს რანჟირებას ტესტის ორ ნახევარს შორის.

Sticky filters სიებში. კატეგორია სორტირებით: /catalog, /catalog?sort=price, /catalog?sort=date. შინაარსი იგივეა, წყობა — განსხვავებული. ყველა ვარიანტის canonical /catalog-ზე — Google ერთ გვერდს რანჟირებს, არა სამ მსგავსს.

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

როდის აზიანებს canonical

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

Canonical მთავარ გვერდზე ყველა გვერდიდან. ჩემი ისტორია პოსტის დასაწყისიდან. ეს ყველაზე ხშირი შეცდომაა, და ის სრულად კლავს საიტს. წარმოიქმნება ცუდად დაკონფიგურირებული next.config.js-ის, Astro-ს შაბლონის, WordPress-ის პლაგინის, Shopify-ის თემის გამო — ყველგან, სადაც canonical დგინდება ნაგულისხმევად მიმდინარე URL-ის გათვალისწინების გარეშე. Google ინდექსირებს მხოლოდ მთავარს. დანარჩენი გვერდები — გამოცემაში არ ჩნდება. ერთი ბრძანებით მოწმდება:

curl -sS https://example.com/some-page | grep canonical

თუ გამოშვებაში href ფესვზე მიდის — გაქვს პრობლემა.

Self-canonical სხვა დომენით ან სქემით. საიტი https://example.com-ზე, canonical კი დგას http://example.com/page (s-ის გარეშე) ან https://www.example.com/page (www-თი, თუმცა საიტი www-ის გარეშეა). წარმოიქმნება შაბლონში hardcode-ული URL-ის გამო ან მიგრაციის შემდეგ, რომლის შემდეგაც canonical არ განახლდა. Google ან უგულებელყოფს, ან აერთიანებს არარსებულ ვერსიასთან. გასწორება — ხუთი წუთი, პოვნა — ზოგჯერ საათები.

Canonical noindex-გვერდზე. თვითწინააღმდეგობრივობა. შენ ამბობ: «აი ეს ძირითადი ვერსიაა», და აქვე ამ ძირითადზე — <meta name="robots" content="noindex">. Google ამ შემთხვევაში canonical-ს უგულებელყოფს, მაგრამ ორიგინალის ინდექსაციაც შეიძლება არ მოახდინოს — რადგან აშკარად თქვი, რომ ის ვერსია ძირითადი არ არის. წარმოიქმნება ჩვეულებრივ staging-გარემოებში, რომელიც შემთხვევით მოხვდა ინდექსში.

Canonical-ის ჯაჭვები. გვერდი A canonical-ით მიდის B-ზე, B canonical-ით — C-ზე. Google ამუშავებს მხოლოდ პირველ ნაბიჯს. ანუ A → B ის ნახავს, B → C — ვერა. შედეგად ინდექსში რჩება B, თუმცა შენ გინდოდა C. ჯაჭვები წარმოიქმნება მიგრაციების ისტორიის მქონე საიტებზე, როცა canonical რამდენჯერმე გასწორდა და წესრიგში არ მოვიდა.

Canonical materially განსხვავებული შინაარსისას. /search?q=seo-ს აქვს canonical /search-ზე. თითქოს ლოგიკურია — ეს ხომ ერთი საძიებო გვერდია. მაგრამ ?q=seo გასცემს შედეგებს «seo»-სთვის, ხოლო /search პარამეტრის გარეშე — ცარიელ ფორმას. შინაარსი განსხვავებულია, query პარამეტრი materially ცვლის გვერდს. Google აერთიანებს — და დაკარგავ SERP-პოზიციებს ყველა კონკრეტული საძიებო ჩანაცვლებისთვის. იგივე ეხება კატალოგის ფილტრებს, რომლებიც ძლიერ ცვლის გამოცემას: /laptops?brand=apple — ეს არ არის /laptops-ის დუბლიკატი, ეს არის ცალკე გვერდი, რომელსაც შეუძლია «macbook»-ით რანჟირება.

მთავარი პრინციპი: canonical საჭიროა იქ, სადაც შინაარსი დუბლირდება. თუ შინაარსი განსხვავებულია — canonical მავნეა.

როგორ შევამოწმოთ canonical

სამი ხერხი, სიზუსტის ზრდის მიხედვით.

curl. ყველაზე სწრაფი. ნებისმიერ გვერდზე:

curl -sS https://example.com/page | grep -i canonical

უნდა დააბრუნოს სტრიქონი <link rel="canonical" href="...">. თუ href ემთხვევა მოთხოვნის URL-ს (სქემის, www-ის, trailing slash-ის გათვალისწინებით) — self-canonical, ყველაფერი წესრიგშია. თუ სადმე სხვაგან მიდის — გაარკვიე, ეს განზრახაა თუ ბაგი.

DevTools. ხსნი გვერდს, F12, ჩანართი Elements, Ctrl+F, ეძებ «canonical»-ს. ხედავ, რა გამოარენდერა ბრაუზერმა. ეს მნიშვნელოვანია: ზოგჯერ canonical ჩაისმის JavaScript-ით, და curl-ში ის არ ჩანს — DOM-ში კი არის. განსაკუთრებით SPA-ებზე, როგორიცაა React/Next client-side rendering-ით.

Google Search Console → URL Inspection. ყველაზე გულახდილი ხერხი. ჩაამატებ URL-ს — Google გიჩვენებს ორ ველს:

User-declared canonical — რა გიდგას HTML-ში
Google-selected canonical — რას მიიჩნევს Google რეალურად ძირითადად

ისინი უნდა ემთხვეოდეს. თუ არ ემთხვევა — Google-მა შენი canonical უგულებელყო და სხვა რამ აარჩია. ეს არის სიგნალი: ან შენი canonical აშკარად გატეხილია, ან შინაარსი ჰგავს სხვა გვერდს და Google-მა გადაწყვიტა მათი გაერთიანება. და აი «Google-selected» — ეს არის ის, რაც რეალურად მოქმედებს ინდექსაციაზე და რანჟირებაზე, არა ის, რაც გამოაცხადე.

შემოწმება — თვეში ერთხელ ძირითად გვერდებზე. დიდ კატალოგებზე — შერჩევით, GSC API-ით ერთდროულად ათასობით URL-ით.

თვითკანონიკური გვერდები

Best practice, რომელსაც ვდებ ყველა პროექტზე. ყოველი უნიკალური გვერდი დებს canonical-ს თავის თავზე — სრული აბსოლუტური URL-ით.

<!-- გვერდზე /article/seo-tips -->
<link rel="canonical" href="https://example.com/article/seo-tips">

რატომ არის ეს საჭირო, თუ გვერდი ისედაც უნიკალურია? იმიტომ, რომ ის შეიძლება ხელმისაწვდომი იყოს URL-ის ვარიანტებით, რომელთა შესახებაც შენ არ იცი:

?utm_source=... — სარეკლამო პარამეტრები
?fbclid=... — Facebook click ID
#section — ანკორი
/article/seo-tips/ — trailing slash
/Article/Seo-Tips — სხვადასხვა რეგისტრი

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

რეალიზდება ჩვეულებრივ Next.js / WordPress / ნებისმიერი CMS-ის შაბლონში — ფუნქციით, რომელიც იღებს request.url-ს, ნორმალიზებას უკეთებს (იღებს query-ს, ნორმალიზებას უკეთებს case-ს, დებს trailing slash-ს როგორც შენთან მიღებულია) და სვამს <link rel="canonical">-ში. ერთხელ დააკონფიგურირე — მუშაობს ყველა გვერდზე.

Next.js-ში ეს კეთდება metadata.alternates.canonical-ის გავლით layout.tsx-ში ან გვერდის დონეზე:

export const metadata = {
  alternates: {
    canonical: 'https://example.com/article/seo-tips',
  },
}

მნიშვნელოვანია: URL აბსოლუტურია, სქემითა და დომენით. შედარებითი canonical-ები (/article/seo-tips) ფორმალურად ვალიდურია, მაგრამ მინახავს შემთხვევები, როცა Google მათ უცნაურად ინტერპრეტირებდა — განსაკუთრებით თუ გვერდი ხელმისაწვდომია რამდენიმე host-ით (apex და www). უმჯობესია ყოველთვის ჩაწერო სრული URL.

შეჯამება

Canonical — ეს Google-ის სიგნალია: «როცა მსგავს გვერდებს დაინახავ, აი ეს დააინდექსირე». სასარგებლოა query-პარამეტრებისთვის, ფილტრებისთვის, A/B-ტესტებისთვის, გადაბეჭდვებისთვის. მავნეა, როცა მასიურად დგას მთავარზე, noindex-ზე, http-ზე https-საიტისას, ან როცა query-პარამეტრები materially ცვლის შინაარსს.

წესი მარტივია. თუ შინაარსი დუბლირდება — canonical საჭიროა. თუ შინაარსი უნიკალურია — self-canonical. თუ შინაარსი განსხვავებულია — canonical საერთოდ არ არის საჭირო, იყოს თავისი გვერდი თავისი URL-ით.

ამოწმე GSC URL Inspection-ით. «Google-selected canonical» — ერთადერთი ციფრია, რომელიც რეალურად მოქმედებს გამოცემაზე. დანარჩენი ყველაფერი — შენი განზრახვებია.

იხილე აგრეთვე: 30+ ფაქტორი SEO 2026, რა დავბლოკოთ robots.txt-ში, hreflang: subdomain თუ subdirectory.