What is a URL slug?

Which part of an address is the slug?

The slug is the readable identifying segment within a page’s URL path, commonly the final segment. It is separate from the domain, query parameters, and fragment. Understanding those boundaries helps you change the intended part of an address without confusing a page move with tracking or an in-page navigation link.

• In the illustrative address https://example.com/services/wood-fence-repair/, the domain is example.com.

  The path is /services/wood-fence-repair/. The page’s identifying slug is wood-fence-repair. The parent segment places it within a service section, while the final segment names this particular page.

• The term is common in content management systems rather than a separate search feature.

  A CMS may call its editable field a slug, permalink, handle, or URL key. Its label does not tell you whether it controls only the final segment or the entire path. Inspect the published address before editing.

• A query string begins after a question mark.

  A campaign parameter attached to the repair URL does not ordinarily change its slug. A fragment begins after a hash mark and often identifies a location within the page. Neither should be mistaken for a new page’s readable path segment.

• These distinctions matter during troubleshooting.

  If a tracked link fails, changing the slug may leave the underlying parameter handling problem untouched. If an in-page anchor stops working, the relevant element identifier may have changed even though the page address itself remains valid.

• Google’s URL structure guidance recommends logical, descriptive addresses.

  It also explains technical requirements and common causes of excessive URL variants. A readable slug supports that broader structure; it cannot independently establish crawlability or compensate for a broken route.

• A 301 redirect can preserve access from an old slug after a permanent move, but it should point to the relevant final resource and be verified directly.

How should you choose a slug for a new service page?

Choose wording that identifies the page’s durable purpose and fits the site’s existing path conventions. Prefer a service or subject customers recognize over an internal code. Include distinctions that matter to the page’s role, while leaving temporary claims and unnecessary variations out of the address so routine updates do not require moves.

Should slugs use hyphens, lowercase, or special characters?

Use a consistent convention that your CMS and server handle reliably, with hyphens separating readable words where appropriate. Lowercase paths can simplify consistency, while special characters require correct encoding. These are implementation and readability decisions, not reasons to relocate every established page that follows a different but functioning convention.

• Google recommends hyphens rather than underscores for word separation.

  For a new path, chimney-repair is a straightforward choice. Joining words into chimneyrepair can reduce readability, while underscores follow a different convention. Neither observation alone establishes that changing an existing address will produce a worthwhile search improvement.

• Path case deserves technical verification.

  Google treats differently cased paths as distinct URLs. A server may treat them as equivalent, redirect one to another, or serve different resources. Establish the intended behavior rather than assuming /Repairs/ and /repairs/ necessarily resolve to the same page.

• If the server treats case variants as the same content, consistent linking helps avoid ambiguity.

  For a new website, a lowercase convention is easy to maintain. For an existing site, investigate published routes and incoming references before imposing a global conversion that changes many addresses.

• Languages can use non-ASCII words in paths.

  Google recommends audience-language wording and explains percent encoding in links where needed. A readable local-language slug can therefore be appropriate. Do not assume every language must be transliterated into English merely because an encoded address looks longer when copied.

• Reserved characters have technical roles.

  A slash separates path segments; a question mark introduces parameters. Inserting such characters into an editor field can produce an unexpected path or require encoding. Use the CMS’s supported handling and verify the published URL rather than improvising replacement rules.

• Copy an encoded address carefully when testing redirects or link destinations.

  A displayed browser address and its underlying encoded form can look different. Diagnose whether they identify the same resource before declaring them duplicates or changing the slug to solve a cosmetic display difference.

What makes an existing slug worth changing?

Change an established address when its current identity creates a substantive problem that a move can resolve. Examples include an inaccurate service name, a genuine consolidation, or a required architecture change. Weigh that benefit against the links and integrations using the old address rather than treating shorter wording as an automatic improvement.

• A page titled “Wood fence repair” can retain a stable slug while its copy, photographs, or prices change.

  None of those routine updates necessarily changes the page’s purpose. Keeping the address avoids requiring customers, staff, and other websites to revise references that still point to a valid service.

• A different decision arises when the company stops repairing wood fences and replaces the offer with general fence inspections.

  The original slug may no longer describe the page. First decide whether the old service page should be retained, retired, or moved to a genuinely equivalent destination.

• A misspelling can justify review, but the severity matters.

  A confusing or misleading spelling is different from a harmless historical abbreviation. Check usage before moving. An address printed on vehicles or distributed in customer emails can remain useful long after its internal naming seems inelegant.

• An existing year in a slug requires contextual judgment.

  An annual report may properly retain its year. A continuously updated evergreen guide may have an unnecessarily dated address. Do not remove dates from historical content merely to make it appear current or avoid clarifying which period it covers.

• Avoid changing a slug whenever keyword research finds a new variant.

  The page can explain related terminology without taking a new address. A series of cosmetic moves adds operational work and makes change analysis harder without establishing that the address was the limiting factor.

