როგორ გავასწოროთ 404 შეცდომები ვებსაიტის ან აპის დეპლოიმენტის შემდეგ

თუ თქვენი აპი ლოკალურად მუშაობს, მაგრამ დეპლოის შემდეგ გვერდები 404-ს აბრუნებს, ყველაზე ხშირი მიზეზი ერთგვერდიანი აპის (SPA) როუტინგის არარსებობაა: სერვერი ეძებს ფაილს სახელად /dashboard, რომელიც არ არსებობს, რადგან ეს მარშრუტი მხოლოდ JavaScript-ში არსებობს. გამოსავალი არის fallback წესი, რომელიც აპის მარშრუტებისთვის index.html-ს აბრუნებს. სხვა მიზეზებია build შედეგში დაკარგული ფაილები, რეგისტრზე მგრძნობიარე გზები, ბოლო სლეშის განსხვავებები, არასწორი base path და API მარშრუტები, რომლებიც არ დეპლოიდა.

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

ნაბიჯი 1: იპოვეთ ნიმუში

რეალური სტატუს კოდის სანახავად გახსენით დეველოპერის ხელსაწყოები (მარჯვენა ღილაკი → Inspect), გადადით Network ჩანართზე, განაახლეთ გვერდი და შეხედეთ პირველი მოთხოვნის სტატუსს.

ნაბიჯი 2: დაამატეთ SPA fallback

ეს კლასიკური შემთხვევაა. React, Vue ან Svelte ერთგვერდიან აპში სერვერს რამდენიმე რეალური ფაილი აქვს: index.html და რამდენიმე JavaScript და CSS ფაილი. ისეთი მარშრუტები, როგორიცაა /dashboard ან /projects/42, ბრაუზერში მარშრუტიზატორის მიერ მუშავდება.

• ბმულზე დაწკაპუნება მუშაობს: მარშრუტიზატორი ცვლის URL-ს და ხატავს ახალ გვერდს სერვერისგან კითხვის გარეშე.
• განახლება ან პირდაპირ ბმულზე გახსნა არ მუშაობს: ბრაუზერი სერვერს /dashboard-ს სთხოვს, სერვერს ასეთი ფაილი არ აქვს და 404-ს აბრუნებს.

გამოსავალი არის წესი, რომელიც ამბობს: თუ მოთხოვნა რეალურ ფაილს არ ემთხვევა, დააბრუნე index.html 200 სტატუსით და მარშრუტიზატორმა დაიწყოს მუშაობა. როგორ დაამატებთ, დამოკიდებულია ჰოსტზე (შეამოწმეთ ჰოსტის მიმდინარე დოკუმენტაცია, რადგან დეტალები იცვლება):

დარწმუნდით, რომ წესი არ შთანთქავს რეალურ ფაილებს: მოთხოვნებმა /assets/app.js-ზე მაინც JavaScript ფაილი უნდა დააბრუნოს. თუ index.html-ს აბრუნებს, მიიღებთ ცარიელ გვერდს და შეცდომას „Failed to load module script". იხილეთ როგორ გავასწოროთ ცარიელი თეთრი გვერდი.

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

