Slug Collisions: What Happens When Two Pages Generate the Same URL, and How CMSs Handle It

Two articles titled "How to Make Sourdough Bread" published a year apart on the same site will, by default, generate the identical slug — and what your CMS does next varies from silently overwriting the old URL to appending a number nobody chose

The previous articles on this site covered why slugs are a long-term URL commitment and how to handle non-Latin scripts in international slugs. This article addresses a narrower but very common practical issue: slug collisions — what happens when two pieces of content would generate the same slug, and how different content management systems handle this differently, with consequences ranging from "minor cosmetic difference" to "accidentally broke an existing URL."

The collision: same title, same slug, by default

Most slug-generation logic follows the same basic process (covered in the original text-to-slug article): lowercase, replace spaces with hyphens, strip special characters. Two different pieces of content with the same (or very similar) title will, by this logic alone, produce the identical slug.

This isn't a rare edge case — it happens routinely:

• A blog publishes an annual "Year in Review" post — "2023 Year in Review," "2024 Year in Review" — titles that differ (different years) but, if the slug-generation strips numbers or the year happens to not be part of the title pattern used, could collide
• A recipe site has multiple "Chocolate Chip Cookies" recipes (a classic version, a vegan version, a gluten-free version) — if only the base recipe name informs the slug, all three would generate chocolate-chip-cookies
• A product catalog has products with identical names but different variants/SKUs (e.g., a t-shirt available in multiple colors, each as a separate product page, but all sharing the same product name)

Approach 1: append a numeric suffix

The most common approach: when a slug collision is detected (the generated slug already exists for another piece of content), append a number — chocolate-chip-cookies, then chocolate-chip-cookies-2, chocolate-chip-cookies-3, etc., for subsequent collisions.

This is WordPress's default behavior, and is widely used across other CMSs — it's simple, automatic, and guarantees uniqueness (each collision increments the suffix).

The downside: the suffix is uninformative. chocolate-chip-cookies-2 doesn't tell a user (or a search engine) anything about what's different about this version compared to chocolate-chip-cookies — unlike a slug that incorporates meaningful differentiating information (chocolate-chip-cookies-vegan, chocolate-chip-cookies-gluten-free) — the numeric suffix is purely a uniqueness mechanism, carrying no semantic information.

Practical implication: content creators should, ideally, proactively choose differentiated slugs (manually specifying chocolate-chip-cookies-vegan rather than letting auto-generation produce chocolate-chip-cookies-2) — the automatic numeric-suffix fallback exists specifically for cases where this proactive differentiation didn't happen (whether through oversight, or because the collision wasn't anticipated at the time of creation — e.g., the second "Chocolate Chip Cookies" post was written without the author realizing an earlier post already used that exact title).

Approach 2: incorporate a date or ID into the slug structure

Some platforms/site structures build date or ID information into the URL path itself — e.g., /blog/2024/01/chocolate-chip-cookies (incorporating year/month) or /recipes/12345/chocolate-chip-cookies (incorporating a numeric content ID).

This prevents most collisions structurally — two different posts titled "Chocolate Chip Cookies," published in different months, would naturally have different URLs (/blog/2023/06/chocolate-chip-cookies vs /blog/2024/01/chocolate-chip-cookies) without needing a numeric slug suffix at all — the date (or ID) portion of the URL provides the uniqueness, leaving the slug portion free to be the clean, descriptive text without needing disambiguation.