• Record the actual reason for a move in concrete terms.

  “The page now covers commercial inspections instead of residential repairs” explains a scope change. “More SEO friendly” leaves the intended benefit unclear and does not help decide whether the disruption is justified.

How do you prepare before moving a published page?

Inventory the old address’s important references, identify the exact destination, and verify that the replacement fulfills the same relevant need. Check internal links, search-facing signals, and business integrations before changing the slug. This preparation turns a field edit into a deliberate move rather than leaving customers to discover broken references afterward.

• Find links in navigation, body copy, footer components, related cards, and reusable calls to action.

  A CMS may update some references automatically while leaving manually entered URLs unchanged. Search for the complete old path and test representative rendered pages instead of relying on a single global setting.

• Review external references you can reasonably identify.

  Directory listings, partner pages, customer messages, social profiles, and downloadable brochures may use the old URL. You cannot necessarily update every reference, which makes a working redirect especially important when the move is legitimate.

• Include operational integrations.

  Booking forms, confirmation messages, CRM templates, advertising destinations, and QR codes can depend on the address. A redirect may preserve access, but query parameters or fragment behavior may still affect the intended workflow. Test the actual links those systems produce.

• Identify whether the current page has a self-referencing canonical tag and whether the new page will reference the intended new URL.

  A canonical signal addresses preferred indexing among equivalents; it does not send a customer who opens an old address to the new page.

• Review the XML sitemap and any localized references.

  The preferred destination should be represented consistently after a move. An old sitemap entry combined with new internal links and an old canonical creates avoidable disagreement about which address represents the page.

• Keep the old-to-new mapping precise.

  A move from one service page to its equivalent replacement differs from redirecting all retired pages to the homepage. Customers looking for a specific repair explanation need a relevant destination, not a generic page selected only because it still exists.

Which redirect is appropriate for a slug change?

A genuine permanent relocation normally calls for a permanent redirect to the corresponding new URL. A temporary relocation needs different treatment. Choose the response according to the move’s intended duration and meaning, then verify the server’s actual behavior rather than assuming a CMS permalink edit created the correct redirect automatically.

• Google’s redirect documentation distinguishes permanent and temporary redirects.

  A 301 redirect is a common permanent server-side option. The broader documentation also covers other supported mechanisms, so identify the method your platform actually implements.

• If the service has permanently moved from /fence-fixing/ to /wood-fence-repair/, a direct redirect can preserve access through the old address.

  The destination should return the intended live content. A redirect to another unavailable URL simply moves the failure further along the request path.

• Do not use a temporary response merely because the implementation is easy.

  If the old URL will not return, temporary semantics misrepresent the move. Conversely, a brief maintenance diversion or test may not justify telling search engines that the original page has permanently relocated.

• Check for a redirect chain when the page has moved before.

  An earlier address may still point to the previous slug, which now points to the latest one. Where practical, update mappings so known historical addresses reach the final relevant destination directly.

• Test for loops and unexpected external destinations.

  A rule can accidentally redirect the new URL back to the old one, particularly when trailing slash or case normalization interacts with a slug mapping. Inspect the complete response sequence rather than viewing only the final browser screenshot.

How do you verify a completed slug move?

Test both addresses, inspect the response sequence, and review the published destination’s links and indexing signals. The old URL should behave as planned, and the new one should deliver the correct content. Separate immediate implementation checks from later search observations, which depend on crawling and processing beyond the editor’s save action.

How do duplicate address variants affect the slug decision?

Determine whether different addresses represent separate content or alternative routes to the same page before changing the readable segment. Case, trailing slash, and parameters can create variants without changing the underlying service. The appropriate fix may involve consistent linking or canonicalization rather than renaming the slug and creating another address to manage.

• Compare the actual responses for slash and non-slash versions.

  Some platforms redirect consistently; others serve both. Choose the site’s intended convention and make its links agree. Do not assume a trailing slash is inherently better for search simply because a competing website uses one.

• Tracking parameters can expose the same content under several URLs.

  A campaign-tagged service page is not automatically a distinct landing page. Check whether the parameter changes content, attribution, or behavior before deciding how the site should handle it.

• The concept of canonicalization helps distinguish equivalent variants from meaningful pages.

  Google can choose a representative URL among duplicates. Clear signals support the intended choice, but a canonical declaration should not point an unrelated service page at another page merely to reduce a report’s URL count.

• If two paths serve the same content accidentally, inspect routing and publication history.

  A duplicated CMS object can create an unexpected second page. An alias may be intentional. The remedy depends on which situation exists, not on whether one slug contains a more attractive keyword.

• Do not block the old URL from crawling as a substitute for a redirect that Google needs to observe.

  Likewise, an indexing directive does not transport customers to a replacement. Crawl controls, indexing instructions, canonical signals, and redirects have different functions and must be selected accordingly.

