ძველი WordPress საიტის გადარჩენა ხელახლა აწყობამდე

მოკლე პასუხი (TL;DR): ძველი WordPress საიტის გადარჩენა იწყება ინვენტარით და ასლით, არა ახალი დიზაინის არჩევით. ჯერ უნდა გაირკვეს, ვის აქვს წვდომა, სად არის დომენი, რომელ გვერდებს მოაქვს მოთხოვნები, როგორ მუშაობს ფორმა და შესაძლებელია თუ არა მიმდინარე ვერსიის აღდგენა. ამის შემდეგ გადაწყდება კონკრეტული ნაწილის შეკეთება, ეტაპობრივი მიგრაცია თუ ხელახლა აწყობა.

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

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

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

• დომენის რეგისტრატორი, DNS-ის მართვა, ჰოსტინგის ანგარიში და SSL-ის პასუხისმგებელი პირი;
• WordPress-ის ადმინისტრატორის ანგარიში, FTP ან ფაილების მართვის გზა და მონაცემთა ბაზის სარეზერვო წვდომა;
• ბოლო სრული სარეზერვო ასლის თარიღი და აღდგენის ცდის შედეგი;
• ყველა საკონტაქტო ფორმა, ელფოსტის მიმღები, ავტომატური პასუხი და CRM-ში გადაცემის გზა;
• ძირითადი გვერდები, მოქმედი URL-ები, ძველი კამპანიების ბმულები და საძიებო სისტემიდან მოსული გვერდები;
• გუნდის რეალური რედაქტირების გზა: ვინ წერს, ვინ ამოწმებს და ვინ აქვეყნებს.

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

გადაარჩინეთ, გაზომეთ თუ შეცვალეთ

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

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

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

შექმენით აღდგენისთვის მზად პაკეტი

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

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

URL-ები, ძიება და მომხმარებლის გზა

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

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

შეკეთება თუ ხელახლა აწყობა

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

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

სცენარი: მცირე კლინიკის ძველი საიტი

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

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

ხშირი შეცდომები

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

შეკეთების გადაწყვეტილების შედარება

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

სამაშველო შემოწმების საზღვრები

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

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

შემდეგი სამუშაო დოკუმენტები

• WordPress კონტენტის აუდიტი მიგრაციამდე
• დომენისა და ჰოსტინგის მფლობელობის კონტროლი
• staging და cutover გეგმა
• როგორ შევინარჩუნოთ მოთხოვნები მიგრაციისას
• SEO გადამისამართებების ჩეკლისტი
• პლაგინების დამოკიდებულებების გეგმა
• aiWEB პროექტის განხილვა

<li><a href="https://developer.wordpress.org/advanced-administration/security/backup/">ოფიციალური დოკუმენტაცია: სარეზერვო ასლები</a></li>
<li><a href="https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes">ოფიციალური მითითება: საიტის გადატანა</a></li>
<li><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/301">ოფიციალური მითითება: მუდმივი გადამისამართება</a></li></ul>

კითხვები ძველი საიტის გადარჩენაზე

როდის ღირს ძველი WordPress საიტის შენარჩუნება?

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

საკმარისია თუ არა WordPress-ის XML ექსპორტი?

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

როდის უნდა მომზადდეს გადამისამართებების სია?

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

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

შემდეგი ნაბიჯი: შეაგროვეთ ანგარიშების, ასლების, ფორმებისა და ძველი URL-ების სია და ამის შემდეგ შეაფასეთ შეკეთება ან ხელახლა აწყობა aiWEB-ის გუნდთან.