WordPress-ის გადატანა ახალ ჰოსტზე შეფერხების გარეშე

WordPress-ის გადატანა ოთხი ნაბიჯია: დააკოპირე ფაილები, გადაიტანე მონაცემთა ბაზა, ყველგან გადაწერე საიტის URL, სადაც ის ინახება, და შემდეგ DNS ახალ მისამართზე მიმართე. თუ ამ თანმიმდევრობით გააკეთე, TTL ერთი დღით ადრე დაწიე და საიტი hosts ფაილის ჩანაწერით გატესტე, სანამ საჯაროდ რამე შეიცვლება, ვიზიტორები არანაირ შეფერხებას ვერ ხედავენ. თუ თანმიმდევრობა არასწორი იყო, ისინი ნახევრად გადატანილ საიტს დაინახავენ იმდენ ხანს, რამდენსაც მათი resolver დაიმახსოვრებს.

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

რას გადაიტან სინამდვილეში#

ხუთ რამეს, და მათგან მხოლოდ პირველი ორი გამოდის migration plugin-იდან.

• ფაილები. wp-content არის ის ნაწილი, რომელიც შენია: themes, plugins, uploads და ხშირად mu-plugins საქაღალდე, რომლის არსებობაც არავის ახსოვს. core ფაილების დაკოპირება არ არის საჭირო, ისინი ახალ ადგილას wordpress.org-დან თავიდან ჩამოიტვირთება - მიზეზი არ არის, 60 MB ფაილი გადააკოპირო, რომელიც წამში მოგაქვს.
• მონაცემთა ბაზა. ყოველი ცხრილი შენი prefix-ით. პოსტები, options, მომხმარებლები და ყველა ცხრილი, რომელიც plugin-ებმა შექმნეს - მაღაზია ან ფორუმი მონაცემების უმეტესობას ცხრილებში ინახავს, რომლებზეც core არაფერს იცის.
• `wp-config.php`, რომელსაც სანიმუშოდ აკოპირებ და შემდეგ თავიდან წერ. ახალ ჰოსტზე ბაზის credential-ები სხვა იქნება, ხოლო ძველების გამოყენება ყველაზე ხშირი მიზეზია, რის გამოც ახლადგადატანილი საიტი ბაზასთან კავშირის შეცდომას აჩვენებს.
• რაც WordPress-ის გარეთაა. გადამისამართების წესები .htaccess-ში ან სერვერის კონფიგურაციაში, cron ამოცანები, რომლებსაც ძველი ჰოსტი შენ მაგივრად უშვებდა, ხელით შეცვლილი robots.txt, IP allow სიები, SMTP API key plugin-ის პარამეტრებში.
• DNS და სერტიფიკატი. ვინც ზონას ფლობს, ისევ ფლობს; მხოლოდ ჩანაწერები იცვლება. თუ ძველი ჰოსტი ამავე დროს შენი DNS პროვაიდერი ან რეგისტრატორი იყო, ეს გადაწყვიტე გადატანის დღემდე და არა მის განმავლობაში - nameserver-ები თუ DNS ჩანაწერები განმარტავს, სამი მხარიდან რომელს ცვლი სინამდვილეში.

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

აირჩიე მეთოდი და ჯერ საიტის ზომა გაიგე#

რამის არჩევამდე ორი რიცხვი შეამოწმე: wp-content-ის ზომა და ბაზის ზომა. პანელში ან SFTP-ით ეს არის საქაღალდის ზომა და phpMyAdmin-ში ცხრილის ზომის მაჩვენებელი.

Migration plugin-ები პატარა საიტებზე მართლა კარგია და დიდებზე მართლა არასანდო, მოსაწყენი მიზეზით: ისინი საქმეს PHP მოთხოვნის შიგნით აკეთებენ, ამიტომ max_execution_time და memory_limit მოქმედებს, და 3 GB uploads საქაღალდე 30-წამიან მოთხოვნაში არ ეტევა. ჩავარდნა ჩვეულებრივ ჩუმია - არქივი, რომელიც მოკვეთილია, მაგრამ სრულად გამოიყურება. თუ შენი საიტი დიდია, გააკეთე ხელით; ქვემოთ მოცემულ ხელით გზას ხსენების ღირსი ზომის ლიმიტი არ აქვს.

