So my rewriterule is like

RewriteRule ^test$ index.php [L]

I tested it on https://htaccess.madewithlove.com?share=b0a9904b-1ec4-49cd-917c-36426ff6150a it works fine.

enter image description here

I also tested it on live Joomla sites and on a HTML sites, it all work fine.

However, when I try to test this on a Wordpress site, I am always getting a 404 page. By default, wordpress site's .htaccess file is like

# BEGIN WordPress
# The directives (lines) between "BEGIN WordPress" and "END WordPress" are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

I add my rewrite rule above to the first line, but when I open mysite.com/test I will get a 404 error.

To test, I create a 1.php file and modify my rule to

RewriteRule ^test$ 1.php [L]

This time, when I open mysite.com/test it successfully executes 1.php. So the catch here is index.php.

What I don't understand is if I open mysite.com/index.php it will load mysite.com without problem. And I believe

RewriteRule ^test$ index.php [L]

in essential is telling the server when user request mysite.com/test show him mysite.com/index.php, then why in actuality I am getting a 404 page(not a blank 404, but the 404 page handled by wordpress's theme) when trying to open mysite.com/test?

P.S. I've also tried removing the default wordpress rules, but still getting the same result.

1 Answer 1


I am getting a 404 page(not a blank 404, but the 404 page handled by wordpress's theme)

Your rule is successfully rewriting the request to index.php, however...

index.php is the WordPress front-controller. Code in this file looks at the requested URL (eg. /test in your example) and decides how to handle it. If /test is not a valid route defined in WordPress then WordPress (not Apache) generates a 404. This isn't reporting that the file index.php does not exist, but that the URL /test does not exist inside of WordPress, ie. there is no route defined for this URL in WordPress.

I add my rewrite rule above to the first line

UPDATE: Incidentally, unless /test maps to an existing directory (or file) then the WordPress code block already does exactly what you are doing with the rewrite... it rewrites the request to /index.php with the last rule.

So, the directive you are adding is in fact entirely superfluous anyway.

RewriteRule ^test$ 1.php [L]

If the code in 1.php responds with a 404 (for whatever reason), then this would also result in a 404.

  • So although Apache rewrites the URL it still passes the original request (in my case /test) to Wordpress? And how then do I rewrite /test to /?
    – Wen Shenk
    Feb 4, 2022 at 14:28
  • 1
    @WenShenk Yes, the original request is available to PHP (ie. WordPress) in the $_SERVER['REQUEST_URI'] superglobal - and WP uses this to route the URL through the CMS. Incidentally, your rewrite is really superfluous (assuming /test does not map to a file or directory) since the WordPress code block already rewrites the request to /index.php in the last rule.
    – MrWhite
    Feb 4, 2022 at 15:08
  • 2
    @WenShenk "how then do I rewrite /test to /?" - Do you mean "redirect"? It doesn't make sense to internally rewrite /test to /. / itself is not a valid end-point. It would require further rewriting to handle the request (eg. to serve the DirectoryIndex). However, unless you are implementing an additional app outside of WordPress then all URLs/routing need to be configured in WordPress itself - not .htaccess. AFAIK, WordPress itself does not provide a mechanism to "rewrite" requests outside of WP itself, unlike some other CMS, since it always looks that the URL the user requested.
    – MrWhite
    Feb 4, 2022 at 15:12
  • 1
    @WenShenk I just tried the /shop URL on your site and I'm 302 redirected to google.com, so unless you've changed something, you're probably seeing a cached response/redirect (as mentioned above).
    – MrWhite
    Feb 4, 2022 at 19:08
  • 1
    Thank you so much. Wasn't aware this could be cached.
    – Wen Shenk
    Feb 4, 2022 at 19:23

This site is temporarily in read-only mode and not accepting new answers.

Not the answer you're looking for? Browse other questions tagged .