Do clean URLs help SEO?

A little, and mostly through people. Search engines index query-string URLs without trouble, but a short readable path is easier to link to, share and recognise in results. The larger gain is consistency: one address per page, enforced with a 301 from the old form, so links are not split across duplicates.

Where do I put the Nginx rewrite rule?

Inside the server block for the site, in the location / section. If that location already exists, add only the rewrite line to it, because Nginx refuses to load a configuration with two location / blocks in one server. Run nginx -t to check the syntax, then reload with systemctl reload nginx. Nginx does not read .htaccess files.

What does the QSA flag do in a RewriteRule?

QSA, query string append, merges the query string of the incoming request with the one in the rule's target. Without it, a target that has its own query string replaces the original, so tracking or paging parameters on the clean URL are lost. With [L,QSA], /product/123?page=2 reaches the script as id=123&page=2.

Can I use words instead of numeric IDs in the path?

Yes. Give the example URL a text value, such as ?slug=blue-suede-shoes, and the generator uses ([^/]+) for that segment, which accepts letters, digits and hyphens. Your script then has to look the record up by slug, so slugs must be unique. A numeric example produces ([0-9]+), which rejects anything but digits.

Will my old URLs stop working after I add the rules?

No. The script is still there, so product.php?id=123 keeps answering. With the 301 option on, Apache redirects requests for the old form to the clean path as long as the parameters appear in the expected order. Other variations are served directly as before.

Clean URLs

URL Rewrite Generator

Paste one example of a query-string URL, such as https://example.com/product.php?id=123&category=shoes, and the generator works out a clean path for it (/product/123/shoes) and writes the rewrite rules that make that path load the original script. You get three versions side by side: Apache mod_rewrite for .htaccess, an Nginx location block and an IIS web.config rule. It is for developers who want readable URLs without changing the application behind them.

Dynamic URL (example)

Path prefix

Parameter order in the clean URL

Loading URL Rewrite Generator...

Querying live edge resolvers and network infrastructure...

How to use the URL Rewrite Generator

Paste an example of your current dynamic URL into the Dynamic URL box. It needs at least one query parameter.
Set the Path prefix (the default is product) and click the swap arrows between the parameter pills to change the order of the values in the clean path.
Leave the 301 checkbox ticked if Apache should send requests for the old query-string URLs to the new paths.
Check the Clean URL preview, then copy the Apache, Nginx or IIS block into your server configuration.

What to look for

Patterns follow your example values

A parameter whose example value is all digits gets the pattern ([0-9]+); anything else gets ([^/]+), which accepts every character except a slash. With id=123 in the example, /product/abc does not match the rule and ends in a 404 instead of reaching your script with a bad ID.

Rewrite and redirect are different

The RewriteRule is internal: the browser keeps showing /product/123/shoes while the server runs product.php?id=123&category=shoes. The optional second rule is an external 301 from the old query-string form to the clean path. Only the Apache output includes that redirect. The Nginx and IIS blocks contain the internal rewrite alone.

Extra query parameters still arrive

The Apache rule carries the QSA flag and the IIS rule sets appendQueryString to true, so /product/123/shoes?utm_source=mail still hands utm_source to the script. Nginx appends the original arguments to a rewritten URI by default, which gives the same result without a flag.

Guide

Turning query-string URLs into clean paths with rewrite rules

How the generator builds the rule

The tool splits your example into a script path and a list of parameters. For https://example.com/product.php?id=123&category=shoes the script is product.php and the parameters are id and category. Each parameter becomes one path segment after the prefix, in the order the pills show, so the clean form is /product/123/shoes and the pattern is ^product/([0-9]+)/([^/]+)/?$. The trailing /? accepts the path with or without a final slash.

The target reuses the captured groups: product.php?id=$1&category=$2. Nothing about your application changes. PHP still reads $_GET['id'], and a script in a subfolder such as shop/item.php keeps its folder in the target. If the example has no query string, the tool stops and says there are no parameters to turn into a path.

What the three outputs contain