დაგეგმე ფანჯარა და TTL დაწიე#

DNS ჩანაწერებს აქვთ time to live, რომელიც resolver-ებს ეუბნება, რამდენ ხანს დაიმახსოვრონ პასუხი. თუ შენს A ჩანაწერს 86,400 წამის TTL აქვს, ზოგი resolver ვიზიტორებს ძველ სერვერზე მთელი დღით გააგზავნის ცვლილების შემდეგ.

1. ორი დღით ადრე: დაწიე TTL იმ ჩანაწერებზე, რომლებსაც შეცვლი - apex-სა და www-ზე - 300 წამამდე. ეს საკმარისად ადრე უნდა გააკეთო, რომ ძველი, გრძელი TTL ყველგან ამოიწუროს.
2. შეამოწმე, გაჭრა თუ არა. dig +noall +answer example.com ბეჭდავს ჩანაწერს დარჩენილი TTL-ით. ის 300-დან უნდა ჩამოითვალოს და არა უფრო დიდი რიცხვიდან.
3. აირჩიე საათი. შენი ყველაზე მშვიდი საათი შენი ვიზიტორების და არა შენი დროის ზონით. გამოიყენე analytics და არ გამოიცნო.
4. გადაწყვიტე, რა იყინება. ბლოგისთვის - არაფერი: დაკარგული კომენტარი გადასატანია. მაღაზიისა და membership საიტისთვის ძველი საიტი maintenance რეჟიმში ჩააყენე ბაზის საბოლოო ექსპორტსა და DNS-ის შეცვლას შორის ათი წუთით და გვერდზე ეს დაწერე.
5. ძველი ჰოსტინგი კიდევ ორი კვირა გადახდილი გქონდეს. ეს არის rollback გეგმა და ინციდენტზე იაფია.

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

დააკოპირე ფაილები#

ორივე მხარეს shell წვდომით არქივი სერვერზე შექმენი და ერთი ფაილი გადაიტანე:

$ cd /var/www/example.com$ tar -czf /tmp/wp-content.tar.gz wp-content$ scp /tmp/wp-content.tar.gz user@new-host:/tmp/

shell წვდომის გარეშე იგივე გააკეთე file manager-ით: შექმენი wp-content-ის არქივი ძველ ჰოსტზე, ჩამოტვირთე ერთი ფაილი, ატვირთე ახალზე, ადგილზე ამოაარქივე. 40,000 პატარა ფაილის ჩამოტვირთვა SFTP-ით საათებს იღებს; ერთი 800 MB არქივის - წუთებს, და ეს განსხვავება მთელი ხრიკია. SFTP და file manager კავშირის დეტალებს შეიცავს.

დატოვე ის, რაც არ გჭირდება:

• ქეშის საქაღალდეები: wp-content/cache, wp-content/et-cache, ყველაფერი, რაც caching plugin-მა შექმნა. ყველაფერი თავიდან გენერირდება, ხოლო ძველი ქეშის ფაილები გადატანის შემდეგ ძველი URL-ების მიწოდების კარგი გზაა.
• backup plugin-ების არქივები wp-content-ის შიგნით. ისინი ხშირად დისკზე ყველაზე დიდი რამაა და საიტის ასლებია, რომელსაც უკვე აკოპირებ.
• error_log ფაილები, რომლებიც უზარმაზარი შეიძლება იყოს და ახალ სერვერზე არაფერს გეუბნება.

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

გადაიტანე მონაცემთა ბაზა#

shell წვდომით გააკეთე dump და ჩატვირთე:

$ mysqldump --single-transaction --default-character-set=utf8mb4 \    --add-drop-table -u olduser -p olddb > site.sql$ gzip site.sql

ახალ ჰოსტზე ჯერ შექმენი ბაზა და მომხმარებელი, შემდეგ დააიმპორტე. phpMyAdmin-ში იგივე საქმეა Export, შემდეგ Custom, შემდეგ gzip ვარიანტი, და Import მეორე მხარეს. სამი დეტალი წყვეტს, სუფთა იქნება თუ არა იმპორტი:

