Percentage of users who edit the URL of the site they're on?

Question

The company I work for rents out vacation properties, with an alphanumeric ID for each property. Such as http://www.example-domain.tld/abc123456

There are SEO recommendations for using a slug / permalink with 3-5 keywords in them instead. Such as http://www.example-domain.tld/vacation-property-in-italy/

The internal (company) reason cited to keep the ID as-is, is for better user experience, with the explanation that if users edit the URL, they will encounter an error page. However, this got me thinking as to what percentage of users actually do (and know how to) change the URL of a specific page. I was unable to find an answer, searching online, and figured that this would be an excellent forum for it.

Is there any statistical information on whether users manually change the url in the browser? Are there any user tests that have been published, with information about whether people even know how to change the URL?

EDIT: A number of comments relate to people's own practice in modifying URLs - I appreciate the feedback on that, however I am looking for information (statistics, studies or similar) that support either the claim that users do or do not (or don't know how to) modify the URL of the page they're on. With the stats in hand, improving the user experience with regards to the URLs is easier.

Answer 1

I don’t know any general studies about it, and I guess it would be very hard to come up with a sensible one. I think it’s safe to assume that this very, very much depends on a) target group and b) URL design.

So even if users regularly manipulate URLs, this doesn’t mean that they do it on every site, because often the URL design is not good, i.e., the URLs are not browsable at all.

Why? (Motivations)

I think there are three main motivations for manipulating the URL:

• Navigation: Users know (or assume) how the URL design works and want to reach a specific resource.
• Error correction: Users try to fix a URL that leads to a 404 error page, because they think the page should exist and they assume that the URL might contain an error (e.g., missing a part, mistyped something, etc.)
• Curiosity: Users try to find (possibly "hidden") content, but they don’t know if it exists at all.

Other motivations might be: trying to make the URL shorter (removing unnecessary parts); removing referrer parts (e.g., from affiliate links); removing identifying parts (e.g., session or tracking IDs); ….

How? (URI parts)

Host / domain

Users might try to remove or add subdomains, second-level, and top-level domains.

Examples:

• Switch from the English to the German Wikipedia by replacing the subdomain en. with de.
  1. http://en.wikipedia.org/
  2. http://de.wikipedia.org/
• Switch from Amazon France to Amazon Germany by replacing the top-level domain .fr with .de
  1. http://www.amazon.fr/
  2. http://www.amazon.de/

Path

The slash / is probably the most used delimiter for path segments.

As the URI standard says (emphasis mine):

The path component contains data, usually organized in hierarchical form, […]

So for navigational purposes, it can expected that users

• remove path segments (delimited by /) from right to left
• add path segments from left to right, delimited by /
• replace strings between /

Examples

• Switch from the "php" to the "python" tag by replacing the corresponding strings:
  1. https://stackoverflow.com/questions/tagged/php
  2. https://stackoverflow.com/questions/tagged/python
• Remove the whole path to reach the home page:
  1. http://en.wikipedia.org/wiki/Stack_Overflow_%28website%29
  2. http://en.wikipedia.org/
• Append a segment to reach the Edit page:
  1. http://any-wikkawiki.example.com/FAQ
  2. http://any-wikkawiki.example.com/FAQ/edit

Query

Typically more complex than the path.

It’s likely that only users that know the typical format (each key-value of the formkey=value, the first one introduced by prefixing ?, additional ones by adding & as a delimiter) add/remove whole key-value pairs.

Others would probably only replace existing values.

Examples

• Go from page 2 to 5 by replacing the value of the page key:
  1. http://example.com/products?page=1
  2. http://example.com/products?page=5
• Switch to French translation by adding the whole query component:
  1. https://support.google.com/webmasters/answer/47334
  2. https://support.google.com/webmasters/answer/47334?hl=fr

Fragment

