Hyphens vs Underscores in URLs: The Standard Your Automation Should Enforce

When automation generates hundreds of pages, small URL decisions stop being cosmetic and start being infrastructure.

One of the smallest is the character between words: a hyphen or an underscore.

Google documents a clear preference, and crawler tooling treats the difference as a detectable issue.

If your publishing pipeline enforces one convention, you avoid a class of problems that is tedious to fix after the fact.

What Google actually recommends

Google's guidance on URL structure is direct: use hyphens instead of underscores to separate words in URLs.

The stated reason is that hyphens help users and search engines better identify concepts in the URL.

The reasoning is historical.

Underscores are commonly used in programming languages to denote concepts that should be kept together, such as a function named format_date.

Google explains that this legacy usage is why it does not recommend underscores as word separators.

Google's URL structure documentation contrasts a summer clothing path written with hyphens versus underscores.

In practical terms, a URL such as example.com/summer-clothing communicates two separate words.

The underscore version risks being read as one token.

Google does not promise any ranking change for individual pages either way.

But the recommendation is unambiguous, and following documented guidance is the cheapest position to hold.

Why this matters more when automation writes the URLs

A human writing ten URLs will notice an inconsistency.

An automated pipeline writing thousands will not.

Slug generation usually derives from a title or keyword field, and whatever separator logic you configure gets applied uniformly.

If that logic emits underscores, every generated page carries the non-recommended convention, and no individual page flags itself as broken.

This is the core argument for treating the hyphen rule as an enforced standard rather than a preference.

The cost of enforcing it at generation time is near zero.

The cost of fixing it later is a migration: every changed URL needs a redirect, internal links need updating, and sitemaps need regenerating.

For a large programmatic section, that is a project.

For a slug function, it is one line.

The same logic applies to adjacent URL conventions that Google documents.

URLs are case sensitive as far as Google's handling is concerned, so /Apple and /apple are distinct URLs.

Google advises converting text to a single case when your server treats them the same, making it easier to confirm URLs reference one page.

The same guidance also recommends using as few URL parameters as possible and trimming parameters that do not change content.

An automation standard can enforce all of these together: lowercase, hyphen-separated, minimal parameters.

How crawlers surface the problem

You do not have to take Google's word alone.

Screaming Frog's SEO Spider includes a dedicated Underscores filter among its URL issues, alongside checks for uppercase, multiple slashes, spaces, and repetitive paths.

The tool's issues documentation lists underscores as a first-class check, so auditors and agencies will flag them.

That matters for operations leaders coordinating across teams and vendors.

If an external audit runs, underscore URLs appear as a listed issue whether or not they cause measurable harm.

Running the same crawl internally before an audit turns a surprise finding into a known backlog item, or better, into nothing at all because the standard prevented it.

Screaming Frog's tab documentation also notes related conventions worth folding into the same standard.

URLs containing spaces are considered unsafe and can break when shared, and hyphens should be used as word separators instead.

Multiple slashes in a path are generally mistakes that can create duplicate URLs. The crawler's user guide frames these as best-practice checks, not ranking guarantees.

What a publishing standard should include

A workable URL convention for automated publishing is short enough to write down and enforce in code.

Based on the documented guidance above, it should cover:

• Hyphens, never underscores, between words in the slug.
• Lowercase letters throughout, since URL handling is case sensitive.
• No spaces, which are unsafe and can break shared links.
• A single slash between path sections, with no doubled slashes.
• As few parameters as possible, and none that fail to change the content.
• Slugs derived from clean title text, stripped of punctuation that would need encoding.

Google also recommends percent-encoding non-ASCII characters in URLs.

If your automation generates pages from topics that include non-Latin scripts or accented characters, decide deliberately whether to encode them or transliterate the slug.

Either can work; an unencoded mix applied inconsistently across a large section is what creates audit noise.

Google's guidance warns about URL structures generating very large numbers of similar URLs, such as additive filters.

It also flags irrelevant parameters like session IDs and referral codes, plus unbounded calendars.

If your automation produces filtered or parameterized views, that warning deserves its own review, separate from the separator question.

Google's documentation suggests robots.txt blocking as one remedy, a decision to make with your technical team rather than a default.

Enforcement points in an automated pipeline

A standard only holds if something enforces it.

In a publishing pipeline there are three practical checkpoints.

First, the slug generator.

This is where the rule belongs.

Derive the slug from the title, replace spaces and underscores with hyphens, lowercase everything, and strip characters that would require encoding.

Test it with awkward inputs: titles with punctuation, mixed-case acronyms, and non-ASCII words.

Second, the review step.

If humans approve generated pages before publishing, the URL should be visible in the approval view.

A reviewer who sees the slug can catch a malformed one in seconds.

If approval is automated, add a validation check that rejects slugs violating the convention rather than silently publishing them.

Third, the audit loop.

Periodic crawls catch what generation misses, including URLs created by other systems, legacy pages, or integrations that build links independently.

Screaming Frog's underscore, uppercase, space, and multiple-slash filters map directly to the standard above, so a crawl can verify compliance without custom scripting.

The issues list shows these checks sit alongside broader URL hygiene checks like parameters and tracking codes.

These checkpoints mirror how disciplined teams treat other automation standards.

The same intake-and-review thinking in an automation intake operating standard applies here: define the rule once, enforce it at entry, and verify downstream.

Changing existing underscore URLs

If a crawl finds existing underscore URLs, resist the urge to bulk-rename immediately.

Every URL change needs a redirect from the old address to the new one, and internal links should point at the final URL rather than chaining through redirects.

For a small number of pages this is routine.

For a large programmatic section, sequence it: prioritize pages that earn traffic or links, redirect the rest in batches, and update internal linking as you go.

Also fix the source before fixing the pages.

If a slug generator or a CMS template produced the underscores, changing the URLs without changing the generator guarantees the problem returns.

This is the same principle behind an automation change operating standard: correct the system, not just the output.

One caution on scope.

Google's hyphen recommendation is about word separators in paths.

It does not establish that every underscore URL underperforms, nor that rewriting them produces a predictable ranking change.

Treat the rewrite as hygiene and consistency work, and verify outcomes with your own crawl and analytics data rather than assuming a specific result.

Where this fits in broader URL decisions

Separators are one small part of URL structure for automated pages.

How much of the topic hierarchy to encode in the path, how to handle pagination, and when to use subdirectories versus parameters are larger questions with tradeoffs of their own.

If you are weighing automated publishing against hiring an agency, SEO automation versus an SEO agency covers who should own standards like this one.

And if the broader question is which parts of marketing to automate at all, the agency versus automation system comparison frames that choice for founders.

The separator rule itself, though, needs no debate.

Google recommends hyphens, crawlers flag underscores, and enforcement costs one line of slug logic.

Write the standard, put it in the generator, and check it in your next crawl.

How Meshline can help. Connect automation, Organic Marketing (demand generation), and customer lifecycle management (Revenue Intelligence).

Bring topic planning, content publishing and performance feedback into the conversation about your workflow. Book a Meshline demo.