Dynamic URL: Why It Is Usually a Marketing-Team Phrase, and the Three Engineering Questions It Actually Contains

Q: Should I use query parameters or path segments for filters?

Path segments (/products/red-widget) for the canonical content, query parameters (/products?color=red) for state that does not change the canonical content. The path is what the SERP shows. The query parameters are the state.

Q: How do I tell Google which URL is the canonical one?

Add a tag in the of every page. Google will consolidate duplicates to the canonical URL. For URLs that have moved, use a 301 redirect from the old URL to the canonical.

Q: When should I use a 301 redirect?

When a URL has permanently moved. A product renamed, a blog post moved between categories, a page deleted. The 301 preserves the SEO value of the old URL and tells Google the new URL is the canonical one.

“Dynamic URL” is a phrase that means three different things in three different contexts: a URL with query parameters (/products?id=42), a URL the application routes by pattern (/products/42), or a URL the server generates per request from a database. The SEO advice for one is wrong for the other two. The engineering advice for one is wrong for the other two. The reason this question still comes up in 2026 is that the phrase is overloaded, and most blog posts on the topic pick one definition and pretend the other two do not exist.

This post is the unblocker. The first half is the three definitions, with examples and the engineering context for each. The second half is the SEO reality, which is less about “dynamic vs static” and more about “what does this URL look like to Google, and what does the user expect when they click it.”

The interesting thing about dynamic URLs is that the original SEO concern (Google cannot crawl ?id=42 as well as /products/42) was solved in 2009. Modern Google crawls both forms with equal facility. The remaining SEO questions are about canonicalization, user experience, and click-through rate — not crawlability. Most blog posts on this topic are still answering the 2009 question, which is no longer the question.

The direct answer
The three definitions of “dynamic URL”
Definition 1: query-parameter URLs
Definition 2: pattern-routed URLs
Definition 3: server-generated URLs
The SEO reality in 2026
When the URL structure actually matters
The canonical pattern
The opinion this post is built on
FAQ

The direct answer

If you are asking “is my dynamic URL bad for SEO?” — probably not, but it depends on which kind of dynamic URL it is. The rule of thumb:

Query parameters (?id=42) — fine, but use canonical tags and avoid infinite parameter spaces.
Pattern routes (/products/42) — preferred, the modern default, no SEO concern.
Server-generated URLs — fine, treat as static once they are stable, use canonical tags to deduplicate.

The deeper answer is below. The short version: modern Google crawls all three, the SEO question is canonicalization not crawlability, and the user-experience question (does the URL look trustworthy in the SERP) matters more than the crawlability question.

The three definitions of “dynamic URL”

The phrase “dynamic URL” is used to mean three different things, often in the same conversation. The first step to answering the question is to figure out which definition the asker means.

Definition 1: a URL with query parameters. /products?id=42, /search?q=hello&page=2, /articles?category=python&sort=date. The page is the same; the parameters modify what the server returns. The server’s view of the URL is “the path is /products, and here are the query parameters.”

Definition 2: a pattern-routed URL. /products/42, /search/hello/page-2, /articles/category/python/sort/date. The page changes because the path changes. The server’s view of the URL is “the path is /products/42, and I will route based on the path.” Most modern web frameworks (Next.js, Django, Rails, Express) use pattern routing by default.

Definition 3: a server-generated URL. A URL the server composes at runtime from data in a database, a CMS, a config file, or a third-party API. The URL is not in a file on disk; the server returns a different HTML page for each URL. The URL might look static (/blog/my-post-title) or dynamic (/blog?id=42) or somewhere in between (/blog/2024/03/my-post-title).

The three definitions overlap. A pattern-routed URL is often also a server-generated URL. A query-parameter URL is a server-generated URL when the server is doing database lookups based on the parameter. The distinctions are about how the URL is addressed by the application, not whether the content is dynamic.

Definition 1: query-parameter URLs

The classic dynamic URL. The path is the same; the parameters change.

/products?id=42
/products?id=43
/products?id=44

The server sees /products, reads id from the query string, and looks up the product in the database. Three different URLs, three different pages.

The SEO history: in the early 2000s, search engines struggled with query-parameter URLs. Crawlers would index every combination, and ?id=1 through ?id=999999 would all appear in the index as duplicate content. The solution was to use robots.txt to block parameter crawls, or to use URL rewriting to convert /products?id=42 into /products/42.

In 2026, the crawlability concern is largely solved. Google crawls query-parameter URLs as easily as path-routed URLs, and it has heuristics to identify parameter-based duplicates. The remaining concerns are:

