What is a dynamic URL?
A dynamic URL is one that carries a query string: a question mark followed by parameters such as ?id=482&sort=price&page=3. The server reads those values and assembles the page on the fly from a database, which is how shops, search results, filters and session-based pages have worked for decades. A static URL, by contrast, looks like a fixed path (/films/bag-man/) whether or not a database sits behind it.
The word dynamic describes the URL, not the page. Most pages today are built dynamically; the question is whether the address exposes the machinery. A well-run site uses both kinds, clean paths for the things people look for and parameters for the ways they look at them, and the craft is in deciding which is which.
Why it matters
Why a dynamic URL matters
Search engines can crawl and index dynamic URLs, and have been able to for years, so the problem is not capability. The problem is multiplication. Every combination of parameters is a new address, and a product grid with five filters and three sort orders can generate thousands of URLs for one set of products. Each is a potential duplicate, each spends crawl budget, and each can collect links and shares that should have gone to one page.
There is a human cost too. A clean URL tells a person what they will find and gets copied into emails and decks; a string of parameters does not, and gets truncated or mistyped. For brands that care how everything looks, including the address bar, that is reason enough on its own.
In practice
How a dynamic URL works in practice
- 01
Give primary content a clean address. Products, articles, films, services: each gets a readable static path, with parameters rewritten by the server so the database still does the work but the public URL hides it. Keep parameters for what they are good at, which is state that should not be its own page: sorting, filtering, pagination, tracking.
- 02
Then manage the parameters you keep. Put a canonical tag on every variant pointing at the clean page, so links to the filtered view credit the product. Use a consistent parameter order and lowercase keys so the same state does not produce two addresses. Block crawl-trap parameters (infinite calendars, session IDs) in robots.txt, and keep them out of the sitemap and internal links. Tracking parameters on inbound links are harmless as long as the canonical tag is in place, and Search Console's Page indexing report will show you whether Google has agreed with your choices.
Watch out
What people get wrong about dynamic URLs
Believing Google cannot index them. It can, and the advice to avoid them entirely is twenty years out of date. The real risks are duplication and crawl waste, both of which are handled by canonicals and parameter discipline, not by banning the question mark. The opposite mistake is rewriting every parameter into a path, which turns a filtered view into /shoes/black/size-10/under-200/ and creates exactly the same explosion of indexable pages, now with nicer names. Clean URLs for things, parameters for states.
