Skip to main content
← Back to blog

SEO ჩატარების ნაბიჯი 7: უსაფრთხოება — საფუძველი, რომელზე ожидает Google 2026 წელს

·11 min read·by LANGR SEO

SEO ჩატარების ნაბიჯი 7: უსაფრთხოება

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

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

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

SSL-ის კონფიგურაცია

SSL (ტექნიკურად TLS) encrypt ცვლის კავშირს თქვენი სერვერის და ვიზიტორების შორის. 2014 წლიდან Google-მ ექსპლიციტურად დაადასტურა HTTPS როგორც რეიტინგული სიგნალი. 2026 წლისათვის HTTPS-ს არ ქონა უკვე არა მხოლოდ რეიტინგული პრობლემა აღარ არის — Chrome მარკირებს HTTP ვებსაიტებს როგორც "არასაფრთხო" მისამართის ხაზში, რის შედეგადაც მომხმარებლების ნდობა ექმნება.

ჩანაწერების საჭიროებები:

| საჭიროება | რატომ | როგორ შეამოწმოთ | |-----------|------|----------------| | მოქმედი სერტიფიკატი | გასული = ბრაუზერის ორკვევნა = ძვირფასი ვიზიტორების წასვლა | შეამოწმეთ გამოსვლის თარიღი | | სრული ჯაჭვი | გამოუსწორებელი ჯაჭვები ზოგიერთი მოწყობილობაზე ვერ მუშაობს | SSL Labs-ის ტესტი | | TLS 1.2+ | ძველი ვერსიები ახორციელებენ ცნობილ დაუცველობებს | SSL Labs-ის ტესტი | | არ არსებობს SHA-1 | გაუქმებულია, ბრაუზერები მას მტკიცებულებებს არ შესთავაზებენ | სერტიფიკატის დეტალები | | SAN კაპოტა | www და non-www უნდა იყოს ორივე დახურული | სერტიფიკატის დეტალები | | ავტო-განახლებონი | აღვიძებს გასვლების ავარიებს | Let's Encrypt / პროვაიდერის კონფიგურაცია |

SSL-ის ქულა:

100% = მოქმედი სერტიფიკატი + სრული ჯაჭვი + TLS 1.3 + ძლიერი cipher + ავტო-განახლება
  0% = გასული ან დაკარგული სერტიფიკატი

საერთაშორისო SSL-ის შეცდომები:

  1. სერტიფიკატი გასული ვადის მომატება — დასაშვები სიგნალი (ნაბიჯი 6) სამსახურის დროიდან მინიმუმ 30 დღის წინ
  2. დამაკავშირებელი სერტიფიკატის ჯაჭვი — სერვერი უნდა გამოაღებოს შუამდგომლური სერტიფიკატები, არა მხოლოდ ფოთოლი
  3. მრავალფეროვანი შინაარსი — HTTPS გვერდი უხურავს HTTP რესურსებს (სურათები, სკრიპტები, სტილია)
  4. გადასვლის წრიული ციკლები — HTTP → HTTPS → HTTP ციკლები არასწორად გაწვდილი CDN-ის/პროქსისგან
  5. non-www vs www ვერსიის შეუსაბამობა — სერტიფიკატი ერთი ტომით დაფარავს, მაგრამ მეორეს არა

წინასწარი ცვლილება: გაყოლეთ თქვენი დომენი SSL Labs (ssllabs.com/ssltest). "A" რეიტინგის ქვეშ ნებისმიერი აქტიური პრობლემაა. უმეტესობას ჰოსტინგი ამ პრობლემებს ერთი დაწკაპუნებით აარიდებს.

უსაფრთხოების წყაროები

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

ძირითად უსაფრთხოების წყაროები:

შინაარსის უსაფრთხოების პოლიტიკა (CSP)

CSP არის ყველაზე ძლიერი უსაფრთხოების წყარო. ის ბრაუზერებს ზუსტად უთხრობს, რომელი რესურსები (სკრიპტები, სტილი, სურათები, ფFonts) დათანხმდება თქვენს გვერდზე დატვირთვისათვის.

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' https://fonts.gstatic.com; connect-src 'self' https://api.example.com; frame-ancestors 'none';

