WordPress მიგრაციისას დომენისა და ჰოსტინგის მფლობელობის კონტროლი

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

მფლობელობის 2 ფენა, რომელიც არ უნდა აგერიოთ

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

რა ითვლება მტკიცებულებად

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

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

სარეზერვო ასლები და აღდგენა

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

აღდგენის ცდა ჩაატარეთ განცალკევებულ გარემოში. შეამოწმეთ მთავარი გვერდი, ადმინისტრატორი, მედია, ფორმა, ავტომატური ელფოსტა და ძირითადი URL. „ფაილი არსებობს“ არ ნიშნავს „საიტი აღდგა“. თუ აღდგენა არ გაგისინჯავთ, სტატუსი უნდა იყოს გადასამოწმებელი.

DNS და გადართვის თანმიმდევრობა

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

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

სცენარი: სააგენტოსგან დაბრუნებული საიტი

წარმოიდგინეთ კომპანია, რომლის საიტიც წინა სააგენტომ ააწყო. WordPress-ის ადმინისტრატორი კომპანიას აქვს, მაგრამ დომენი სააგენტოს ანგარიშზეა, DNS სხვა პლატფორმაზეა, ხოლო ფორმის ელფოსტა ყოფილი თანამშრომლის მისამართზე მიდის.

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

შედარება: არსებული ანგარიშების გამოყენება და ახალი გარემოს შექმნა

გადაცემის 3 აუცილებელი ჩანაწერი

1. რესურსების რეესტრი: ანგარიში, პასუხისმგებელი, აღდგენის გზა და ბოლო შემოწმება;
2. ცვლილებების ჟურნალი: რა შეიცვალა DNS-ში, ჰოსტინგში, SSL-ში ან WordPress-ში;
3. გადართვისა და დაბრუნების გეგმა: ვინ ასრულებს ცვლილებას და რა პირობით ბრუნდება ძველ გარემოში.

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

რისი გარანტია არ არის მფლობელობის სია

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

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

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

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

<li><a href="https://developer.wordpress.org/advanced-administration/upgrade/migrating/">ოფიციალური დოკუმენტაცია: მიგრაცია</a></li>
<li><a href="https://developer.wordpress.org/advanced-administration/security/backup/">ოფიციალური დოკუმენტაცია: სარეზერვო ასლები</a></li>
<li><a href="https://www.icann.org/resources/pages/transfer-policy-2016-06-01-en">ოფიციალური პოლიტიკა: დომენის გადაცემის წესები</a></li></ul>

ხშირი კითხვები

ვის სახელზე უნდა იყოს დომენი?

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

საკმარისია WordPress-ის ადმინისტრატორის წვდომა?

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

როდის შეიძლება DNS-ის შეცვლა?

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

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

შემდეგი ნაბიჯი: შეადგინეთ დომენის, DNS-ის, ჰოსტინგის, SSL-ისა და WordPress-ის პასუხისმგებლების სია და შემდეგ განიხილეთ გადაცემის პირობები aiWEB-ის გუნდთან.