Τα άρθρα του WordPress επιστρέφουν 404 αλλά η αρχική σελίδα δουλεύει
Αν η αρχική σελίδα φορτώνει κανονικά αλλά κάθε μεμονωμένο άρθρο και σελίδα επιστρέφει 404, οι κανόνες URL rewrite στους οποίους βασίζεται το WordPress λείπουν ή είναι χαλασμένοι στο
Δημοσιεύτηκε
Αν η αρχική σελίδα φορτώνει κανονικά αλλά κάθε μεμονωμένο άρθρο και σελίδα επιστρέφει 404, οι κανόνες URL rewrite στους οποίους βασίζεται το WordPress λείπουν ή είναι χαλασμένοι στο αρχείο .htaccess. Η πιο γρήγορη λύση: πηγαίνετε στις Ρυθμίσεις → Μόνιμοι σύνδεσμοι στο wp-admin και πατήστε Αποθήκευση αλλαγών χωρίς να αλλάξετε τίποτα. Αυτό αναγκάζει το WordPress να αναδημιουργήσει το rewrite block. Αν τα 404 επιμένουν, το .htaccess σας δεν είναι εγγράψιμο από τον web server, ο Apache είναι ρυθμισμένος να το αγνοεί, ή βρίσκεστε σε Nginx (που δεν χρησιμοποιεί καθόλου .htaccess).
Γιατί δουλεύει η αρχική αλλά όχι τα άρθρα
Η αρχική σελίδα σας δουλεύει επειδή ένα αίτημα προς το / εξυπηρετείται απευθείας από το index.php στη ρίζα του document root. Δεν απαιτείται κανένα rewrite.
Ένα αίτημα προς το /2026/my-post/ είναι διαφορετικό. Αυτή η διαδρομή δεν είναι πραγματικός φάκελος στον δίσκο. Για να την απαντήσει το WordPress, ο Apache πρέπει να δρομολογήσει εσωτερικά το αίτημα στο index.php, και μετά το WordPress διαβάζει το REQUEST_URI, το αντιστοιχίζει με τους κανόνες rewrite που είναι αποθηκευμένοι στην επιλογή rewrite_rules της βάσης δεδομένων, επιλύει τις query vars (WP::parse_request()), και φορτώνει το σωστό άρθρο.
Η μεταβίβαση από τον Apache στο index.php είναι το σημείο που χαλάει. Εξαρτάται εξ ολοκλήρου από αυτό το block στο .htaccess:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
Οι δύο γραμμές RewriteCond λένε: αν η ζητούμενη διαδρομή δεν είναι πραγματικό αρχείο (!-f) και δεν είναι πραγματικός φάκελος (!-d), στείλε την στο index.php. Αφαιρέστε αυτό το block και ο Apache ψάχνει για έναν κυριολεκτικό φάκελο /2026/my-post/, δεν τον βρίσκει, και επιστρέφει το δικό του 404 — προτού καν δει το αίτημα το WordPress.
Γιατί το WordPress αντικαθιστά το .htaccess όταν αποθηκεύετε τους μόνιμους συνδέσμους
Αυτό το κομμάτι το παραλείπουν οι περισσότεροι οδηγοί. Όταν πατάτε Αποθήκευση στην οθόνη Μόνιμοι σύνδεσμοι, το WordPress καλεί την flush_rewrite_rules(). Σε Apache με εγγράψιμο .htaccess, αυτό ενεργοποιεί την save_mod_rewrite_rules(), η οποία αναδημιουργεί το παραπάνω block μέσω της WP_Rewrite::mod_rewrite_rules() και το ξαναγράφει χρησιμοποιώντας την insert_with_markers().
Η insert_with_markers() αγγίζει μόνο τις γραμμές ανάμεσα στο # BEGIN WordPress και το # END WordPress. Οτιδήποτε εκτός αυτών των markers μένει ανέγγιχτο. Οτιδήποτε μέσα απορρίπτεται και ξαναγράφεται. Οι νεότερες εκδόσεις του WordPress εμφανίζουν μάλιστα την προειδοποίηση απευθείας μέσα στο αρχείο:
Any changes to the directives between these markers will be overwritten.
Έτσι, το «το WordPress αντικαθιστά το .htaccess μου» είναι αληθές αλλά περιορισμένο: ξαναγράφει μόνο το δικό του σημειωμένο block, και μόνο όταν το αρχείο είναι εγγράψιμο. Αν το αρχείο δεν είναι εγγράψιμο, η αποθήκευση δεν κάνει σιωπηλά τίποτα στον δίσκο. Το WordPress εμφανίζει μια κίτρινη ειδοποίηση στην οθόνη Μόνιμοι σύνδεσμοι που σας λέει να επικολλήσετε τους κανόνες χειροκίνητα, και αν χάσετε αυτή την ειδοποίηση, το rewrite block σας παραμένει απόν και κάθε άρθρο συνεχίζει να επιστρέφει 404.
Πώς να το διορθώσετε, με τη σειρά
1. Ξανα-αποθηκεύστε τους μόνιμους συνδέσμους σας. Ρυθμίσεις → Μόνιμοι σύνδεσμοι → Αποθήκευση αλλαγών. Δεν χρειάζονται αλλαγές. Αυτό ξανατρέχει το flush και ξαναγράφει το block. Λύνει την πλειονότητα των περιπτώσεων, συμπεριλαμβανομένων των παρωχημένων κανόνων μετά από μια μεταφορά.
2. Ελέγξτε ότι το .htaccess υπάρχει και είναι εγγράψιμο. Βρίσκεται στον ίδιο φάκελο με το wp-config.php. Είναι κρυφό αρχείο (dotfile), οπότε ενεργοποιήστε την «εμφάνιση κρυφών αρχείων» στον FTP client σας ή χρησιμοποιήστε:
ls -la /path/to/wordpress/.htaccess
Αν λείπει, δημιουργήστε το και επικολλήστε το σωστό block. Αν η εγκατάστασή σας βρίσκεται σε υποφάκελο, το RewriteBase και ο τελικός στόχος του rewrite πρέπει να ταιριάζουν με αυτή τη διαδρομή — το να το κάνετε λάθος είναι ο πιο συνηθισμένος λόγος που ένα χειροκίνητα επικολλημένο block συνεχίζει να δίνει 404. Η γεννήτρια .htaccess μας δημιουργεί το ακριβές block για τη διαδρομή εγκατάστασής σας ώστε να μη χρειάζεται να μαντεύετε.
3. Επιβεβαιώστε ότι ο Apache επιτρέπεται να διαβάσει το .htaccess. Αν ο virtual host έχει AllowOverride None, ο Apache αγνοεί εντελώς το αρχείο ανεξάρτητα από το περιεχόμενό του. Χρειάζεστε AllowOverride All (ή τουλάχιστον FileInfo) στον φάκελο του WordPress. Αυτό βρίσκεται στη ρύθμιση του server, όχι στο .htaccess, οπότε απαιτεί πρόσβαση στον server:
<Directory /var/www/html>
AllowOverride All
</Directory>
4. Επιβεβαιώστε ότι το mod_rewrite είναι ενεργοποιημένο. Σε Debian/Ubuntu:
sudo a2enmod rewrite
sudo systemctl restart apache2
5. Στον Nginx, δεν υπάρχει .htaccess. Τα rewrites πηγαίνουν στο server block:
location / {
try_files $uri $uri/ /index.php?$args;
}
Γρήγορη διάγνωση: ποιανού είναι το 404;
Κοιτάξτε τη σελίδα 404. Αν είναι μια σελίδα σφάλματος του Apache ή του host χωρίς styling, ο Apache δεν έφτασε ποτέ στο WordPress — αυτό είναι πρόβλημα .htaccess ή ρύθμισης server (βήματα 2–4). Αν είναι το διαμορφωμένο 404 του θέματός σας, το WordPress λαμβάνει το αίτημα αλλά δεν μπορεί να το αντιστοιχίσει — οι κανόνες στη βάση δεδομένων είναι παρωχημένοι, και η ξανα-αποθήκευση των μόνιμων συνδέσμων (βήμα 1) είναι η λύση. Αυτή η μία διάκριση γλιτώνει στους περισσότερους μία ώρα μαντεψιάς.
Τι να μην κάνετε
Μην απενεργοποιήσετε πρώτα όλα τα πρόσθετά σας. Ένα καθαρό σύμπτωμα «τα άρθρα δίνουν 404, η αρχική δουλεύει» είναι πρόβλημα rewrite, όχι σύγκρουση προσθέτων. Η απενεργοποίηση προσθέτων είναι η αντανακλαστική απάντηση στα φόρουμ και σχεδόν ποτέ δεν αγγίζει αυτό.
Μην κάνετε chmod 777 στο .htaccess σας. Το WordPress χρειάζεται το αρχείο εγγράψιμο από τον χρήστη του web server, που δεν είναι το ίδιο με το world-writable. Το 644 με τον σωστό ιδιοκτήτη είναι μια χαρά και ασφαλές· το 777 είναι μια τρύπα ασφαλείας που ούτως ή άλλως δεν θα διορθώσει τη δρομολόγηση.
Μην επικολλάτε προσαρμοσμένους κανόνες rewrite μέσα στους markers # BEGIN WordPress / # END WordPress. Θα σβηστούν την επόμενη φορά που κάποιος θα αποθηκεύσει τους μόνιμους συνδέσμους. Βάλτε τις προσαρμοσμένες οδηγίες πάνω από τη γραμμή # BEGIN WordPress.
Μην επανεγκαταστήσετε το WordPress. Τα αρχεία πυρήνα είναι εντάξει. Πρόκειται για ένα block κειμένου που λείπει, όχι για κατεστραμμένη εγκατάσταση.
Μην ρίχνετε το φταίξιμο στο θέμα σας. Η δρομολόγηση των μόνιμων συνδέσμων είναι πυρήνας του WordPress. Ένα θέμα δεν μπορεί να την προκαλέσει ούτε να τη διορθώσει.
Ακόμα κολλημένοι;
Αν ξανα-αποθηκεύσατε τους μόνιμους συνδέσμους, επιβεβαιώσατε ότι το block υπάρχει και είναι εγγράψιμο, και ορίσατε AllowOverride All, ο εναπομείνας ύποπτος είναι ένα πρόσθετο ασφαλείας ή ένας κανόνας σε επίπεδο host που αναδημιουργεί ή κλειδώνει το .htaccess πίσω από την πλάτη σας. Ελέγξτε τη χρονική σήμανση τροποποίησης του αρχείου αμέσως μετά από μια αποθήκευση μόνιμων συνδέσμων — αν δεν άλλαξε, κάτι μπλοκάρει την εγγραφή. Αναδημιουργήστε ένα καθαρό block με τη γεννήτρια .htaccess, επικολλήστε το, και ξαναδοκιμάστε με hard refresh.