{"id":602,"date":"2026-09-10T12:31:53","date_gmt":"2026-09-10T12:31:53","guid":{"rendered":"https:\/\/www.vps.tc\/blog\/?p=602"},"modified":"2026-09-10T09:40:04","modified_gmt":"2026-09-10T09:40:04","slug":"404-hatasi-nedir-sebepleri-ve-cozum-yollari","status":"publish","type":"post","link":"https:\/\/www.vps.tc\/blog\/tr\/404-hatasi-nedir-sebepleri-ve-cozum-yollari\/","title":{"rendered":"404 Hatas\u0131 Nedir? Sebepleri ve \u00c7\u00f6z\u00fcm Yollar\u0131"},"content":{"rendered":"
\u0130\u00e7indekiler<\/strong><\/p>\n
    \n
  1. 404 hatas\u0131 nedir?<\/a><\/li>\n
  2. 404 hatas\u0131 neden olur?<\/a><\/li>\n
  3. 404 hatas\u0131 nas\u0131l kontrol edilir?<\/a><\/li>\n
  4. Sunucu taraf\u0131nda 404 nas\u0131l d\u00fczeltilir?<\/a><\/li>\n
  5. 404 sayfas\u0131 nas\u0131l haz\u0131rlanmal\u0131?<\/a><\/li>\n
  6. 404, 403, 410 ve 500 aras\u0131ndaki fark nedir?<\/a><\/li>\n
  7. 404 hatas\u0131n\u0131 \u00f6nlemek i\u00e7in neler yap\u0131labilir?<\/a><\/li>\n
  8. S\u0131k Sorulan Sorular<\/a><\/li>\n
  9. Kaynaklar<\/a><\/li>\n<\/ol>\n<\/div>\n

    404 hatas\u0131 nedir?<\/h2>\n

    Bir gece m\u00fc\u015fteri sitesinin ana sayfas\u0131 a\u00e7\u0131l\u0131yor, fakat \u00fcr\u00fcn ba\u011flant\u0131lar\u0131n\u0131n tamam\u0131 404 d\u00f6n\u00fcyordu. \u0130lk bak\u0131\u015fta uygulama \u00e7\u00f6km\u00fc\u015f gibi g\u00f6r\u00fcn\u00fcyordu; loglar\u0131 a\u00e7\u0131nca durum daha sakindi: Nginx iste\u011fi al\u0131yor, dosyay\u0131 ya da uygulama rotas\u0131n\u0131 bulamad\u0131\u011f\u0131 i\u00e7in yan\u0131t veriyordu.<\/p>\n

    404 hatas\u0131, istemcinin sunucuya ula\u015ft\u0131\u011f\u0131 ancak sunucunun istenen kayna\u011f\u0131 bulamad\u0131\u011f\u0131 anlam\u0131na gelen HTTP durum kodudur. Genellikle silinmi\u015f veya ta\u015f\u0131nm\u0131\u015f bir sayfa, yanl\u0131\u015f yaz\u0131lm\u0131\u015f URL, hatal\u0131 y\u00f6nlendirme ya da web sunucusu yap\u0131land\u0131rmas\u0131 nedeniyle g\u00f6r\u00fcl\u00fcr. Sunucu \u00e7al\u0131\u015f\u0131yor olabilir; sorun \u00e7o\u011fu zaman belirli kayna\u011f\u0131n adresindedir.<\/p>\n

    Bir ziyaret\u00e7i taray\u0131c\u0131da sayfa adresini a\u00e7t\u0131\u011f\u0131nda taray\u0131c\u0131 HTTP iste\u011fi g\u00f6nderir. Sunucu iste\u011fi al\u0131r, fakat URL ile e\u015fle\u015fen dosya, rota veya uygulama kayd\u0131 bulamazsa yan\u0131t durumunu 404 Not Found<\/code> olarak d\u00f6nd\u00fcr\u00fcr. MDN dok\u00fcmantasyonundaki tan\u0131m da bu noktaya dayan\u0131r: sunucu istenen kayna\u011f\u0131 bulamam\u0131\u015ft\u0131r, fakat kayna\u011f\u0131n neden bulunamad\u0131\u011f\u0131n\u0131 ayr\u0131ca a\u00e7\u0131klamak zorunda de\u011fildir.<\/p>\n

    Buradaki ayr\u0131m \u00f6nemli. 404, sunucunun mutlaka kapal\u0131 oldu\u011funu s\u00f6ylemez. Hatta sunucu, PHP ve veritaban\u0131 gayet sa\u011fl\u0131kl\u0131 \u00e7al\u0131\u015f\u0131rken yaln\u0131zca bir \u00fcr\u00fcn sayfas\u0131 i\u00e7in 404 d\u00f6nd\u00fcrebilir. \u0130stek ile kayna\u011f\u0131n kendisini birbirinden ay\u0131rmadan yap\u0131lan her te\u015fhis biraz tahminden ibaret kal\u0131r.<\/p>\n

    404 hatas\u0131 neden olur?<\/h2>\n

    Bir URL’nin 404 d\u00f6nd\u00fcrmesinin tek bir nedeni yoktur. Kullan\u0131c\u0131 taraf\u0131nda basit bir yaz\u0131m hatas\u0131 olabilir; sunucu taraf\u0131nda ise dosya yolu, rewrite kural\u0131, uygulama rotas\u0131 veya proxy ayar\u0131 devreye girer. En s\u0131k kar\u015f\u0131la\u015ft\u0131\u011f\u0131m nedenleri a\u015fa\u011f\u0131da ayr\u0131 ayr\u0131 ele ald\u0131m.<\/p>\n

    Yanl\u0131\u015f veya eksik URL<\/h3>\n

    Adres \u00e7ubu\u011funda tek bir karakterin eksik olmas\u0131 bile yeterlidir. \/urunler\/telefon<\/code> ile \/urun\/telefon<\/code> ayn\u0131 kaynak de\u011fildir. URL’lerde b\u00fcy\u00fck-k\u00fc\u00e7\u00fck harf duyarl\u0131l\u0131\u011f\u0131 da i\u015fletim sistemine ve web sunucusuna g\u00f6re fark yaratabilir. Linux \u00fczerinde urunler.html<\/code> ile Urunler.html<\/code> farkl\u0131 dosyalard\u0131r.<\/p>\n

    Ba\u011flant\u0131y\u0131 bir e-posta veya sosyal medya payla\u015f\u0131m\u0131ndan a\u00e7an kullan\u0131c\u0131, adresin sonuna nokta ya da parantez gibi metin i\u015faretlerini de ta\u015f\u0131yabilir. B\u00f6yle durumlarda sunucuda hata aramadan \u00f6nce taray\u0131c\u0131daki ger\u00e7ek URL’yi kopyalay\u0131p incelemek daha h\u0131zl\u0131d\u0131r.<\/p>\n

    Sayfa silinmi\u015f veya ta\u015f\u0131nm\u0131\u015f olabilir<\/h3>\n

    \u0130\u00e7erik y\u00f6netim sistemlerinde slug de\u011fi\u015fikli\u011fi, \u00fcr\u00fcn silme, kategori ta\u015f\u0131ma veya kal\u0131c\u0131 ba\u011flant\u0131 yap\u0131s\u0131n\u0131n de\u011fi\u015ftirilmesi eski adresleri ge\u00e7ersiz b\u0131rak\u0131r. Kaynak ger\u00e7ekten kal\u0131c\u0131 olarak kald\u0131r\u0131ld\u0131ysa 404 do\u011fru yan\u0131t olabilir. Kaynak yeni bir adrese ta\u015f\u0131nd\u0131ysa eski URL i\u00e7in \u00e7o\u011funlukla 301<\/code> y\u00f6nlendirmesi tercih edilir.<\/p>\n

    Her eski adresi ana sayfaya y\u00f6nlendirmek iyi bir \u00e7\u00f6z\u00fcm de\u011fildir. Kullan\u0131c\u0131 belirli bir \u00fcr\u00fcn veya yaz\u0131 ar\u0131yorsa ana sayfaya g\u00f6nderilmesi, teknik olarak ba\u015far\u0131l\u0131 g\u00f6r\u00fcnen ama pratikte i\u015fe yaramayan bir y\u00f6nlendirme yarat\u0131r. Uygun yeni adres varsa oraya, yoksa anlaml\u0131 bir 404 sayfas\u0131na gitmelidir.<\/p>\n

    Web sunucusunda dosya yolu veya k\u00f6k dizin yanl\u0131\u015f\u0131<\/h3>\n

    Nginx ya da Apache, iste\u011fi yanl\u0131\u015f root<\/code> dizinine ba\u011fl\u0131yorsa mevcut dosyay\u0131 bulamaz. \u00d6rne\u011fin site dosyalar\u0131 \/var\/www\/example\/public<\/code> alt\u0131nda dururken yap\u0131land\u0131rmada k\u00f6k dizin \/var\/www\/example<\/code> se\u00e7ilmi\u015fse, beklenen index.php<\/code> veya statik dosyalar farkl\u0131 bir yerde aran\u0131r.<\/p>\n

    Nginx’in root<\/code>, alias<\/code> ve try_files<\/code> y\u00f6nergeleri bu a\u015famada \u00f6zellikle \u00f6nemlidir. Nginx dok\u00fcmantasyonunda da try_files<\/code> y\u00f6nergesinin dosyalar\u0131 verilen s\u0131rayla kontrol edip son parametreye y\u00f6nlendirebildi\u011fi belirtilir. K\u00fc\u00e7\u00fck g\u00f6r\u00fcnen bir yol fark\u0131, b\u00fct\u00fcn uygulamay\u0131 404 sayfas\u0131na \u00e7evirebilir.<\/p>\n

    CMS kal\u0131c\u0131 ba\u011flant\u0131lar\u0131 veya rewrite kurallar\u0131 bozulmu\u015f olabilir<\/h3>\n

    WordPress gibi sistemlerde kullan\u0131c\u0131 dostu URL’ler \u00e7o\u011fu zaman ger\u00e7ek bir dosyaya de\u011fil, uygulaman\u0131n \u00f6n denetleyicisine aktar\u0131l\u0131r. Nginx veya Apache bu aktar\u0131m\u0131 yapamazsa ana sayfa a\u00e7\u0131l\u0131rken yaz\u0131 ve kategori sayfalar\u0131 404 verebilir.<\/p>\n

    WordPress’te kal\u0131c\u0131 ba\u011flant\u0131 ayarlar\u0131n\u0131 kaydetmek, baz\u0131 Apache kurallar\u0131n\u0131n yeniden olu\u015fturulmas\u0131na yard\u0131mc\u0131 olabilir. Nginx kullan\u0131lan bir VPS’te ise bu i\u015flem tek ba\u015f\u0131na yeterli de\u011fildir; ilgili location<\/code> blo\u011fu ve PHP \u00f6n denetleyicisine yap\u0131lan y\u00f6nlendirme ayr\u0131ca kontrol edilmelidir. \u00d6nce yedek almak, sonra yap\u0131land\u0131rmay\u0131 de\u011fi\u015ftirmek gerekir. Bir ayar\u0131 kaydetmek i\u00e7in panelde d\u00fc\u011fmeye basmak geri d\u00f6n\u00fc\u015f plan\u0131 de\u011fildir.<\/p>\n

    DNS de\u011fi\u015fikli\u011fi yanl\u0131\u015f sunucuya g\u00f6t\u00fcr\u00fcyor olabilir<\/h3>\n

    Bazen 404 \u00fcreten sunucu, sitenin do\u011fru sunucusu bile de\u011fildir. DNS kayd\u0131 eski VPS’i, CDN’i, staging makinesini veya varsay\u0131lan sanal host’u g\u00f6steriyorsa ziyaret\u00e7i beklemedi\u011fi bir sunucunun 404 sayfas\u0131n\u0131 g\u00f6r\u00fcr.<\/p>\n

    DNS taraf\u0131nda isim \u00e7\u00f6z\u00fcmleme sorunlar\u0131n\u0131 ay\u0131rmak i\u00e7in dig<\/code> ile ba\u015flayan basit kontroller yeterli olabilir. DNS kay\u0131tlar\u0131n\u0131 de\u011fi\u015ftirdiyseniz \u00f6nbellek s\u00fcreleri nedeniyle farkl\u0131 a\u011flardan farkl\u0131 sonu\u00e7lar g\u00f6r\u00fclebilir. Bu noktada DNS_PROBE_FINISHED_NXDOMAIN Hatas\u0131 Nas\u0131l \u00c7\u00f6z\u00fcl\u00fcr?<\/a> ba\u015fl\u0131kl\u0131 i\u00e7erikteki NXDOMAIN ile 404 aras\u0131ndaki ayr\u0131m\u0131 da hat\u0131rlamak faydal\u0131d\u0131r: NXDOMAIN, alan ad\u0131n\u0131n \u00e7\u00f6z\u00fcmlenemedi\u011fini; 404 ise HTTP sunucusuna ula\u015f\u0131ld\u0131\u011f\u0131n\u0131 g\u00f6sterir.<\/p>\n

    Proxy, CDN veya uygulama rotas\u0131 kaynakl\u0131 404<\/h3>\n

    Reverse proxy kullanan yap\u0131larda istek \u00f6nce Nginx’e, CDN’e veya y\u00fck dengeleyiciye gelir; ard\u0131ndan uygulama sunucusuna aktar\u0131l\u0131r. Proxy \u00fczerindeki location<\/code> e\u015fle\u015fmesi yanl\u0131\u015fsa istek uygulamaya hi\u00e7 ula\u015fmadan 404 \u00fcretilebilir. Uygulama ula\u015f\u0131yor fakat rota tan\u0131ml\u0131 de\u011filse bu kez 404’\u00fc uygulaman\u0131n kendisi d\u00f6nd\u00fcr\u00fcr.<\/p>\n

    Yan\u0131t ba\u015fl\u0131klar\u0131, hatan\u0131n hangi katmanda olu\u015ftu\u011funa dair ipucu verir. Server<\/code>, Via<\/code>, \u00f6zel CDN ba\u015fl\u0131klar\u0131 veya uygulamaya \u00f6zg\u00fc hata ba\u015fl\u0131klar\u0131 tek ba\u015f\u0131na kesin kan\u0131t de\u011fildir; fakat loglarla birlikte olduk\u00e7a de\u011ferlidir.<\/p>\n

    404 hatas\u0131 nas\u0131l kontrol edilir?<\/h2>\n

    Taray\u0131c\u0131daki hata sayfas\u0131na bak\u0131p hemen dosya silmek veya sunucuyu yeniden ba\u015flatmak genellikle k\u00f6t\u00fc bir ba\u015flang\u0131\u00e7t\u0131r. Ben \u00f6nce iste\u011fin ger\u00e7ekten nereye gitti\u011fini, hangi HTTP durumunu ald\u0131\u011f\u0131n\u0131 ve yan\u0131t\u0131n hangi katmandan geldi\u011fini ay\u0131r\u0131r\u0131m.<\/p>\n

    1. URL’yi do\u011frudan test edin<\/h3>\n

    \u00d6nce adresi kopyalay\u0131n, gereksiz bo\u015fluklar\u0131 temizleyin ve alan ad\u0131yla birlikte tam olarak test edin. Komut sat\u0131r\u0131ndan yaln\u0131zca ba\u015fl\u0131klar\u0131 g\u00f6rmek i\u00e7in curl -I<\/code> kullanabilirsiniz.<\/p>\n

    curl -I https:\/\/example.com\/eski-sayfa<\/code><\/pre>\n
    Yan\u0131tta HTTP\/2 404<\/code> veya HTTP\/1.1 404 Not Found<\/code> g\u00f6r\u00fcyorsan\u0131z sunucu iste\u011fi alm\u0131\u015f ve 404 d\u00f6nd\u00fcrm\u00fc\u015ft\u00fcr. -I<\/code> g\u00f6vdeyi indirmeden ba\u015fl\u0131klar\u0131 istedi\u011fi i\u00e7in ilk kontrol\u00fc h\u0131zland\u0131r\u0131r; fakat baz\u0131 uygulamalar HEAD isteklerini GET ile farkl\u0131 i\u015fleyebilir. \u015e\u00fcpheli durumda normal GET iste\u011fini de deneyin:<\/p>\n
    curl -sS -D - -o \/dev\/null https:\/\/example.com\/eski-sayfa<\/code><\/pre>\n
    Bu komut yan\u0131t ba\u015fl\u0131klar\u0131n\u0131 ekrana yaz\u0131p g\u00f6vdeyi \/dev\/null<\/code>‘a g\u00f6nderir. \u00d6zellikle Location<\/code> ba\u015fl\u0131\u011f\u0131nda beklenmedik bir y\u00f6nlendirme olup olmad\u0131\u011f\u0131na bakar\u0131m.<\/p>\n
    2. Y\u00f6nlendirmeleri g\u00f6r\u00fcn\u00fcr hale getirin<\/h3>\n
    Bir URL do\u011frudan 404 d\u00f6nmeyebilir; \u00f6nce birka\u00e7 y\u00f6nlendirmeden ge\u00e7ip son ad\u0131mda 404’e ula\u015fabilir. curl<\/code>‘\u00fcn -L<\/code> se\u00e7ene\u011fi y\u00f6nlendirmeleri takip eder, -w<\/code> ise son durum kodunu yazd\u0131r\u0131r.<\/p>\n
    curl -sS -L -o \/dev\/null -w 'final=%{http_code} url=%{url_effective}n' https:\/\/example.com\/eski-sayfa<\/code><\/pre>\n
    Burada \u00f6nemli olan yaln\u0131zca son kod de\u011fildir. Ara yan\u0131tlar\u0131 da g\u00f6rmek istiyorsan\u0131z -D -<\/code> se\u00e7ene\u011fiyle her yan\u0131t\u0131n ba\u015fl\u0131klar\u0131n\u0131 inceleyin. 301 veya 302 zinciri gereksiz uzuyorsa sorun 404’ten \u00f6nce ba\u015flam\u0131\u015f olabilir.<\/p>\n
    3. DNS ve hedef IP’yi do\u011frulay\u0131n<\/h3>\n
    Alan ad\u0131n\u0131n hangi IP’ye \u00e7\u00f6z\u00fcld\u00fc\u011f\u00fcn\u00fc kontrol edin:<\/p>\n
    dig +short example.com A\ndig +short example.com AAAA<\/code><\/pre>\n
    \u00c7\u0131kt\u0131da beklemedi\u011finiz bir IPv6 adresi varsa baz\u0131 istemciler sitenin farkl\u0131 sunucusuna gidebilir. A ve AAAA kay\u0131tlar\u0131n\u0131n ayn\u0131 hizmete ait olup olmad\u0131\u011f\u0131n\u0131 do\u011frulay\u0131n. DNS taraf\u0131n\u0131 kontrol ederken 502 Bad Gateway Hatas\u0131 Nedir ve Nas\u0131l \u00c7\u00f6z\u00fcl\u00fcr?<\/a> ba\u015fl\u0131kl\u0131 i\u00e7erikteki upstream yakla\u015f\u0131m\u0131 da ak\u0131lda tutulabilir; 502 ve 404 farkl\u0131 katmanlar\u0131 i\u015faret eder, fakat ikisi de reverse proxy yap\u0131land\u0131rmas\u0131yla ili\u015fkili olabilir.<\/p>\n
    4. Sunucu loglar\u0131n\u0131 iste\u011fin saatiyle e\u015fle\u015ftirin<\/h3>\n
    Nginx i\u00e7in yayg\u0131n log yollar\u0131 \/var\/log\/nginx\/access.log<\/code> ve \/var\/log\/nginx\/error.log<\/code> dosyalar\u0131d\u0131r. Da\u011f\u0131t\u0131m ve hosting paneline g\u00f6re yollar de\u011fi\u015febilir. \u0130ste\u011fi tekrar g\u00f6nderip ayn\u0131 anda logu izlemek, tahmin y\u00fcr\u00fctmekten daha g\u00fcvenilirdir:<\/p>\n
    sudo tail -f \/var\/log\/nginx\/access.log \/var\/log\/nginx\/error.log<\/code><\/pre>\n
    Access log sat\u0131r\u0131nda URL, durum kodu ve istemci IP’si; error log’da ise dosya yolu veya upstream bilgisi g\u00f6r\u00fclebilir. Access log’da 404 olup error log’da hi\u00e7bir kay\u0131t olmamas\u0131 her zaman sorun de\u011fildir. Nginx, beklenen bir dosya bulunamad\u0131\u011f\u0131nda yaln\u0131zca eri\u015fim kayd\u0131 b\u0131rakabilir.<\/p>\n
    Benzer bir kontrol\u00fc Apache’de \/var\/log\/apache2\/access.log<\/code> ve \/var\/log\/apache2\/error.log<\/code> \u00fczerinden yapabilirsiniz. PHP-FPM loglar\u0131 ise uygulaman\u0131n iste\u011fi al\u0131p almad\u0131\u011f\u0131n\u0131 ay\u0131rmaya yard\u0131mc\u0131 olur.<\/p>\n
    5. Dosya ve izinleri kontrol edin<\/h3>\n
    Statik bir dosya i\u00e7in \u00f6nce ger\u00e7ekten var olup olmad\u0131\u011f\u0131na bak\u0131n:<\/p>\n
    sudo stat \/var\/www\/example\/public\/assets\/app.css\nsudo namei -l \/var\/www\/example\/public\/assets\/app.css<\/code><\/pre>\n
    stat<\/code> dosyan\u0131n mevcut oldu\u011funu, namei -l<\/code> ise yolun her bile\u015fenindeki izinleri g\u00f6sterir. Dosya mevcut oldu\u011fu halde web sunucusu okuyam\u0131yorsa \u00e7o\u011fu zaman 403 g\u00f6r\u00fcrs\u00fcn\u00fcz; fakat uygulama veya \u00f6zel hata yap\u0131land\u0131rmas\u0131 bunu 404 olarak maskeleyebilir. Sorunu anlamadan chmod -R 777<\/code> \u00e7al\u0131\u015ft\u0131rmay\u0131n. Bu yakla\u015f\u0131m izin modelini d\u00fczeltmez, yaln\u0131zca yeni g\u00fcvenlik sorunlar\u0131 a\u00e7ar.<\/p>\n
    Sunucu taraf\u0131nda 404 nas\u0131l d\u00fczeltilir?<\/h2>\n
    Do\u011fru \u00e7\u00f6z\u00fcm, iste\u011fin hangi katmanda kayboldu\u011funa g\u00f6re de\u011fi\u015fir. A\u015fa\u011f\u0131daki s\u0131ra, dosya tabanl\u0131 bir site ile framework veya CMS kullanan uygulamalarda ortak bir ba\u015flang\u0131\u00e7 noktas\u0131d\u0131r.<\/p>\n
    Dosya ger\u00e7ekten ta\u015f\u0131nd\u0131ysa<\/h3>\n
    Eski URL’nin yeni ve e\u015fde\u011fer bir kar\u015f\u0131l\u0131\u011f\u0131 varsa 301 y\u00f6nlendirmesi ekleyin. Nginx’te basit bir \u00f6rnek \u015f\u00f6yledir:<\/p>\n
    location = \/eski-sayfa {\n    return 301 \/yeni-sayfa;\n}<\/code><\/pre>\n
    De\u011fi\u015fiklikten sonra yap\u0131land\u0131rmay\u0131 \u00f6nce test edin:<\/p>\n
    sudo nginx -t\nsudo systemctl reload nginx<\/code><\/pre>\n
    nginx -t<\/code> ba\u015far\u0131l\u0131 d\u00f6nmeden reload \u00e7al\u0131\u015ft\u0131rmay\u0131n. Bir m\u00fc\u015fterinin staging sand\u0131\u011f\u0131 sanal host’ta Nginx de\u011fi\u015fikli\u011fi yaparken \u00f6nce hostname’i kontrol etmeyi al\u0131\u015fkanl\u0131k haline getirmemi\u015ftim; production prompt’undaki k\u0131rm\u0131z\u0131 renk o g\u00fcn yerle\u015fti. \u015eimdi yap\u0131land\u0131rma de\u011fi\u015fikli\u011finden \u00f6nce hedefi, sonra dosyay\u0131 kontrol ediyorum.<\/p>\n
    Uygulama rotas\u0131 kay\u0131psa<\/h3>\n
    Framework kullanan uygulamalarda route tan\u0131m\u0131n\u0131 ve \u00fcretim ortam\u0131ndaki base URL ayarlar\u0131n\u0131 kontrol edin. \u0130stek \/api\/v1\/users<\/code> yerine yanl\u0131\u015fl\u0131kla \/api\/users<\/code> adresine gidiyorsa web sunucusunda dosya aramak vakit kaybettirir. Uygulama loglar\u0131nda route e\u015fle\u015fmesi veya controller bulunamad\u0131\u011f\u0131na dair kay\u0131t aray\u0131n.<\/p>\n
    Uygulama yeni s\u00fcr\u00fcme ge\u00e7irildikten sonra route cache’i veya derlenmi\u015f varl\u0131klar eski kalabilir. Kulland\u0131\u011f\u0131n\u0131z framework’\u00fcn resmi temizleme komutunu, \u00f6nce yedek ve bak\u0131m plan\u0131yla uygulay\u0131n. Genel bir rm -rf<\/code> komutunu kopyalay\u0131p \u00e7al\u0131\u015ft\u0131rmak, 404 sorununu daha b\u00fcy\u00fck bir veri kayb\u0131na \u00e7evirebilir.<\/p>\n
    WordPress’te kal\u0131c\u0131 ba\u011flant\u0131lar\u0131 kontrol edin<\/h3>\n
    WordPress y\u00f6netim panelinde kal\u0131c\u0131 ba\u011flant\u0131 ayarlar\u0131n\u0131 a\u00e7\u0131p de\u011fi\u015fiklik yapmadan yeniden kaydetmek baz\u0131 kurulumlarda rewrite kurallar\u0131n\u0131 yeniler. Bu i\u015flemden \u00f6nce Nginx kullan\u0131l\u0131yorsa uygulaman\u0131n ilgili location<\/code> blo\u011funu da inceleyin; Apache i\u00e7inse .htaccess<\/code> dosyas\u0131n\u0131n varl\u0131\u011f\u0131 ve okunabilirli\u011fi \u00f6nemlidir.<\/p>\n
    Birden fazla site ayn\u0131 VPS’te bar\u0131n\u0131yorsa yanl\u0131\u015f server block se\u00e7imi de g\u00f6zden ka\u00e7abilir. Alan ad\u0131 iste\u011fi beklenmeyen virtual host’a d\u00fc\u015f\u00fcyorsa do\u011fru dosya yerinde olsa bile ziyaret\u00e7i varsay\u0131lan sitenin 404 sayfas\u0131n\u0131 g\u00f6r\u00fcr.<\/p>\n
    404 sayfas\u0131 nas\u0131l haz\u0131rlanmal\u0131?<\/h2>\n
    Her 404’\u00fc d\u00fczeltmek m\u00fcmk\u00fcn de\u011fildir. Silinmi\u015f bir i\u00e7erik i\u00e7in kullan\u0131c\u0131ya bo\u015f beyaz sayfa g\u00f6stermek yerine, ne oldu\u011funu a\u00e7\u0131klayan ve bir sonraki ad\u0131m\u0131 sunan \u00f6zel bir 404 sayfas\u0131 haz\u0131rlamak daha sa\u011fl\u0131kl\u0131d\u0131r.<\/p>\n