Test rewrite rules before they take a site down

Because .htaccess runs in a per-directory context, and Apache strips the directory prefix — including the leading slash — before matching. A request for /blog/post is tested against "blog/post". So ^/blog can never match in a root .htaccess, while ^blog matches fine. This one detail accounts for more broken rewrite rules than everything else combined, largely because the same rule does work when placed in a server or virtual-host config, which is where most copied examples come from.

Not quite, and the difference matters. L ends the current pass through the ruleset. In a .htaccess file, if the URL was rewritten, Apache then starts the whole ruleset again from the top with the new URL — which is exactly how infinite loops happen despite an L flag on every rule. The END flag, added in Apache 2.4, is the one that genuinely stops all processing. If you have a loop you cannot explain, this is usually why.

Because it has no access to your server's filesystem, and nothing that runs in a browser could. Conditions like RewriteCond %{REQUEST_FILENAME} !-f depend entirely on that. Rather than guess, the tool lets you state the assumption and marks every step that depends on it. Toggle "path is a real file" and watch the classic front-controller rule flip — that toggle is the whole behaviour of a pretty-URL setup in one checkbox.

A rewrite is internal: Apache serves different content and the visitor's address bar never changes. A redirect sends a 301 or 302 back to the browser, which then requests the new URL, and the address bar updates. For SEO they are entirely different — a rewrite is invisible to search engines, while a redirect transfers signals to the destination. The R flag, or an absolute URL in the substitution, is what turns a rewrite into a redirect.

Yes. Conditions default to AND; the [OR] flag chains a condition with the next one so either can satisfy that link. The trace shows each condition evaluated individually with the value it was tested against, so a chain that behaves unexpectedly is visible rather than inferred. Note that conditions are only evaluated after the RewriteRule pattern matches — a common misreading, since they are written above the rule.

Close, not identical. This simulates the mod_rewrite directives you paste in isolation. A real server also has server-level and virtual-host configuration, other modules, inherited rules from parent directories, and its actual filesystem — any of which can change the outcome. Treat this as a way to reason about your logic and catch the common mistakes before deploying, then verify on a staging environment.

If you can put the rules in your server or virtual-host configuration instead, do — Apache re-reads .htaccess on every request to every directory in the path, which costs real performance. On shared hosting you usually have no choice, and that is what .htaccess exists for. Either way, redirect chains are worth auditing: every extra hop costs crawl budget and a little authority, and long chains accumulate quietly over years of site migrations.