• `utf8mb4` თავიდან ბოლომდე. ექსპორტი და იმპორტი იმავე character set-ით გააკეთე, თორემ აქცენტიანი სიმბოლოები და emoji mojibake-ად ჩამოვა. ამას შემდეგ find-and-replace-ით ვერ გამოასწორებ.
• `--single-transaction` საიტის დაბლოკვის გარეშე თანმიმდევრულ snapshot-ს იღებს, რაც მნიშვნელოვანია, თუ დატვირთულ ბაზას აკეთებ dump-ს.
• იმპორტის ზომის ლიმიტები. phpMyAdmin-ის იმპორტი PHP-ით გადის, ამიტომ upload_max_filesize, post_max_size და max_execution_time ყველა მოქმედებს. gzip-ით შეკუმშული dump ჩვეულებრივ ოთხიდან რვაჯერ პატარაა და ხშირად ის განსხვავებაა, რაც მუშაობასა და არმუშაობას შორისაა. თუ მაინც არ ეტევა, გაყავი dump ან გაზარდე ლიმიტები - php.ini პარამეტრები, რომლებსაც მნიშვნელობა აქვს გვიჩვენებს, რომელი, ხოლო phpMyAdmin-ის იმპორტისა და ექსპორტის გზამკვლევი - პანელის მხარეს.

RE:NODE-ზე ვებ გეგმებს ორი ბაზის სლოტი აქვს, რომლებიც პანელიდან იქმნება გენერირებული host-ით, მომხმარებლითა და პაროლით. Open in phpMyAdmin ღილაკი შენ ერთჯერადი token-ით შეგიყვანს, რომელიც სამოც წამში იწურება, ამიტომ dump-ის იმპორტი ბრაუზერის ტაბში შეგიძლია გააკეთო და credential-ები არასოდეს აკრიფო ფორმაში. ეს ახალი credential-ები ჩასვი wp-config.php-ში და არა ძველები.

Search and replace, ნაბიჯი, რომელიც საიტებს ამტვრევს#

ბაზა სავსეა აბსოლუტური URL-ებით: siteurl და home options ცხრილში, ყოველი სურათის src პოსტის კონტენტში, widget-ისა და თემის პარამეტრები და plugin-ების კონფიგურაცია. თუ დომენი იცვლება ან http-დან https-ზე გადადიხარ, ყველაფერი გადასაწერია.

ამას SQL-ით ნუ გააკეთებ. ეს WordPress-ის გადატანის ყველაზე დამაზიანებელი შეცდომაა:

-- Do not do this. It corrupts every serialised setting in the table.UPDATE wp_options SET option_value = REPLACE(option_value, 'old.com', 'new.com');

WordPress მასივებს და ობიექტებს PHP serialised სტრიქონებად ინახავს, რომლებიც ყოველი მნიშვნელობის ბაიტურ სიგრძეს ჩაიწერენ. თუ ერთ-ერთში old.com-ს newsite.com-ით შეცვლი, შენახული სიგრძე აღარ ემთხვევა, ამიტომ PHP-ს unserialise არ შეუძლია და plugin-ი ან widget-ი ჩუმად ნაგულისხმევზე ბრუნდება. თემის პარამეტრები ქრება, მენიუები ცარიელდება, slider-ები ფუჭდება - და ზიანი დღეების შემდეგ ჩანს, როცა გადატანაზე ეჭვი დიდი ხანია შეწყვიტე.

გამოიყენე ინსტრუმენტი, რომელსაც serialisation ესმის. WP-CLI-ით:

$ wp search-replace 'https://old.example.com' 'https://example.com' \    --all-tables --precise --dry-run$ wp search-replace 'https://old.example.com' 'https://example.com' --all-tables

ჯერ dry run გაუშვი, წაიკითხე რაოდენობების ცხრილი, შემდეგ ნამდვილად გაუშვი. shell წვდომის გარეშე Better Search Replace plugin იგივე საქმეს admin-იდან აკეთებს და მასაც აქვს dry-run რეჟიმი. ცალკე Search Replace DB სკრიპტიც მუშაობს, ერთი წესით: მუშაობის დასრულებისთანავე წაშალე. სკრიპტი, რომელიც შენს ბაზას გადაწერს და გამოსაცნობ URL-ზე დგას, სრული გატეხვაა, რომელიც აღმოჩენას ელოდება.

