როგორ გადავიტანოთ WordPress საიტი მოთხოვნების დაკარგვის გარეშე

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

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

ჩამოწერეთ მოთხოვნის ყველა გზა

გააკეთეთ ფორმების ინვენტარი და თითოეულ ჩანაწერს დაურთეთ:

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

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

ვალიდაციის ფენები

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

ელფოსტა და ავტომატური პასუხი

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

შეამოწმეთ სათაური, გამგზავნის მისამართი, reply-to, ძირითადი ველების ასახვა და ბმული, რომელსაც მომხმარებელი იღებს. თუ მოთხოვნა CRM-ში უნდა გადავიდეს, დადასტურეთ ჩანაწერის შექმნა და ველის შესაბამისობა. მხოლოდ „გაგზავნილია“ შეტყობინება მიღებას არ ადასტურებს.

URL-ები და კამპანიის გზა

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

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

უსაფრთხო გადატანის თანმიმდევრობა

1. გადაიღეთ WordPress-ის მონაცემთა ბაზისა და ფაილების ასლები;
2. staging-ზე გადაიტანეთ ერთი სრულად შევსებული ფორმა და მისი მიღების გზა;
3. გაიმეორეთ სწორი, არასრული და არასწორი შეყვანის ტესტები;
4. დაადასტურეთ მიმღები, CRM ან სხვა შემდგომი დამუშავება;
5. cutover-ის შემდეგ ისევ გაგზავნეთ კონტროლირებული შეტყობინება და შეინახეთ შედეგი.

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

სცენარი: საკონსულტაციო კომპანიის შეფასების ფორმა

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

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

ფორმის მიგრაციის გზების შედარება

ტესტის მტკიცებულების საზღვარი

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

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

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

მოთხოვნის გზის დაკავშირებული გეგმები

• staging და cutover გეგმა
• ფორმიანი URL-ების redirect
• დომენისა და ჰოსტინგის მფლობელობა
• ძველი საიტის სამაშველო შემოწმება
• კონტენტის აუდიტი
• რედაქტორის workflow
• aiWEB პროექტის განხილვა

<li><a href="https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Forms/Form_validation">ოფიციალური სახელმძღვანელო: ფორმის შემოწმება</a></li>
<li><a href="https://developer.wordpress.org/advanced-administration/upgrade/migrating/">ოფიციალური დოკუმენტაცია: მიგრაცია</a></li>
<li><a href="https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes">ოფიციალური მითითება: საიტის გადატანა</a></li></ul>

კითხვები ფორმების გადატანაზე

ფორმის გახსნა ნიშნავს, რომ მოთხოვნა მუშაობს?

არა. საჭიროა სწორი და არასწორი მონაცემის ტესტი, სერვერის პასუხი, მიმღების მიღება და ბიზნესის შემდგომი დამუშავების დადასტურება.

საჭიროა თუ არა ძველი ფორმის ზუსტად კოპირება?

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

როგორ დავამტკიცოთ, რომ მოთხოვნა არ დაიკარგა?

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

რა უნდა ჩაიწეროს ფორმის ტესტის მტკიცებულებაში?

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

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

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