The Apache block starts with RewriteEngine On, then RewriteRule ^product/([0-9]+)/([^/]+)/?$ product.php?id=$1&category=$2 [L,QSA]. L stops rule processing at this match. The pattern has no leading slash because Apache strips the directory prefix before matching in .htaccess. In a virtual host file the same rule needs ^/product/ instead.

The Nginx block is a location / containing rewrite ^/product/([0-9]+)/([^/]+)/?$ /product.php?id=$1&category=$2 last. Here the leading slash is required, and last makes Nginx search its locations again with the rewritten URI so the PHP location picks it up. The IIS block is a rule element for the rules section of web.config, with a match on the same pattern and a Rewrite action whose back-references are written {R:1} and {R:2}; each ampersand is escaped as & because web.config is XML.

The 301 from old URLs and why it reads THE_REQUEST

Once clean URLs work, the old query-string addresses still work too, and search engines see two addresses for one page. The optional redirect fixes that. It adds RewriteCond %{THE_REQUEST} \s/product\.php\?id=([^&\s]+)&category=([^&\s]+)\s [NC] followed by RewriteRule ^ /product/%1/%2? [R=301,L]. The %1 and %2 come from the condition, and the question mark at the end of the target drops the old query string.

THE_REQUEST holds the request line exactly as the browser sent it, for example GET /product.php?id=123&category=shoes HTTP/1.1. The internal rewrite never changes it, so the condition is true only for someone who asked for the old form. A test on QUERY_STRING would also match the rewritten request and loop.

The condition is literal about shape. It expects the parameters in the order shown, with nothing after them, so product.php?category=shoes&id=123 or a URL with a third parameter is served as before, without a redirect. For Nginx and IIS you have to write the equivalent redirect yourself.

Why a rewritten page loads without styles

The usual surprise after switching is a page with no CSS or images. The browser resolves relative paths against the URL it sees, so on /product/123/shoes a reference to css/site.css becomes /product/123/css/site.css, which does not exist. Use root-relative paths (/css/site.css) in templates, or set a base element in the head.

A 404 on the clean path usually means the rule is not being read. On Apache, check that mod_rewrite is loaded and that AllowOverride permits FileInfo for the directory. Otherwise .htaccess is ignored. On IIS, a 500.19 configuration error after adding the rule is the standard sign that the URL Rewrite module is not installed.

Parameters arrive empty on Apache when the prefix equals the script name (product and product.php): MultiViews answered first, so add Options -MultiViews.
Values containing a slash never match ([^/]+). Keep slashes out of anything that goes into the path.
The generator does not edit your pages: change internal links to the clean form so visitors skip the redirect.

Limits and neighbouring tools

The rules come from one example and are not tested against your server. Every parameter must be present in every clean URL, in the same order. An optional parameter needs a second rule with fewer segments. Text values are matched loosely, so /product/123/anything reaches the script, which should validate its input and answer unknown items with a real 404 so search engines do not index empty pages.

Everything runs in your browser and the example URL is not sent anywhere. For moving pages, forcing HTTPS or removing www, use .htaccess Redirect Generator. After the switch, run Broken Link Checker on your busiest pages: links that now pass through the 301 show up as redirected.

Knowledge Base & FAQ

URL Rewrite Generator FAQs

Common questions about the url rewrite generator.

A rewrite happens inside the server and the visitor never sees it. A redirect tells the browser to request a different address. Rewriting /product/123 to product.php?id=123 keeps the clean URL in the address bar. Redirecting product.php?id=123 to /product/123 changes it, with a 301 status that search engines treat as a permanent move.

Related Diagnostic Tools

Combine diagnostics for deep-dive network and DNS troubleshooting.

View All Tools

Website OS Checker

Find out which operating system and web server a website runs on.

MD5 Hash Generator

Generate MD5, SHA-1 and SHA-256 hashes of text or files, and verify checksums.

Base64 Encoder / Decoder

Encode and decode Base64 text and files, including URL-safe and data URIs.