Canonicalization. A page that can be reached at ?id=42&page=1 and ?id=42&page=2&sort=date is two URLs for the same content, and Google will consolidate them via the canonical link tag, but only if the tag is correct.
Click-through rate. A URL that looks like /products?id=42&utm_source=email is a longer, less trustworthy-looking URL in the search results. Users are less likely to click it than /products/red-widget.
Parameter explosions. A search page that generates ?q=hello&page=1, ?q=hello&sort=date&page=1, and so on creates a combinatorial space of URLs. Each combination is a different URL, each can be indexed, each can appear in the SERP.

The fix for the canonicalization and CTR concerns is usually to use pattern routing for the canonical URL and reserve query parameters for state that does not change the canonical content. The fix for the parameter-explosion concern is robots.txt plus canonical tags plus parameter handling in Google Search Console.

Definition 2: pattern-routed URLs

The modern default. The path encodes the resource; the server routes by pattern.

/products/42
/products/43
/products/red-widget

The server sees /products/42, routes to a handler that reads the product ID from the path, and looks up the product. The URL is the canonical URL. There is no parameter space. There is no combinatorial explosion.

Pattern routing is the right answer for content that has a stable identity: products, articles, user profiles, blog posts, documentation pages. The URL is part of the user experience — a user can read /blog/2024/03/my-post and know what the page is about, and a user can edit the URL in the address bar to navigate to a sibling page.

The SEO win: pattern-routed URLs are the URLs Google displays in the SERP. The CTR win: pattern-routed URLs are the URLs users trust. The engineering win: pattern routing is the default in every modern framework, and the routing is type-checked at compile time.

The trap: making the pattern too clever. /blog/{year}/{month}/{slug}/{id} is fine. /blog/{author}/{year}/{month}/{slug}/{id}/{comment_id} is a routing nightmare. The pattern should be as deep as the content’s natural identity, no deeper.

Definition 3: server-generated URLs

The URL is composed at runtime from data. The pattern might be static or dynamic, but the data behind the URL changes.

/blog/2024/03/my-post-title
/blog/2024/03/another-post
/blog/2024/04/yet-another

The server reads the post slug from the URL, looks it up in the database, and returns the page. The URLs look static, but they are generated by the server on every request. Modern web frameworks call this “dynamic routing” — a static-looking URL that the server handles dynamically.

The SEO win: the URL looks static in the SERP, which is what users trust. The crawlability is the same as a static URL. The canonical URL is the URL itself. There is no parameter space.

The engineering win: the framework handles the routing. The developer writes a route handler that matches a pattern, and the framework dispatches. The URL is the resource identity; the handler is the behavior.

The trap: URLs that change over time. A blog post that was at /blog/2024/03/my-post and is moved to /blog/2024/04/my-post is a different URL, and the old URL needs a 301 redirect. A product that was at /products/42 and is renamed to /products/red-widget is a different URL, and the old URL needs a 301 redirect. The redirect story is the hard part of server-generated URLs, and the part most teams skip.

The SEO reality in 2026

The “dynamic URLs are bad for SEO” advice is from 2009. Modern Google crawls dynamic URLs as well as static URLs. The remaining SEO concerns are:

Canonicalization. Use <link rel="canonical"> to tell Google which URL is the primary. This handles ?id=42 and ?id=42&page=1 and ?utm_source=email and any other variant.
Duplicate content. A page that is reachable at multiple URLs needs a canonical. A page that is filtered, sorted, or paginated needs to either canonicalize to the unfiltered version or use rel="prev" and rel="next" for paginated series.
CTR. A URL that looks trustworthy in the SERP gets more clicks. /products/red-widget outperforms /products?id=42 in click-through rate, even when both rank in the same position. The URL is part of the product.
Crawl budget. For very large sites (millions of URLs), the parameter space matters. For most sites, it does not.

The Google Search Console has a URL Parameters tool that lets the site owner tell Google which parameters to ignore. It is the right tool for the rare cases where the parameter space is a real problem. For most sites, canonical tags are enough.

The trap to avoid: chasing the “static URL” goal for its own sake. A /products/red-widget URL is not inherently better than a /products?id=42 URL. The first is more user-trustworthy in the SERP, but the second is just as crawlable. The engineering effort to convert from one to the other is only worth it if the conversion is part of a broader product improvement.

When the URL structure actually matters

URL structure matters when:

The URL is shown to the user in the SERP, and a longer or parameter-laden URL reduces CTR.
The URL is shared on social media, and a clean URL is more shareable.
The URL is part of the navigation pattern, and the user is expected to edit the URL in the address bar.
The URL is part of the analytics story, and a clean URL makes the analytics readable.
The URL is part of the canonical story, and a clean URL simplifies the canonical tag.

URL structure does not matter when:

The URL is only used internally (API endpoints, admin URLs).
The URL is only seen by the application (a redirect target).
The URL is the result of a server-side composition that the user never sees.

