Skip to content
Issue docs

URL longer than 115 characters

Suggestionurl_over_115_charactersIssue 116

What is this issue?

This check measures the length of the page's own address and reports it when the whole URL runs past 115 characters.

The 115-character mark is the figure the established site crawlers all publish. It is not a limit any browser or search engine enforces; it is the point past which a URL stops fitting in the places people actually see it: a search result, a shared link, a spreadsheet column, a log line.

For a URL to pass this check:

  • The complete address -- scheme, host, path and query together -- is 115 characters or fewer.

Example: https://example.com/blog/seo-tips passes at 33 characters. A category page that spells out four levels of nesting, plus a product slug, plus three tracking parameters will not.

Why it matters

A long URL is not penalised by search engines, and that is why this is reported as a suggestion rather than as a defect: it never deducts from the health score. What it costs is everywhere the URL is read rather than followed:

  • Search results: Google truncates the displayed URL, so the part that told the searcher where they were going is the part that disappears.
  • Sharing: long URLs get broken by email clients that wrap lines, and are the ones people replace with a shortener, which hides the destination and loses the brand from the visible link.
  • Maintenance: a URL is usually long because the path repeats information the page already carries. Shortening it almost always simplifies the site structure behind it.
  • Duplicate risk: the longest URLs on a site are usually the parameterised ones, which are also the ones most likely to be reachable at several addresses.

Acting on it does not move the health score at all. What it usually surfaces is the template generating unnecessarily deep paths, which is worth more than the individual URL.

How to fix it

  1. Shorten the path, not the words. Drop path segments that repeat what a later segment already says: /products/category/shoes/mens-shoes/ says "shoes" twice.

  2. Remove dates and IDs nobody reads. A numeric post ID or a /2024/09/03/ prefix adds characters without adding meaning for a reader or a search engine.

  3. Trim the slug. Keep the two or three words that identify the page and drop the stop words. /how-to-choose-the-best-running-shoes-for-beginners becomes /choosing-running-shoes.

  4. Move tracking parameters out of the canonical address. Campaign parameters belong on the links you publish, never in your sitemap or your internal links.

  5. Redirect the old address. Any URL you shorten needs a permanent (301) redirect from the old form, with every internal link and sitemap entry updated to the new one.

  6. Fix it in the template, not page by page. A long URL is almost always a long URL pattern, so the repair belongs wherever that pattern is defined.

Examples

Example 1: A short, readable URL

Scenario: A blog post with a trimmed slug.

Passes because: the whole address is 47 characters.

https://example.com/blog/choosing-running-shoes

Example 2: A path that repeats itself

Scenario: A category template that nests the same word three times and appends a numeric product ID.

Fails because: the address is well over 115 characters.

https://example.com/shop/footwear/shoes/mens-shoes/running-shoes/nike-air-zoom-pegasus-mens-running-shoes-blue/product-id-8871294

Corrected version:

https://example.com/shop/running-shoes/nike-air-zoom-pegasus

Example 3: A short path with a long query string

Scenario: A campaign landing page reached from a newsletter.

Fails because: length is measured on the whole URL, and here the query string is most of it.

https://example.com/p?utm_source=newsletter&utm_medium=email&utm_campaign=autumn-clearance-2026&utm_content=hero-button

Corrected version: keep the campaign parameters on the published link, and make sure the canonical tag, the sitemap entry and every internal link use the clean address.

https://example.com/p

How PixyScan detects this

  1. Takes the address the page was SERVED at. After any redirects have been followed, PixyScan uses the final URL, the one a visitor ends up on. That matters: a site that has already fixed a long URL by redirecting it to a short one has nothing to report, and measuring the requested address would report it anyway.

  2. Measures the whole string, decoded. The scheme, the host, the path and the query string are all counted. The address is decoded first, so a URL written with accented or non-Latin characters is measured at the length its owner sees rather than at the length its percent-encoded form happens to be -- a 48-character Cyrillic address is 48, not 133. A short path with a long query string is still a long URL and is reported as one.

  3. Compares it against 115 characters. A URL of exactly 115 characters passes; 116 fails.

  4. Reports the measurement. The finding names the length it measured and the limit it applied, so the number of characters that have to go is on the row itself.

The check makes no judgement about what the characters are. Naming problems such as uppercase letters or underscores are a separate check.

What we store

Storage Level

Page Level


Database Table / Prisma Model

audit_issues.details


Stored Fields

Field Type Description
url String The page URL that was measured
urlLength Int The measured length, in characters
actual Int The measured length, structured
expectedMax Int The limit applied, 115
difference Int How many characters over the limit

Detection Dependencies

  • HTTP Response
  • The page URL as the crawler fetched it

Note

This check reads only the address of the page. Its evidence is kept on the finding itself rather than in a per-page table: there is no measurement worth keeping for a URL that passes, and the address itself is already stored on the Urls row.

Further reading