• When there are many variants, a technical SEO review can trace the rules creating them.

  Solve the generation or routing issue rather than repeatedly polishing final segments while the site continues producing unnecessary addresses.

How can a URL structure create too many pages?

Dynamic features can generate large numbers of addresses through filter combinations, date navigation, sorting, or session identifiers. The problem concerns how URLs are produced and linked, not merely whether individual slugs are readable. Review whether each generated state deserves a crawlable address and prevent unbounded combinations that do not serve a useful purpose.

• A service directory might expose combinations of town, property type, service, and availability.

  Some combinations can serve genuine browsing needs. Others may produce empty or near-identical pages. A descriptive path for each combination does not automatically make all of them valuable search destinations.

• An appointment calendar can link indefinitely to future dates.

  Google highlights unlimited calendars as a potential source of excessive URLs. Constrain the feature according to the useful booking window and investigate its crawl behavior rather than treating every date path as a normal content page.

• Session identifiers in addresses can multiply references to the same content and complicate sharing.

  A customer copying such a URL may carry state that another visitor does not need. Review the platform’s session design with a developer before attempting a blanket rewrite.

• Sorting and filtering parameters require contextual treatment.

  Removing them indiscriminately can break a user’s chosen view. Leaving every combination crawlable can create unnecessary work for crawlers. Decide which views have a durable purpose and handle the remaining states according to their function.

• Google’s URL guidance discusses crawl controls for problematic dynamic spaces.

  Those decisions should follow an inventory of the generated URLs and their purpose. A robots.txt rule can limit crawling, but it does not make a weak page informative or replace an indexing strategy for already known content.

• Check broken relative links as well.

  A component can append a path relative to the wrong location, creating increasingly nested invalid addresses. Fix the link construction and nonexistent-page response. Renaming the valid destination’s slug does not correct the faulty reference generator.

How would a fence company handle a real service consolidation?

Start by identifying which old pages still have a meaningful equivalent in the consolidated offer. Preserve useful information at the replacement destination, map appropriate moves, and retire genuinely discontinued content honestly. The invented example below illustrates these decisions without claiming measured search gains or assuming that every merger warrants the same redirect pattern.

• Imagine a contractor with separate pages for wooden fence repairs and gate hinge repairs.

  It decides to offer one broader timber repair service. Customers can still book both tasks, and the new page explains their distinct scope. Consolidation may therefore give both old pages a relevant replacement.

• Before choosing /timber-repairs/, check whether that phrase accurately describes the business’s offer.

  If the company repairs only garden fencing and gates, a wider phrase could imply structural carpentry. A slug such as fence-gate-repair may communicate the scope more precisely.

• Move useful details from both pages into clearly labeled sections.

  Explain which defects can be repaired and when replacement may be necessary. The new address should not become an excuse to erase information customers need about access, materials, or assessment.

• Map the old addresses to the new page if their needs are genuinely fulfilled there.

  Update links in service navigation and relevant advice articles. Test old customer-facing URLs, including any booking links previously distributed by staff.

• Suppose a third page described metal gate automation, which the company has discontinued.

  The timber repair page is not equivalent merely because both mention gates. Decide how to explain the discontinued service or return an appropriate unavailable-page response instead of creating a misleading redirect.

What common slug questions need a contextual answer?

Judge a proposed convention against readability, durability, and the site’s actual implementation. There is no single slug pattern that resolves every content or technical problem. For an established page, the question is also whether a change brings enough practical value to justify maintaining the old address and updating its important references.

• Must a slug contain the exact target keyword?

  A natural service name often includes relevant vocabulary. An exact phrase can fit, but awkward repetitions add little. The cited documentation favors descriptive addresses; it does not establish a universal ranking benefit from exact phrase placement.

• Should small connecting words be removed?

  Remove them if the result stays understandable and fits the site’s convention. Retain them when they distinguish meaning. A shorter address is not automatically clearer, especially when removing words makes two different services look identical.

• Should a location appear in every service slug?

  Use location distinctions when they represent the page’s actual role. A general service page can explain its coverage without listing every town in the address. Separate location pages need useful local content, not only different town names.

• Can a heading change without changing the slug?

  Yes. The heading can become clearer while the durable page identity remains the same. If the subject changes substantially, review whether this is still the same page. Treat wording refinement and replacement of an offer as different decisions.

• Can you keep an old redirect indefinitely?

  Its usefulness depends on continuing references and platform support. Do not remove a working mapping solely because the editor considers the move finished. Older links, printed materials, and customer messages can continue using the previous address.

• Does a clean slug prove a page can be indexed?

  No. The route must work, the content must be accessible, and relevant indexing conditions still apply. Treat the slug as one part of the page’s identity rather than a replacement for inspecting its technical and editorial quality.

Primary documentation

Google Search Central: URL structure best practices, SEO Starter Guide, and Redirects and Google Search. Accessed 8 October 2026.