For the cases where it matters, pattern routing is the right answer. For the cases where it does not, query parameters are fine. The mistake is to apply one rule to all cases.

The canonical pattern

For a site that wants to be both dynamic and SEO-friendly:

Use pattern routing for content with a stable identity: products, articles, profiles.
Use query parameters for state that does not change the canonical content: sort, filter, page.
Use <link rel="canonical"> on every page to point at the canonical URL.
Use 301 redirects for URLs that have moved.
Use robots.txt to block crawlers from infinite parameter spaces (search results, filter combinations).

The pattern in code (Next.js example):

// app/products/[slug]/page.tsx
export default async function ProductPage({ params }: { params: { slug: string } }) {
  const product = await getProduct(params.slug);
  return (
    <>
      <link rel="canonical" href={`https://example.com/products/${params.slug}`} />
      {/* ... */}
    </>
  );
}

The framework handles the routing. The developer handles the canonical tag. The SEO is correct by default. The same pattern works in Django, Rails, Express, and any framework that supports file-based or decorator-based routing.

For a deeper look at how the framework and the deploy platform together handle the URL-to-content mapping, the RunxBuild platform handles the routing, the canonical headers, and the SSL termination in one place. The application focuses on the content.

The opinion this post is built on

The reason “dynamic URL” is still a frequently-asked question is that the phrase is overloaded. Three different things, one label, three different answers. The blog posts that answer the 2009 question (Google cannot crawl ?id=42) are not answering the 2026 question. The blog posts that answer the 2026 question (use canonical tags, use pattern routing for the canonical URL) are not answering the 2009 question. The result is a sea of advice that is right for someone, wrong for the reader.

The right answer for the modern web: pattern routing for content with a stable identity, query parameters for state, canonical tags for everything. The framework handles the routing. The developer handles the canonical tags. The deploy platform handles the SSL and the redirects. Each layer does one job, and the URL is the contract between them.

The rest is folklore. The 2009-era advice about static URLs and Google crawlability is folklore in 2026. The advice about avoiding query parameters is folklore when the parameters do not change the canonical content. The advice that “dynamic URLs are bad” is folklore when the modern Google crawler handles both forms equally. The right answer is to use the right tool for the job, not to chase a static URL for its own sake.

A framework that handles pattern routing by default, a deploy platform that handles canonical headers and 301 redirects, and a content model that distinguishes “the resource” from “the state” — that is the stack where the URL question is a solved problem. Anything less is a story the team tells about a site that ranks lower than it should.

How this fits the rest of the stack

The URL question is also a hosting question — the pattern routing layer has to scale with the traffic, the canonical headers have to be set on every response, and the 301 redirects have to be served at the edge. None of that is free at scale, and the team should know what the URL layer costs before the traffic gets heavy. The RunxBuild hosting calculator is the right place to model that — pick the bandwidth, the request rate, the storage, and the edge function count, and the calculator shows what the URL layer costs at the team’s actual usage.

Useful related references:

FAQ

What is a dynamic URL?

A URL whose content is determined at request time, as opposed to a static URL that serves a fixed file. In practice, the term is used to mean three different things: a URL with query parameters, a URL the application routes by pattern, or a URL the server generates per request from a database. The SEO and engineering answers depend on which kind.

Are dynamic URLs bad for SEO in 2026?

No. Modern Google crawls dynamic URLs as easily as static URLs. The remaining SEO concerns are canonicalization (use <link rel="canonical">), click-through rate (cleaner URLs look more trustworthy in the SERP), and parameter space management (avoid infinite filter combinations). The 2009-era advice about avoiding dynamic URLs is folklore.

Should I use query parameters or path segments for filters?

Path segments (/products/red-widget) for the canonical content, query parameters (/products?color=red) for state that does not change the canonical content. The path is what the SERP shows. The query parameters are the state.

How do I tell Google which URL is the canonical one?

Add a <link rel="canonical" href="https://example.com/canonical-url"> tag in the <head> of every page. Google will consolidate the duplicates to the canonical URL. For URLs that have moved, use a 301 redirect from the old URL to the canonical.

Do dynamic URLs affect page speed?

Not directly. The URL is just a string; the speed depends on what the server does with the URL. A server that does a database lookup on every request is slower than a server that serves a static file, but the URL itself is not the bottleneck. The right answer is to optimize the server, not to flatten the URL.

When should I use a 301 redirect?

When a URL has permanently moved. A product renamed from /products/42 to /products/red-widget should 301 the old URL to the new one. A blog post moved from one category to another should 301 the old URL to the new one. A page that has been deleted should 301 to the most relevant existing page, or 410 if no replacement exists. The 301 preserves the SEO value of the old URL.