What an .htaccess redirect does
On an Apache web server, an .htaccess file can change request handling for a directory without editing the main server configuration. Redirect rules tell browsers and search crawlers that a requested URL should be fetched somewhere else. They are commonly used after changing a page slug, consolidating domains, enforcing HTTPS, or moving an entire section of a site.
The generator produces a focused rule from the URLs and redirect type you select. It helps avoid common mistakes such as an unescaped hostname, a missing scheme, an endless redirect loop, or a rule that discards the remainder of a path. The output is still server configuration, so read it before deployment and test it on a staging host whenever possible.
How to generate and install a rule
- Select the type of move: one URL, a directory, a domain, or an HTTPS/canonical-host rule.
- Enter the source and destination exactly as they should be matched and served.
- Choose a permanent 301 or temporary 302 response.
- Generate the snippet, copy it, and place it in the relevant .htaccess file.
- Request several affected and unaffected URLs, then inspect their status and Location header.
Rules are evaluated in order. Put a narrow page redirect before a broader directory or domain rule when both could match. Existing WordPress, Laravel, or other front-controller rewrites usually need their marked block left intact; custom redirects typically belong before that block so the application does not consume the request first.
Choose the correct status code
301 for an intended permanent move
A 301 tells clients that the old URL has a lasting replacement. Search engines normally transfer signals over time and browsers may cache the destination aggressively. Use it for a renamed page, an established HTTP-to-HTTPS move, or a deliberate domain migration. Confirm the destination before publishing because cached 301 behavior can make a mistaken rule harder to troubleshoot.
302 for a temporary route
A 302 keeps the original URL relevant while sending current traffic elsewhere. It fits short maintenance periods, temporary campaigns, and controlled tests. Do not leave a 302 indefinitely when the move is truly permanent; the response should describe your intent, not merely provide a convenient default.
Concrete redirect use cases
A single-page rule should match only the old path and send it to one complete destination. A directory migration often needs to preserve everything after the directory name, such as moving /docs/install to /help/install. A host or protocol rule should preserve both the path and query string unless you explicitly want to remove them.
Canonicalization deserves special care. If a reverse proxy or CDN already redirects HTTP or the www hostname, duplicating that behavior in Apache can add an extra hop or form a loop when forwarded protocol headers are misunderstood. Decide which layer owns each redirect and keep one authoritative rule.
Testing and safe rollback
Make a copy of the current .htaccess file before editing. A syntax error can return a 500 response for the whole directory, so keep file access available outside the website. Test with a header inspection tool or curl -I, verify the status and exact Location value, and follow the chain until a 200 response is reached. Also test one path that should remain unchanged.
Check both a clean path and one containing encoded characters or a query string. Redirect bugs often appear only when a real URL includes spaces, Unicode, repeated slashes, or tracking parameters that were absent from the initial example.
Privacy
Rule generation is text processing in your browser. The source URL, destination URL, and generated configuration do not need to be uploaded to create the snippet. Your hosting provider will, of course, process the rule after you add it to the server. Avoid pasting credentials or private tokens embedded in URLs, and remove test query parameters before sharing a rule.