საიტის განახლებისას ყველაზე დიდი რისკი დიზაინი ან ტექნიკური ნაწილი კი არა, უკვე დაგროვილი SEO შედეგების დაკარგვაა. თუ ძველ საიტს Google-იდან ტრაფიკი მოაქვს, ახალი ვერსიის გაშვებისას ეს შედეგები ავტომატურად არ გადადის.
საძიებო სისტემისთვის ვებსაიტი მხოლოდ დიზაინი არ არის. ის არის ერთმანეთთან დაკავშირებული მისამართების, ტექსტების, სურათების, სტატუსკოდებისა და სიგნალების სისტემა. როდესაც ამ სისტემის მნიშვნელოვანი ნაწილი ერთდროულად იცვლება, Google-ს დრო სჭირდება ახალი სტრუქტურის აღმოსაჩენად და ძველ გვერდებთან დასაკავშირებლად.
სწორად დაგეგმილი საიტის მიგრაცია SEO შედეგების ავტომატურ შენარჩუნებას ვერ უზრუნველყოფს, მაგრამ მნიშვნელოვნად ამცირებს დაკარგული გვერდების, 404 შეცდომებისა და ორგანული ხილვადობის შემცირების რისკს.
როდის ითვლება ცვლილება SEO მიგრაციად?
მიგრაცია მხოლოდ დომენის შეცვლა არ არის. SEO-ს თვალსაზრისით განსაკუთრებული კონტროლი საჭიროა, როდესაც იცვლება:
- დომენი ან ქვედომენი;
- HTTP პროტოკოლი HTTPS-ზე;
- გვერდების URL სტრუქტურა;
- CMS ან ელექტრონული კომერციის პლატფორმა;
- კატეგორიების იერარქია;
- რამდენიმე საიტის ერთ დომენში გაერთიანება;
- დიზაინთან ერთად მთავარი ნავიგაცია და შიდა ბმულები;
- მრავალენოვანი საიტის მისამართები;
- დიდი რაოდენობით კონტენტი.
Google-ის ოფიციალური საიტის გადაადგილების გზამკვლევი ურჩევს მფლობელებს, დიდი ცვლილებები წინასწარ დაგეგმონ, თითოეული ძველი URL ახალი შესაბამისი გვერდისკენ მიმართონ და შედეგები Search Console-ში აკონტროლონ.
პირველი ეტაპი: არსებული მდგომარეობის დაფიქსირება
მიგრაციამდე უნდა არსებობდეს საწყისი მონაცემები, რომელთანაც ახალ შედეგებს შევადარებთ. მხოლოდ საერთო ტრაფიკის ცოდნა საკმარისი არ არის.
სასურველია შევინახოთ:
- ორგანული ტრაფიკი გვერდების მიხედვით;
- Google Search Console-ის impressions, clicks, CTR და საშუალო პოზიცია;
- ინდექსირებული URL-ების რაოდენობა;
- ყველაზე მეტი ბექლინკის მქონე გვერდები;
- კონვერსიის მომტანი landing page-ები;
- XML sitemap-ში არსებული URL-ები;
- გვერდების title, description, H1 და canonical;
- სერვერის სტატუსკოდები;
- Core Web Vitals-ის საწყისი მონაცემები.
ეს ჩამონათვალი ქმნის საბაზისო სურათს. მიგრაციის შემდეგ შესაძლებელი იქნება ზუსტად დავინახოთ, რომელი გვერდი გაუმჯობესდა, სად გაჩნდა პრობლემა და რა მოითხოვს სწრაფ რეაგირებას.
URL-ების რუკა - მიგრაციის მთავარი დოკუმენტი
ყველა ძველი მისამართი უნდა დაუკავშირდეს ყველაზე შესაბამის ახალ მისამართს. ამას URL mapping ეწოდება.
ცუდი პრაქტიკაა ყველა წაშლილი გვერდის მთავარ გვერდზე გადამისამართება. მაგალითად, თუ ძველი პროდუქტის გვერდს ახალი ანალოგი აქვს, მომხმარებელი და Google სწორედ ამ ახალ პროდუქტზე უნდა გადავიდეს. თუ ძველი სტატია განახლებული სახელით არსებობს, მისი ძველი URL ახალ სტატიის მისამართს უნდა უკავშირდებოდეს.
URL-ების რუკაში სასურველია იყოს შემდეგი სვეტები:
| ძველი URL | ახალი URL | მოქმედება | მნიშვნელობა | შემოწმების სტატუსი |
|---|---|---|---|---|
| ძველი კატეგორია | ახალი კატეგორია | 301 | მაღალი | სატესტო |
| ძველი პროდუქტი | ახალი ანალოგი | 301 | მაღალი | დასრულებული |
| გაუქმებული გვერდი | შესაბამისი ალტერნატივა ან 410 | საშუალო | გადასაწყვეტი |
განსაკუთრებული ყურადღება უნდა მიექცეს გვერდებს, რომლებსაც უკვე აქვთ ორგანული ტრაფიკი ან გარე ბმულები. მათი არასწორად გადატანა ყველაზე ძვირი შეცდომაა.
301 გადამისამართებები და redirect chain-ები
მუდმივად შეცვლილი URL-ისთვის გამოიყენება server-side 301 ან 308 redirect. Google-ის გადამისამართებების დოკუმენტაცია მუდმივ redirect-ს რეკომენდაციას უწევს მაშინ, როცა გვერდს ახალი მდებარეობა აქვს.
უნდა ავირიდოთ redirect chain:
`ძველი URL → შუალედური URL → ახალი URL`
სასურველი ვარიანტია:
`ძველი URL → ახალი URL`
ჯაჭვები ზრდის ჩატვირთვის დროს, ართულებს ტექნიკურ კონტროლს და ზრდის შეცდომის ალბათობას. ასევე უნდა შემოწმდეს, რომ redirect loop არ წარმოიქმნას.
მიგრაციამდე სასარგებლოა ტექნიკური ოპტიმიზაციის პრაქტიკული გზამკვლევის გამოყენება, რათა redirect-ებთან ერთად შეფასდეს crawling, ინდექსაცია, მობილური გამოცდილება და სიჩქარე.
staging გარემო Google-ისთვის დახურული უნდა იყოს
ახალი საიტი ხშირად staging მისამართზე მზადდება. ტესტური ვერსია საძიებო სისტემაში არ უნდა გამოჩნდეს. მხოლოდ robots.txt-ზე დაყრდნობა საკმარისი დაცვა არ არის, რადგან დაბლოკილი URL ზოგჯერ გარე ბმულიდან მაინც შეიძლება აღმოჩნდეს.
უკეთესი მიდგომაა პაროლით დაცვა ან ავტორიზაცია. თუ გამოიყენება `noindex`, ის გამოშვებამდე აუცილებლად უნდა მოიხსნას. მიგრაციის ერთ-ერთი გავრცელებული შეცდომაა ახალი საიტის production გარემოში `noindex` ნიშნით დატოვება.
რა უნდა შემოწმდეს გაშვებამდე?
რედიზაინის ვიზუალური ტესტი მხოლოდ დასაწყისია. ტექნიკური შემოწმება უნდა მოიცავდეს:
- ახალი URL-ების 200 სტატუსს;
- ძველი მისამართების სწორ 301 redirect-ს;
- canonical-ის შესაბამისობას;
- robots meta tag-ებს;
- robots.txt-ის წესებს;
- XML sitemap-ის ახალ მისამართებს;
- ნავიგაციასა და შიდა ბმულებს;
- responsive დიზაინს;
- ფორმებისა და კონვერსიების მუშაობას;
- სტრუქტურირებულ მონაცემებს;
- სურათების alt ტექსტებს;
- Analytics-ისა და Search Console-ის კოდებს.
ამ პროცესისთვის სასარგებლოა საიტის სრულფასოვანი აუდიტის მეთოდოლოგია, რადგან რედიზაინისას პრობლემა შეიძლება არა მხოლოდ URL-ში, არამედ შაბლონში, ინდექსაციის სიგნალსა და კონტენტის სტრუქტურაშიც იყოს.
გამოშვების დღე: რა თანმიმდევრობით ვიმოქმედოთ?
გაშვებისას გუნდს წინასწარ გაწერილი გეგმა უნდა ჰქონდეს:
- გაკეთდეს საბოლოო backup;
- აიტვირთოს ახალი ვერსია;
- ჩაირთოს redirect-ების სრული ფაილი;
- მოიხსნას staging-ის noindex ან ავტორიზაცია production გარემოდან;
- შემოწმდეს მთავარი და მაღალი მნიშვნელობის URL-ები;
- განახლდეს XML sitemap;
- sitemap გაიგზავნოს Search Console-ში;
- შემოწმდეს Analytics-ის real-time მონაცემები;
- ჩაიწეროს გაშვების ზუსტი დრო.
თუ ერთდროულად იცვლება დომენი, CMS, დიზაინი და კონტენტი, პრობლემის წყაროს პოვნა რთულდება. ამიტომ დიდი პროექტი ეტაპებად უნდა დაიყოს, სადაც ეს ტექნიკურად შესაძლებელია.
მიგრაციის შემდგომი მონიტორინგი
გაშვების შემდეგ სამუშაო არ სრულდება. პირველ დღეებსა და კვირებში რეგულარულად უნდა შემოწმდეს:
- 404 და server error-ები;
- redirect-ების მუშაობა;
- ინდექსირებული გვერდების ცვლილება;
- sitemap-ის დამუშავება;
- ორგანული clicks და impressions;
- ბრენდული და არაბრენდული მოთხოვნები;
- ყველაზე მნიშვნელოვანი landing page-ების პოზიციები;
- conversion rate;
- Core Web Vitals.
პოზიციების დროებითი რყევა ნორმალურია, რადგან Google ძველ და ახალ URL-ებს ხელახლა ამუშავებს. პრობლემის ნიშანია ხანგრძლივი ვარდნა კონკრეტულ გვერდებზე, sitemap-ის შეცდომები ან ძველი URL-ების დიდი რაოდენობით 404 პასუხი.
Google რეკომენდაციას იძლევა, რომ მუდმივი redirect-ები დარჩეს რაც შეიძლება დიდხანს და მინიმუმ ერთი წლის განმავლობაში. ასევე უნდა განახლდეს საიტის შიდა ბმულები, რათა ისინი პირდაპირ საბოლოო URL-ებზე მიუთითებდეს და ზედმეტი redirect hop არ შეიქმნას.
ყველაზე ხშირი შეცდომები
- ძველი URL-ების სიის არარსებობა;
- ყველა გვერდის მთავარზე გადამისამართება;
- redirect chain-ები;
- ახალი sitemap-ის დაგვიანება;
- canonical-ში ძველი დომენის დატოვება;
- staging noindex-ის production-ზე დარჩენა;
- JavaScript-ით შექმნილი ბმულების გაუტესტაობა;
- Analytics-ის კოდის დაკარგვა;
- მობილური ვერსიის უგულებელყოფა;
- ძველი მაღალი შედეგის კონტენტის ზედმეტად შეცვლა.
დასკვნა
საიტის რედიზაინი მხოლოდ ვიზუალური პროექტი არ არის. ის ტექნიკური მიგრაციაა, სადაც თითოეულ ძველ გვერდს, ბმულსა და ინდექსაციის სიგნალს ახალი მდებარეობა უნდა ჰქონდეს.
წარმატებული პროცესი ეფუძნება ოთხ ძირითად ელემენტს: მიგრაციამდე მონაცემების შენახვას, URL-ების ზუსტ რუკას, გამართულ 301 redirect-ებს და გაშვების შემდგომ მონიტორინგს. როდესაც ეს ნაბიჯები წინასწარ არის დაგეგმილი, ბიზნესს შეუძლია განაახლოს საიტი ორგანული ხილვადობის ზედმეტი რისკის გარეშე.
ხშირად დასმული კითხვები
რამდენ ხანს უნდა დარჩეს 301 გადამისამართებები?
Google-ის რეკომენდაციით, მუდმივი redirect-ები სასურველია დარჩეს რაც შეიძლება დიდხანს და მინიმუმ ერთი წლის განმავლობაში. მომხმარებლებისთვის სასარგებლო ძველი URL-ების შემთხვევაში მათი მუდმივად შენარჩუნებაც გამართლებულია.
დომენის შეცვლისას პოზიციები ყოველთვის იკლებს?
მნიშვნელოვანი ცვლილების შემდეგ დროებითი რყევა მოსალოდნელია, რადგან Google ძველ და ახალ URL-ებს ხელახლა ამუშავებს. ზუსტი URL mapping, შესაბამისი მუდმივი redirect-ები, სწორი canonical-ები და მონიტორინგი ხანგრძლივი დანაკარგის რისკს მნიშვნელოვნად ამცირებს.
ყველა ძველი გვერდი მთავარ გვერდზე უნდა გადავამისამართოთ?
არა. ძველი URL უნდა გადავიდეს ყველაზე შესაბამის ახალ გვერდზე. ბევრი განსხვავებული URL-ის მთავარ გვერდზე გადამისამართება მომხმარებელს აბნევს და Google-მა შეიძლება soft 404-ადაც შეაფასოს.
ასევე წაიკითხეთ
გეგმავთ დომენის ცვლილებას ან რედიზაინს? მოითხოვეთ Infinity SEO-ს უფასო საწყისი აუდიტი და მიგრაციამდე განსაზღვრეთ, რომელი URL-ები, კონტენტი და ორგანული სიგნალები უნდა შენარჩუნდეს.