თუ ფაილური სისტემის გზაც შეიცვალა - /home/olduser/public_html რამე სხვაზე - ძველი გზაც მოძებნე. რამდენიმე plugin აბსოლუტურ გზებს ინახავს და როცა გზა აღარ არსებობს, დამაბნეველად ფუჭდება.

გატესტე DNS-ის შეხებამდე#

ახალ საიტს შეგიძლია მისი ნამდვილი დომენის სახელით დაათვალიერო საჯაროდ არაფრის შეცვლის გარეშე, თუ შენს მანქანას ეტყვი, სად ეძებოს. hosts ფაილში დაამატე ერთი ხაზი - C:\Windows\System32\drivers\etc\hosts Windows-ზე, /etc/hosts macOS-სა და Linux-ზე:

203.0.113.25    example.com www.example.com

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

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

• მთავარი გვერდი, პოსტი, კატეგორიის არქივი, ფორმიანი გვერდი და ძებნის შედეგები.
• /wp-admin: შედი, გახსენი plugins ეკრანი, შეამოწმე, არაფერი წერს დაკარგულ ცხრილზე.
• Permalinks: გახსენი ნებისმიერი არამთავარი URL. 404 ყველა გვერდზე მთავარის გარდა ნიშნავს, რომ rewrite წესები ჯერ არ არის ადგილზე.
• სურათები: გახსენი მედიით პოსტი და დარწმუნდი, რომ ფაილები ახალი ჰოსტიდან იტვირთება.
• მაღაზია: კალათა, checkout გადახდის ნაბიჯამდე და ერთი სატესტო შეკვეთა gateway-ის sandbox-ში.
• ყველაფერი, რაც გრაფიკზეა: გაუშვი cron event ხელით და ნახე, სრულდება თუ არა.

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

თავად გადართვა#

300-წამიანი TTL-ით და გატესტილი ახალი საიტით გადართვა მოკლეა.

1. ძველი საიტი maintenance რეჟიმში ჩააყენე, ან უბრალოდ მიიღე რისკი, თუ არაფერი იწერება.
2. ბაზა კიდევ ერთხელ დააექსპორტე და ახალი ჰოსტის ასლის ზემოდან დააიმპორტე. ეს მეორე გავლა ჩვეულებრივ რამდენიმე წუთის სამუშაოა და ყველაფერს იჭერს, რაც პირველი ასლის შემდეგ ჩაიწერა. ახალი uploads იმავე გზით დაასინქრონე.
3. სუფთა იმპორტზე search-replace ხელახლა გაუშვი. ეს მონაცემების ახალი ასლია; ძველი URL-ები მასში დაბრუნდა.
4. შეცვალე A ჩანაწერი apex-სა და www-ზე ახალ მისამართზე. ზონაში სხვა არაფერი შეცვალო: MX ჩანაწერები იქვე რჩება, სადაც იყო, რაც ფოსტას მუშა მდგომარეობაში ინახავს.
5. უყურე ახალი ჰოსტის კონსოლს ან access ლოგს. ტრაფიკი წუთ-ორ წუთში უნდა გამოჩნდეს და გაიზარდოს, რაც resolver-ები ქეშირებულ პასუხებს ამოწურავენ.
6. ძველი საიტი წაშლის ნაცვლად maintenance რეჟიმში დატოვე. ეს შენი rollback-ია და ხელს უშლის დამაგვიანებლებს, რომ ბაზაში ჩაწერონ, რომელსაც თავს ანებებ.

სერტიფიკატს აქვს თანმიმდევრობის პრობლემა, რომელიც მოსალოდნელია. გაცემა ამოწმებს, რომ სახელი ნამდვილად იმ სერვერზე მიუთითებს, რომელიც მას ითხოვს, ამიტომ example.com-ის სერტიფიკატი ახალ ჰოსტზე ჩვეულებრივ ვერ გაიცემა, სანამ DNS უკვე იქ არ მიუთითებს. ეს არის წამებიდან წუთებამდე ფანჯარა ჩანაწერის შეცვლასა და სერტიფიკატის გამოჩენას შორის, რომლის განმავლობაშიც ვიზიტორმა გაფრთხილება შეიძლება დაინახოს. RE:NODE-ზე ამას proxy სლოტი აგვარებს: მიუთითე A ჩანაწერი ამ ტაბზე ნაჩვენებ მისამართზე და სერტიფიკატი გაიცემა, როგორც კი სახელი გადაიჭრება, შემდეგ კი ავტომატურად განახლდება 21-დღიან ფანჯარაში. HTTPS და Let's Encrypt ახსნილი თავად ვალიდაციას გადის.