Unless the site uses JavaScript to show different pages when changing the fragment, users can manipulate it typically without "breaking" something. They might try to add the whole fragment component (prefixed by #), replace the value of an existing fragment, or remove the whole fragment.

Examples:

• Reach the top of the page by removing the whole fragment:
  1. http://tools.ietf.org/html/std66#section-3.5
  2. http://tools.ietf.org/html/std66
• Replace a value to jump to a specific section:
  1. http://tools.ietf.org/html/std66#section-3.5
  2. http://tools.ietf.org/html/std66#section-4
• Guess that a page allows to jump to a specific section by adding a fragment:
  1. http://de.wikipedia.org/wiki/GeSHi
  2. http://de.wikipedia.org/wiki/GeSHi#Weblinks

---

Your example

For your example case, only the URI path matters, so it’s /abc123456 vs /vacation-property-in-italy/.

If the motivation is Navigation:

• The cryptic path doesn’t allow anything except removing it completly to reach the home page.
• The readable path additionally might allow users to switch to similar pages, if they assume/know that they exist (!), by replacing values, e.g., by replacing italy with france.
  • I don’t think that users would assume to find something when removing only parts of the dash-delimited path segment (e.g., from /vacation-property-in-italy/ to /vacation-property-in/ to /vacation-property). This would be very uncommon as almost no site allows this (as this is typically only possible with /)

If the motivation is Error correction:

• The cryptic path doesn’t allow anything except "obvious" cases like removing whitespace or trailing punctuation.
• The readable path allows various kinds of corrections, e.g., when users see /vacation-property-in-italyy/ they might try to fix it by replacing italyy with italy.

If the motivation is Curiosity:

• The cryptic path invites users to try to find other pages by changing the ID, maybe with the hope to find hidden/private content, especially when it looks like the number is incremental.
• The readable path doesn’t convey that there would be something users wouldn’t be "allowed" fiddle with (like it’s the case when cryptic IDs are used), so there is probably no motivation to find private content. So the only thing users might try would probably be replacing some words (similar to the Navigation case).

---

Conclusion:

• In the Curiosity case, anything goes, no matter how the path looks like. Users probably never expect that their manipulation works at all.
• In the Navigation case, the readable path wins if there are such related pages. If not, it doesn’t matter (then it would fall into the domain of the Curiosity case anyway).
• In the Error correction case, the readable path wins.

So the company is right, the readable path probably leads to more users trying to manipulate it. But the company is wrong in assuming that this leads to a worse user experience. If the URL/link contains an error (for example, because some characters were stripped in a mail client, or because it was dictated via phone, or because someone mistyped it), then users have a chance to correct it. In all other manipulation cases, users know that they might and expect they will stumble upon error pages.

(Apart from SEO and manipulation, readable/descriptive URLs offer, of course, various other benefits.)

Answer 2

I don't imagine many "Edit" the URL but most people do copy and paste, or click URL's. When a URL is abc123456 it's easy to be mislead or have to click on every link until you find the one which is actually the one you want. URL's are made to be read by humans, they aren't for the computer, they're for US. Having a human readable URL is a long established usability benefit.

http://en.wikipedia.org/wiki/Clean_URL

Answer 3

The URL should ideally be tied to the information on the page in a way that the user can know what information a page contains prior to clicking on it if the link is visible somewhere or if they save it.

If users modifying the url is a concern, try the following, which is a combination of both:

• www.example-domain.tld/Property-abc123456-vacation-property-in-italy

This gives a unique URL for each property available, but still allows for descriptive text in the URL and page title.

With that method, I would assume the page title would be similar to "Property abc123456: Vacation Property in Italy

Answer 4

Do it like stackexchange does and combine the ID with a friendly URL:

 http://www.example-domain.tld/abc123456/vacation-property-in-italy/ 

When the user inputs an URL where ID and title don't match, the ID should have priority - redirect to the page with the same ID and the corrected title. That way you keep the ability to navigate by ID number and avoid name conflicts, but still have URLs which are human-readable and search-engine-readable.