რა CSP-ი კრძალავს:

  • Cross-site scripting (XSS) თავდასხმები
  • მონაცემების ინექციის თავდასხმები
  • Clickjacking (ბრაუზერების frame-ancestors მეშვეობით)
  • ავტორიზებული სკრიპტების გაწვდვა (cryptominers, ad injectors)

CSP-ის გამოყენების სტრატეგია:

  1. დაიწყეთ Content-Security-Policy-Report-Only (შენიშვნები აღების გარეშე)
  2. მონიტორეთ შეუქცევადი დონეები 1-2 კვირის განმავლობაში
  3. მიაწვდეთ ლეგიტიმური წყაროები
  4. გადავიდეთ აღკვეთის რეჟიმზე
  5. დაამატეთ report-uri ან report-to მუდმივი განხორციელების ჩანაწერისთვის

X-Frame-Options

გარეგანი საიტის ჩართვა რადგან მისი გაწვდვა iframe-ებში სხვა დომენებზე (clickjacking დაცვა).

X-Frame-Options: DENY

თუ საჭიროა იგივე-ორგინის ჩატვირთვის გასაშვებლად:

X-Frame-Options: SAMEORIGIN

X-Content-Type-Options

აიძულებს ბრაუზერებს MIME ტიპების sniffing-ის თავიდან ასაცილებლად (ფაილების ინტერპრეტირების პროცესში სხვანაირი ტიპისთვის ვიდრე გამოცხადებული).

X-Content-Type-Options: nosniff

ეს ერთმაგი ხაზით აფერხებს თავდასხმებს, სადაც .jpg ფაილი შეიცავს ანონიმურ JavaScript-ს, რომელსაც ბრაუზერი შეიძლება გაწვდოს.

Referrer-Policy

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

Referrer-Policy: strict-origin-when-cross-origin

ეს მთელ URL-ს ერთი წყაროდან აგზავნის, მაგრამ მხოლოდ ორიგინზე (დომენი) გადასვლის დროს. აყალიბებს ანალიტიკის საჭიროებას და დისკრეტულობას.

Permissions-Policy

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

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()

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

წყაროს განხორციელების მაგალითი (Next.js):

