What should a page address tell a customer?

Give each page one clear job before naming it. Write down whether it explains a service, presents a product, or answers a question. Choose words that describe that job rather than copying an internal project name.

Here, URL means a page's web address. The path is the part after the domain, and slug means the readable page name within that path. In the hypothetical path /services/window-cleaning/, the slug is window-cleaning.

SEO means helping search engines understand your content and helping people find it. Descriptive URL words give readers information about a page. Google's SEO Starter Guide recommends words that are useful to users.

Write the customer question first

For a hypothetical catering business, separate “What food can I order?” from “Can you cater my wedding?” Propose a menu page and a wedding catering page. Do not force both into a vague address such as /our-solutions/.

Ask the person writing the page to supply its purpose, proposed title, and proposed slug together. Review those three items before publication. This is an editorial workflow recommendation, not a claim that a particular naming formula earns a ranking improvement.

Which URL naming rules should your team use?

Set a short house style: lowercase paths, hyphens between words, and enough detail to identify the page. Put it where editors can find it. Include examples of both an acceptable name and one you would send back for revision.

Use a consistent spelling convention

Google recommends hyphens rather than underscores, treats path letter case as significant, and supports using your audience's language, including transliterated words. See Google's naming guidance.

For a new hypothetical repair page, I would choose /washing-machine-repair/. I would ask for revisions to /Washing_Machine_Repair/. For an existing page, I would first check whether there is a meaningful reason to change its address.

• Choose the main service or product name.
• Keep necessary model names or distinguishing details.
• Remove sales claims such as “amazing” from proposed slugs.
• Leave temporary campaign language out of permanent page names.
• Record unusual spellings so different editors make the same choice.

How much keyword wording belongs in a slug?

Use the phrase that accurately names the page, usually once. For our hypothetical repair business, I would reject /cheap-best-appliance-repair-repair-services/. Ask the writer to name the actual service rather than squeeze every search phrase into one address.

Do not set a character target that forces people to remove useful meaning. My editing test is simple: can someone unfamiliar with the business describe the likely page from its address? If not, discuss the wording before shortening it further.

What do sensible URL choices look like?

Use these hypothetical examples when briefing an editor or developer. The proposed paths are starting points for new pages, not instructions to rename every matching address on an established site.

Choose folders deliberately

Sketch the main groups on paper before adding folders. For a small consultancy, I would begin with services and articles. For a retailer, I would discuss categories and products separately with whoever manages the catalogue.

Do not assume the shortest proposal is automatically the best. Ask what each folder means and who will maintain it. If the team cannot explain a proposed level, leave it out of the draft structure until there is a clear reason for it.

Pair the address review with a review of links between pages. The practical next step is to choose where customers should go after reading each page; use the internal linking guide to plan those connections.

How should an online store handle products and filters?

Review product identity before polishing product names. Pick an item, visit it through different categories, and copy each resulting address. Then compare what those addresses actually show.

Different addresses returning the same content can cause repeated crawling. Addresses with continually changing values can also make useful content harder to discover. Google's ecommerce URL guide explains both problems.

Separate shopping choices from page naming

For a hypothetical homeware shop, list colour, size, sorting, and category selections. Beside each one, write what changes on screen. Ask the catalogue owner which selections customers need to save or share.

A query parameter is a choice written after a question mark in an address. Google recommends the familiar key-and-value format, using = and separating additional parameters with &. Parameter formatting guidance.

Do not delete parameters simply because they look technical. Give the developer a list of the choices they represent. Ask which are necessary, which repeat the same content, and which belong in links used across the site.

Check what the hash sign is doing

A fragment is the part after #. Google does not use fragments to distinguish indexed product content, so do not rely on #blue and #green alone to represent separately discoverable products. Google's fragment example.

In your test, select a colour, copy the address, and open it in a fresh browser window. Record the selected item and the copied address. Give the developer that evidence rather than a general request to “fix product SEO.”

Should you change addresses that already exist?

Require a written reason for each proposed change. “This page has the wrong service name” deserves a different discussion from “I prefer shorter slugs.” I would keep cosmetic changes out of the first review.

Google advises against dropping everything to reorganize a site. For duplicate pages, it suggests redirecting alternative addresses to the preferred version, or using a canonical link when redirecting is not possible. Site organization guidance.

A canonical identifies a preferred address for duplicate or closely matching content. Read the canonical tag guide before approving that part of the implementation. First agree which page should remain the main version.

1. List each existing address and its page purpose.
2. Write the proposed destination beside it.
3. Explain why that destination matches the old content.
4. Assign someone to implement and check the change.
5. Open the old address after implementation and verify the result.

Use the 301 redirect guide when preparing that handover. If the project also involves replacing the domain, expand your checklist with the domain change guide.

What can you check this week?

Choose a manageable sample: your main service pages, one product category, and a few products. Keep a spreadsheet with the current address, page purpose, proposed action, owner, and verification note.

Make the review concrete

• Show an editor your proposed naming rule.
• Ask a colleague to describe pages from their addresses.
• Compare product addresses reached through different routes.
• Record confusing examples without immediately changing them.
• Approve a destination for each address that genuinely needs replacing.

Use Google Search Console's URL Inspection tool when checking how Google sees a page, as recommended in the Starter Guide. Keep its findings separate from your naming preferences.

Include the sitemap, a file listing page addresses, in your handover checklist. Google describes it as one way to provide page URLs. Sitemap explanation. The XML sitemap guide covers that follow-up task.

Finish with a reusable naming policy and a reviewed change list. Your next editor should be able to choose a sensible address without reopening the same debate.