გადართვის შემდეგ და რა ფუჭდება#

პირველ საათში: Settings-ში permalinks ხელახლა შეინახე, რომ rewrite წესები თავიდან დაგენერირდეს, დაადასტურე HTTPS რამდენიმე URL-ზე, გაგზავნე სატესტო წერილი საკონტაქტო ფორმიდან და შეამოწმე, მუშაობს თუ არა დაგეგმილი პოსტები და cron event-ები. პირველ კვირაში: უყურე 404-ებს URL-ებიდან, რომლებზეც არ იცოდი, რომ არსებობდა, და ხელახლა შეამოწმე search console crawl შეცდომებზე.

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

Error establishing a database connection. wp-config.php ისევ ძველი ჰოსტის credential-ებს შეიცავს, ან DB_HOST არის localhost იქ, სადაც რეალური hostname სჭირდება.

საიტი ძველ დომენზე გადამისამართებს. siteurl და home options ცხრილში არ გადაიწერა. დროებით გადააფარე WP_HOME და WP_SITEURL wp-config.php-ში, შემდეგ ბაზა წესიერად გამოასწორე.

Mixed content გაფრთხილებები. ძველი http:// URL-ები ისევ პოსტის კონტენტშია. search-replace ხელახლა გაუშვი scheme-ზე და არა მხოლოდ hostname-ზე.

მენიუები ცარიელია, თემის პარამეტრები განულებულია. serialised მონაცემები უბრალო SQL replace-მა დააზიანა. აღადგინე ბაზა იმ ნაბიჯამდე არსებულით და გაიმეორე სათანადო ინსტრუმენტით. ნაწილობრივი გამოსწორება არ არსებობს.

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

ელფოსტა წყდება. ფოსტა ვებ სერვერს არ მიჰყვება. MX ჩანაწერები შენს ფოსტის პროვაიდერთან რჩება, ხოლო საიტის ტრანზაქციული ფოსტა SMTP plugin-ს სჭირდება, რომელიც პროვაიდერზე მიუთითებს და ის შენ ავთენტიფიკაციას გაგივლის - RE:NODE ფოსტას არ უმასპინძლებს, ამიტომ ამაზე ადრე იფიქრე და არ აღმოაჩინო გვიან. SPF, DKIM და DMARC ახსნილი გვიჩვენებს, რატომ აქვს ჩანაწერებს გადატანის შემდეგაც მნიშვნელობა.

ყველაფერი მუშაობს, მაგრამ საიტი ნელია. ახალი ინსტალაცია page cache-ის გარეშე და OPcache ჯერ ცივია. ხელახლა დააყენე caching plugin და დააკონფიგურირე, სანამ დასკვნებს გამოიტან - WordPress-ის სიჩქარე და caching გვიჩვენებს, რა თანმიმდევრობით გააკეთო.

FAQ#

რამდენ ხანს გრძელდება WordPress-ის გადატანა?

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

გაითიშება ჩემი საიტი გადატანისას?

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

შეიძლება გადატანა დომენის შეცვლის გარეშე?

დიახ, და ეს მარტივი შემთხვევაა: hostname-ისთვის search-replace არ არის საჭირო, მხოლოდ scheme-ისთვის, თუ ამავე დროს HTTPS-ზეც გადადიხარ. გატესტე hosts ფაილის ჩანაწერით და საიტი ზუსტად ისე იქცევა, როგორც გადართვის შემდეგ.

უნდა გამოვიყენო migration plugin თუ ხელით გავაკეთო?

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

რა ვუყო ძველ ჰოსტინგს?

გადახდილი და maintenance რეჟიმში დატოვე ორი კვირა. ის პირველი დღის rollback-ია და შემდგომი ორი კვირის მინიშნება, როცა აღმოაჩენ cron ამოცანას ან გადამისამართების წესს, რომელიც არასოდეს იცოდი. გაუქმებამდე გააკეთე საბოლოო სრული ასლი.

უნდა ვაცნობო საძიებო სისტემებს, რომ საიტი გადავიდა?

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