// next.config.js
module.exports = {
  async headers() {
    return [{
      source: '/(.*)',
      headers: [
        { key: 'X-Content-Type-Options', value: 'nosniff' },
        { key: 'X-Frame-Options', value: 'SAMEORIGIN' },
        { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
        { key: 'Permissions-Policy', value: 'camera=(), microphone=(), geolocation=()' },
        { key: 'Strict-Transport-Security', value: 'max-age=31536000; includeSubDomains; preload' },
      ]
    }]
  }
}

წყაროს განხორციელება (Apache .htaccess):

Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

წყაროს განხორციელება (Nginx):

add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

წინასწარი ცვლილება: დაამატეთ ყველა 5 მოწინავე წყარო თქვენს სერვერს. ამას 5 წუთის განმავლობაში მართავს და დაუყოვნებლივ აუმჯობესებს თქვენს უსაფრთხოების პოზიციას ნებისმიერ სკანირების ხელსაწყოში.

HSTS პრeload

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

HSTS წარწერა:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

სამი მიმართულება:

| მიმართულება | მნიშვნელობა | |--------------|------------| | max-age=31536000 | შეინახეთ ეს 1 წლის განმავლობაში (წამწმნაურებში) | | includeSubDomains | უნდა მდინარეობდეს ყველა შიდა დომენის მიმართ | | preload | ბრაუზერის წინა სიაში ჩართვის მოთხოვნა |

HSTS პრeload სია:

HSTS-ის მაქსიმალური დაცვის სია. ბრაუზერები გადატანენ შექმნილ სიას დომენების შესახებ, რომლებიც ყოველთვის უნდა გამოიყენონ HTTPS. თქვენი დომენის hstspreload.org-ზე წარდგენა ნიშნავს:

  • პირველი ვიზიტი იღებს HTTPS-ი დაუყოვნებლივ (არ აკრძალებს HTTP → HTTPS)
  • თავდამსხმელებს არ შეუძლიათ გააუქმონ კავშირები
  • მუდმივი (რთულია წაშლა ერთხელ წარდგენილზე)

HSTS პრeload-ისთვის საჭიროებები:

  1. მოქმედი HTTPS სერტიფიკატი
  2. გადააგზავნეთ ყველა HTTP HTTPS-ზე (შეიძლება გვერდების მიმართ)
  3. HSTS მოკლე მოძრაობა max-age >= 31536000
  4. HSTS სიგნალი includeSubDomains უნდა გქონდეს
  5. HSTS სიგნალი preload უნდა მოიცავდეს
  6. ყველა სამხედრო დომენი უნდა უჭერდეს HTTPS-ს

ყურადღება: მხოლოდ წარადგინეთ preload-ზე, თუ ყველა მყიდველის დაქვეითება HTTPS-ს იძლევა. includeSubDomains მიმართულება ნიშნავს, რომ ნებისმიერი HTTP-კონფიგურული შეედანება ხელმისაწვდომი აღარ იქნება.

წინასწარი ცვლილება: თუ უკვე გაქვთ HTTPS ყველა ქვეკატეგოროლოგეთში, დაამატეთ სრული HSTS ტურისტი და წარადგინეთ hstspreload.org-ზე. პროცესინგი რამდენიმე კვირა სჭირდება, მაგრამ დაცვა მუდმივია.

დაუცველობების სკანირება

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

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

  • ამოღებული სვამლური: WordPress, პლაგინები, JavaScript-ის ბიბლიოთეკები ცნობილ CVE-ებით
  • გამოყენებული ფაილები: .env, .git, wp-config.php, მონაცემთა გადმოწერები
  • ინფორმაციის გაჟონვა: სერვერის ვერსიის წყაროები, დიაგნოზირების რეჟიმი, საცალო მარკავდა
  • ძირითადი სერტიფიკატები: ადმინისტრაციული გვერდები ავტორიზაციის გარეშე, ძირითად პაროლები
  • ღია პორტები/პროექტები: საჭიროების გარეშე ინტერნეტის გაგრძელატებები
  • ინექციის წერტილები: ფორმები CSRF დაცვის გარეშე, არაუმართლებური შესვლები

პლატფორმითა და დაუცველობების პოპულარობა:

| პლატფორმა | უმთავრესი დაუცველობა | გამოსწორება | |------------|----------------------|-------------| | WordPress | ამოღებული პლაგინები | ავტომატური განახლება + WAF | | Shopify | მესამე მხარის აპლიკაციების უფლებები | აუდიტი ყოველ კვარტალში | | Next.js | გაწვდილი API გზები | ავტორიზაციის მარცხენა + შეზღუდვა | | სტატიკური ვებსაიტები | CDN-ის გზიყრა | შეამოწმეთ კების წესები | | ჰუმანური | SQL ინექცია | პარამეტრიზირებული კითხვები |

სკანირების სიხშირე:

  • ყოველდღიური: ავტომატური ზედაპირული მოკვლევა (SSL, წყაროები, დაიხლეჩილი ფაილები)
  • ყოველკვირაში: დამოკიდებულებისიტანებელი მსოფლიო კითხვების შემოწმება (npm audit, WordPress-ის პლაგინის სკანერი)
  • ყოველთვიური: ღრმა სკანირება ავტორიზაციის ტესტირებით
  • ყველა გამოსვლის შემდეგ: რეგრესიული შემოწმება

წინასწარი ცვლილება: გაწვდეთ npm audit (Node.js) ან შეამოწმეთ თქვენი CMS-ის პლაგინის სია მათ დოლარებზე. დაუყოვნებლივ გამოასწორეთ კრიტიკული/სიმაღლე რყევები.

მრავალფეროვანი შინაარსი

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

მრავალფეროვანი შინაარსის ტიპები:

| ტიპი | სიძლიერე | მაგალითი | ბრაუზერის მოღვაწეობა | |------|----------|---------|---------------------| | აქტიური | მაღალი | HTTP სკრიპტი, iframe, CSS | ავტომატურად დაბლოკილი | | პასიური | საშუალო | HTTP სურათი, ვიდეო, აუდიო | ალტერნატიულ რიგში დაბლოკილია |

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

მრავალფეროვანი შინაარსის აღმოჩენა:

  1. გახსენით Chrome DevTools → კონსოლი
  2. ეძნეთ "მრავალფეროვანი შინაარსის" პრობლემები
  3. ალტერნატიულად, იპოვნეთ სცანის შემოწმება (Screaming Frog, LANGR)

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

  • წერილებში hardcoded http:// URL-ები (ბლოგ პოსტები, პროდუქტის აღწერილობები)
  • მესამე მხარის ვიჯეტები, რომლებსაც HTTP რესურსები დარღვევენ
  • შეკრული შინაარსი (YouTube-ის ძველი გაწვდილიები, სოციალური მედიის ვიჯეტები)
  • CSS background-image HTTP URL-ებით
  • ფონტები, რომელსაც HTTP-ს მეშვეობით აწვდეთ

მრავალფეროვანი შინაარსის გამოსწორება:

<!-- ცუდი -->
<img src="http://example.com/image.jpg" />

<!-- კარგი -->
<img src="https://example.com/image.jpg" />

<!-- საუკეთესო (პროტოკოლის მიმართ, გვერდების პროტოკოლზე ადაპტირება) -->
<img src="//example.com/image.jpg" />

უცნობი მონაცემების მილაღება (WordPress):

UPDATE wp_posts SET post_content = REPLACE(post_content, 'http://yourdomain.com', 'https://yourdomain.com');
UPDATE wp_postmeta SET meta_value = REPLACE(meta_value, 'http://yourdomain.com', 'https://yourdomain.com');

წინასწარი ცვლილება: გახსენით თქვენი მთავარი გვერდი Chrome-ში, დააწკაპუნეთ F12, შეამოწმეთ კონსოლის ჩანართი მრავალფეროვანი შინაარსის პრობლემებისთვის. გამოასწორეთ ნებისმიერი პრობლემა — ეს პირდაპირი ნიშნებია Google-ისთვის.

მესამე მხარის სკრიპტების რისკები

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

  • შეიძლება იყოს მოტყუებული (ცვლილი აღი)
  • აკვირდება თქვენს მომხმარებლებს გარეშე თანხმობის (GDPR დარღვევა)
  • აფერხებს თქვენს ვებსაიტსაც (შინაარსს დაბლოკვის პროცესში, ქსელის გაწვდვა)
  • გამართავს ფუნქციონალზე (ვერსიის განახლებისას, outages)
  • სხვა თემა უფრო საშიში შექმნის (advertising scripts დამაგვოს შეცდომით)

Audits თქვენი მესამე მხარის სკრიპტებისთვის:

| სკრიპტი | საჭიროება? | რისკის დონე | ალტერნატიული | |----------|-----------|--------------|---------------| | Google Analytics | ხშირად კი | დაბალი | სერვერის მხარის ტრექინგი | | ჩეთის ვიჯეტები | შესაძლოა | საშუალო | თვითდამატებული გადაწყვეტები | | სოციალური გაზიარების ღილაკები | იშვიათად | საშუალო | სტატიკური გაზიარების ლინკები | | A/B ტესტირება | ზოგჯერ | მაღალი | სერვერის მხარის ტესტირება | | რეტარგეტინგის პიქსელები | ბიზნეს გადაწყვეტილება | высокая | პირველი მხარის მონაცემები | | ფონტების CDN | კომფორტული | დაბალი | თვითდამატებული ფონტები |

რისკების შემცირება აუცილებელ მესამე მხარის სკრიპტებისათვის:

  1. Subresource Integrity (SRI): Hash-ით ვერსიები საჭიროები ხელს უწყობს შეცდომით სკრიპტების დაბლოკვისთვის
<script src="https://cdn.example.com/lib.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxAE+sO0..."
        crossorigin="anonymous"></script>
  1. CSP-ის შეზღუდვები: მხოლოდ დაშვებული სკრიპტები ცნობილ დომენებისაგან
  2. Sandboxed iframes: იზოლირებული მესამედი მხარის ვიჯეტები
  3. რეგულარული აუდიტები: ყოველკვარტალი გარეგანი რესურსების სიაში
  4. მონიტორინგი: ახალი გარედან გამოჩენილი დომენების გარშემო სტიმული

წინასწარი ცვლილება: ჩამოაყალიბეთ ყოველ