Trade-off: URLs incorporating dates can create the "this content looks dated" perception discussed in previous articles (a /2019/ in the URL of content that's been kept up to date might create an impression of staleness, even if the content itself is current) — URLs incorporating opaque IDs (/12345/) avoid the "looks dated" issue but add a non-human-readable element to the URL (though combined with a descriptive slug — /12345/chocolate-chip-cookies — the ID portion is largely invisible to users, who naturally focus on the readable slug portion, while the ID provides the uniqueness guarantee "behind the scenes."

Approach 3: reject/require manual resolution

Some systems, rather than automatically generating a fallback (numeric suffix or otherwise), flag the collision and require the content author to manually choose a different slug before the content can be saved/published.

This forces the proactive differentiation mentioned earlier — rather than allowing chocolate-chip-cookies-2 to be created "by default," the author is prompted, at creation time, to choose something more descriptive (chocolate-chip-cookies-vegan) — shifting the "choose a meaningful differentiator" decision to the point where the author has the most context (they know why this new piece of content differs from the existing one with the same title — information that an automatic numeric-suffix system doesn't have access to).

Trade-off: this adds friction to the content-creation process — every collision requires manual intervention, rather than "just publish and the system handles it" — for high-volume content creation (many posts per day, across many authors), this friction can be a meaningful operational cost, which is part of why the automatic-suffix approach (Approach 1) remains the most common default across general-purpose CMSs, despite its "uninformative suffix" downside.

What happens when you manually try to set a slug that's already taken?

If an author, manually editing a slug field, enters a value that's already in use by other content — most systems will either:

• Silently append a suffix to the manually-entered value too (the same Approach 1 fallback, applied even to manual entries — my-custom-slug attempted, but my-custom-slug already exists → saved as my-custom-slug-2)
• Reject the save / show an error, requiring the author to choose a different value before proceeding (Approach 3, applied specifically to the manual-entry case)

Checking which behavior your specific CMS implements (by attempting to create content with a deliberately-duplicate slug, in a test/non-production context, and observing what happens) is worthwhile if you're relying on slugs being exactly what you specify — some systems' "silent suffix" behavior for manual entries specifically can be surprising if you expected an error/rejection instead.

Changing an existing slug: collision with the old slug's redirect

A related scenario: if you change a piece of content's slug (from old-slug to new-slug), and later create new content that would naturally generate old-slug as its slug — does the new content "collide" with the redirect that (hopefully) exists from old-slug to the original content's new location?

This depends on how redirects are implemented:

• If the redirect is a database record (e.g., "old-slug → redirect to content ID X") that's checked before slug-generation for new content — the system might recognize old-slug as "already in use" (by the redirect record) and apply the same collision-handling (numeric suffix, etc.) to the new content's slug — avoiding a conflict between "old-slug should redirect to the original content's new location" and "old-slug is now also the slug of this different, new piece of content"
• If redirects are not tracked this comprehensively — a new piece of content could, in principle, end up with the same slug as a previous redirect source — creating ambiguity about which destination old-slug should now represent (the redirect's original target, or the new content that happens to share that slug?) — how this ambiguity is resolved is entirely implementation-dependent, and represents a genuinely tricky edge case in URL/redirect management that's worth being aware of if your site has a history of slug changes and redirects.

How to use the Text to Slug tool on sadiqbd.com

1. Generate slugs for new content — the core function, applying standard slug-generation rules
2. For content likely to have title-collisions (recurring series, multiple variants of similar items): proactively incorporate a differentiator into the slug (year, variant name) rather than relying on automatic numeric suffixes — generate the slug including this differentiator directly
3. Before finalizing: check the slug against your site's existing URLs/redirects (if you have access to this list) — to catch potential collisions, including against redirect sources (old slugs that now redirect elsewhere), before publishing

Frequently Asked Questions

Is chocolate-chip-cookies-2 bad for SEO compared to chocolate-chip-cookies-vegan? The numeric suffix itself isn't directly penalized — but a descriptive slug (-vegan, -gluten-free) provides additional, relevant keyword context in the URL, which some SEO guidance suggests can be a minor positive signal (URLs that describe their content are generally considered good practice, as covered in the original text-to-slug article) — compared to a numeric suffix, which provides no such descriptive value. The difference is generally considered minor rather than significant — but given that choosing a descriptive slug costs nothing extra (compared to letting an automatic numeric suffix apply), it's a low-effort improvement where applicable.

Is the Text to Slug tool free? Yes — completely free, no sign-up required.

Try the Text to Slug tool free at sadiqbd.com — generate clean, URL-friendly slugs from any text instantly.