.htaccess

A standard WordPress block sits between the lines # BEGIN WordPress and # END WordPress and sends any URL that is not a real file or directory to /index.php. WordPress rewrites that block when you save Settings > Permalinks, so anything you place inside the markers can be overwritten.

Check it from a shell with cat .htaccess in the site root, and test syntax by reloading a page: a bad directive returns a 500 Internal Server Error and the Apache error log names the file and line. Nginx ignores .htaccess entirely, so on that stack the same rules live in the server block.

A client's site returns 500 on every URL right after a developer pasted a 301 redirect from a blog post into .htaccess. The Apache error log reads .htaccess: Invalid command 'RewriteRul', perhaps misspelled. One missing letter took the whole site down.

Fixing the directive restores the pages. The developer then moves custom redirects above the # BEGIN WordPress marker, so a later permalink save no longer wipes them.

.htaccess is a file the web server reads, while rewrite rules are a WordPress-level list stored in the database and applied by PHP. On Apache the file hands requests to WordPress and WordPress's rules decide which query to run. If WordPress can write .htaccess, saving permalinks fixes the file, but regenerating rules in the database does not by itself fix a missing file.

Editing inside the WordPress markers. Assuming nginx will pick the file up. Leaving the file read-only so permalink saves silently fail. Stacking redirects until a loop forms. Uploading a CMS-unrelated .htaccess from another host that references modules the server does not have, such as mod_expires.

Keep a copy of the working file before any edit. Put your own rules above the WordPress block and test with curl -I against two or three URLs. If you move hosts to nginx, translate the rules rather than carrying the file over.