თუ სერვერის პარამეტრებს ვერ შეცვლით, hash როუტინგი (URL-ები როგორიცაა /#/dashboard) პრობლემას თავს არიდებს, რადგან #-ის შემდეგ ნაწილი სერვერს არასდროს ეგზავნება. ეს გამოსავალია, არა პირველი არჩევანი: URL-ები უფრო უსახური და საძიებო სისტემებისთვის ნაკლებად მეგობრულია.

ფრეიმვორკები, რომლებიც გვერდებს სერვერზე ან build-ის დროს აგენერირებენ (Next.js, Astro და მსგავსი), ჩვეულებრივ აქვს რეალური ფაილები ან სერვერული მარშრუტები თითოეული გვერდისთვის, ამიტომ ეს კონკრეტული პრობლემა იქ ნაკლებად გავრცელებულია. მათი ეკვივალენტი არის გვერდი, რომელიც build-ის დროს არასდროს დაგენერირდა.

ნაბიჯი 3: შეამოწმეთ, რა დეპლოიდა

თუ ყველაფერი 404-ს იძლევა, სერვერი ალბათ არ ემსახურება თქვენს აშენებულ აპს.

• სწორი საქაღალდე. ჰოსტმა უნდა გამოაქვეყნოს build-ის შედეგი (Vite-ისთვის ჩვეულებრივ dist, Create React App-ისთვის build, სტატიკური Next.js ექსპორტისთვის out), და არა პროექტის ძირი.
• build გაეშვა. წაიკითხეთ დეპლოის ჟურნალი. თუ build ჩაიშალა, ჰოსტმა შეიძლება არაფერი დაადეპლოიროს, ან ძველი ვერსია დატოვოს.
• index.html გამოქვეყნებული საქაღალდის ზედა დონეზეა, და არა ქვესაქაღალდეში.
• base path ემთხვევა. თუ აპი example.com/app/-ზე მუშაობს, build უნდა მოხდეს ამ base-ით (Vite-ის base, React Router-ის basename), წინააღმდეგ შემთხვევაში ყველა მარშრუტი და რესურსი დაკარგული იქნება.

ნაბიჯი 4: გაასწორეთ დაკარგული ფაილები და არასწორი გზები

როცა გვერდები იტვირთება, მაგრამ რესურსები 404-ს იძლევა:

• რეგისტრის მგრძნობელობა. macOS და Windows ჩვეულებრივ Logo.png-ს და logo.png-ს ერთ ფაილად თვლის. უმეტესობა Linux სერვერისა — არა. გაუსწორეთ ყველა მითითება ფაილის ზუსტ სახელს.
• ფაილები build-ის გარეთ. Vite-ში public/-ში არსებული ფაილები უცვლელად კოპირდება და ძირიდან მიემართება (/logo.png). კოდში იმპორტირებული ფაილები ერთიანდება. პროექტის სხვა ადგილას მდებარე ფაილი შეიძლება საერთოდ არ დეპლოიდეს.
• ფარდობითი გზები. images/photo.jpg მიმდინარე URL-ის მიმართ იხსნება, ამიტომ /blog/post-1-ზე ირღვევა. გამოიყენეთ /images/photo.jpg.
• სერვერის დისკზე შენახული ატვირთვები. თუ მომხმარებელთა ატვირთვები სერვერის საკუთარ საქაღალდეში ინახებოდა, ისინი ახალი ვერსიის დეპლოისას ქრება. გამოიყენეთ სათანადო ფაილების საცავი.

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

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

ნაბიჯი 6: გაასწორეთ API მარშრუტები, რომლებიც 404-ს იძლევა

თუ გვერდი იტვირთება, მაგრამ Network ჩანართში /api/... მოთხოვნები 404-ს აბრუნებს:

• backend არ არის დეპლოებული. სტატიკური ჰოსტი მხოლოდ ფაილებს ემსახურება; backend სადმე უნდა მუშაობდეს.
• გზა სხვაგვარად არის მარშრუტიზებული წარმოებაში. განვითარების დროს პროქსიმ შეიძლება /api სხვა სერვერზე გადაამისამართა. წარმოებაში ჰოსტს ეკვივალენტური rewrite სჭირდება, ან ფრონტენდმა უნდა მიმართოს API-ს რეალურ მისამართს.
• SPA fallback-მა დაიჭირა. API მოთხოვნა, რომელიც index.html-ს 200 სტატუსით აბრუნებს, ნიშნავს, რომ fallback წესი ძალიან ფართოა. /api/* გამოიტოვეთ მისგან.

გამოქვეყნებული აპის მოთხოვნები /api/orders 404-ს აბრუნებს, მაგრამ გადახედვაში მუშაობს. შეამოწმე, როგორ არის /api მარშრუტიზებული გადახედვაში და გამოქვეყნებულ აპში, და გახადე გამოქვეყნებული ფრონტენდი backend-ს იმავე გზით მიაღწევდეს.

ნაბიჯი 7: გადაამისამართეთ ძველი URL-ები

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

ნაბიჯი 8: შეამოწმეთ დომენი

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

გახადეთ რეალური 404 გვერდი სასარგებლო

ზოგი 404 სწორია: ვიღაცამ URL არასწორად აკრიფა. გახადეთ ეს გვერდი სასარგებლო:

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

სადაც თქვენი დაყენება ამის საშუალებას იძლევა, არ არსებული გვერდებისთვის დააბრუნეთ რეალური 404 სტატუსი. „ვერ მოიძებნა" შეტყობინება, რომელიც 200 სტატუსით მოდის, საძიებო სისტემები soft 404-ად მიიჩნევენ, და ეს მათ crawl დროს აკარგვინებს და ინდექსირებას ურევს.

გავრცელებული შეცდომები

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

404 Mythex-ში

Mythex-ში აქვეყნებთ სამუშაო სივრციდან, და სტატიკური ფრონტენდები სტატიკურ საიტებად ავრცელებს. თუ გამოქვეყნებული გვერდი 404-ს იძლევა, აგენტს მიეცით ზუსტი URL, თქვენ მიერ აღწერილი ქცევა (განახლებისას, დაწკაპუნებისას თუ ორივე) და რას აჩვენებს Network ჩანართი, და სთხოვეთ მარშრუტიზაციის შემოწმება. გასწორების შემდეგ კვლავ გამოაქვეყნეთ, რადგან ცოცხალი აპი სნეპშოტია, სანამ ხელახლა არ გამოაქვეყნებთ. თუ ახლახან შეცვალეთ პროექტი და ცოცხალი საიტი ძველად გამოიყურება, კვლავ გამოაქვეყნეთ და გააკეთეთ hard refresh. თუ build ჩაიშალა, გამოიყენეთ Fix with AI გამოქვეყნების დიალოგში. იხილეთ დოკუმენტაციაში How to publish და Publish troubleshooting, და ჩვენი სახელმძღვანელო AI-ით აშენებული აპის გამართვა.

404 საკონტროლო სია

• ჩაინიშნა, რომელი URL-ები იძლევა 404-ს და ხდება თუ არა დაწკაპუნებისას, განახლებისას თუ ორივეში
• SPA fallback აბრუნებს index.html-ს აპის მარშრუტებისთვის, 200 სტატუსით
• fallback გამორიცხავს რეალურ ფაილებსა და /api/*-ს
• მარშრუტიზატორს აქვს დამჭერი მარშრუტი „ვერ მოიძებნა"
• build-ის შედეგის საქაღალდე არის ის, რაც გამოქვეყნდება, და build წარმატებული იყო
• base path ემთხვევა იმ ადგილს, სადაც აპი მუშაობს
• ფაილის სახელების რეგისტრი ემთხვევა ყველა მითითებას
• რესურსების გზები იწყება /-ით
• ბოლო სლეშის სტილი თანმიმდევრულია
• API მარშრუტები დეპლოებულია და წარმოებაში მარშრუტიზებულია
• 301 გადამისამართებები ძველი URL-ებისთვის
• ღრმა ბმულები გამოცდილია ახალ ჩანართში ჩასმით

კითხვები