You may have noticed that WordPress by default creates and uses “Search Engine Optimized or Friendly” URLs. The raw URLs, which refer to the file on disk followed up by a train of grotesque-looking keywords and equals-signs and ampersands and question marks, are hidden from view. For WordPress, the magic comes from what is popularly known as URL rewriting. By sketching out simple or complex yet powerful rules to define what and how to rewrite, you can force the web server to completely transform URLs into clean, beautiful, search engine friendly forms.

Apache, a web server that can commonly be found to be the choice for deployment of WordPress, delegates the entire responsibility of URL rewriting to a module named mod_rewrite. URL rewriting rules can be defined globally, or on a per directory basis, which are interpreted and acted upon by mod_rewrite. In order for rules to be interpreted on a per directory basis, for which these are defined in a special configuration file that can exist within any directory, the AllowOverride setting must be enabled within Apache globally. If it isn’t, rules defined per directory will quietly be ignored.

In order for WordPress to weave its magic, both mod_rewrite and the AllowOverride setting must be enabled within Apache. This realisation dawned upon me when Asim mentioned that the two need to be enabled on Apache. On a server on which I had recently deployed WordPress for a friend, I noticed that created pages beyond the home page would give a mysterious 404. The two, as Asim gratuitously told me, were not enabled on Apache on that server which in turn were causing the 404 to pop out. I am surprised I did not stumble upon these two gotchas documented within WordPress—I may have overlooked, I am not sure.

I hope this serves to help a lost soul fumbling along a similar path.