13

Recently, a user started to submit a series of edit suggestions that change the TLD .com to .example in generic URLs used in console command examples (see e.g. this edit suggestion). In many cases, this was the only (visible) change to the original post, so the "edit volume" seems to be even lower than in this related question on "minor mass edits".

Is there any consensus on how to handle this kind of edits?

P.S. Just to be clear - I do not want to imply that I consider the user to be out for cheap reputation-hunting, there are enough examples of edits that make clear improvements to posts.

2 Answers 2

13

Changing .com to .example seems like, at best, a neutral change and at worst a bad one since it is changing a standard and immediately recognizable domain to one that is not even easily recognizable. Changing foo.com to example.com might make sense, but I feel that changing foo.com to foo.example is just confusing.

If that is the only change, I would reject the edit. However, I had a quick look at some of the other pending edits of this user and they often also include other fixes so in those cases, you may choose to "accept and improve" and just undo the .com => .example change.

6
  • 9
    It might be worth improving the edits to use example.com (or .org or whatever), see this example. .example isn’t a valid TLD but example.{com,net,org,edu} are explicitly reserved as example domains. Jun 24 at 14:45
  • @StephenKitt yes, exactly. That's what I meant here: "Changing foo.com to example.com might make sense, but I feel that changing foo.com to foo.example is just confusing."
    – terdon Mod
    Jun 24 at 14:52
  • 2
    Right, I was thinking of your suggestion to “just undo the .com => .example change”. I’m also not sure that all that many people are aware of the special status of example.com & co nowadays... Jun 24 at 14:55
  • "Finally, I also want to point out that it does look like this user is honestly trying to help". As the user is a veteran in stackexchange and a moderator, I would change that part, adding a link to their answer below, where they explain why such edits. As it is an important edit to this answer I'm just suggesting, not editing myself, but if it's OK I can do it. Jun 27 at 15:31
  • Fair enough, @schrodingerscatcuriosity. When I wrote that, I hadn't realized the user was an old hand on SE and I just didn't want them to feel attacked. That's why I added that note, to clarify that edits are welcome and the user is being helpful.
    – terdon Mod
    Jun 27 at 16:12
  • I can definitely see a value in changing valid domains to IANA reserved domains. Especially where it is clear a domain is genuinely valid but the OP didn't realise so... Here I refer to test dot com who had a moan on their page "We not being responsible for spam email". I can't seem to access the domain right now so maybe the self-inflicted groupthink DDOS attack has finally taken them down. As self inflicted as it may be, someone does actually own foo dot com! I will therefore always edit that one to example.com. Jul 12 at 15:53
20

Both example.com and the entire top level .example domain are officially approved for example usage. See the following RFCs and Wikipedia entries:

Whenever an example domain is used, it should be one of these reserved example domains. Using a real domain name is not desired because it can:

  • Bestow unwarranted SEO benefit to the domain, especially when linked, but possibly even just through a mention.
  • Cause problems for the domain when it gets unwanted requests from code that uses it as an example or when web crawlers find and hit the bogus URLs.

Most Stack Exchange sites actually prohibit new and edited posts from containing many incorrectly used example domains such as "mysite" or "domain" with a real top level domain suffix. This regular expression prevents a post from being submitted if the regular expression matches:

https?://(www\.)?(domain|xxx|xyz|abc|site|mysite|mydomain)\.(com|org|net)(?![a-z0-9\-]+|\.[a-z0-9]+)

A moderator could check that Unix & Linux actually has this rule by visiting the user input blocklist.


I acknowledge the feedback that example.com is more recognizable than some-domain.example and I'll prefer to use it in the future.

However, there are some cases in which example.com isn't sufficient. When you need to compare two domains, or when a specific keyword is needed in the domain name, .example domains work better. For example, cases in which a post uses multiple domains like:

  • siteA.example
  • siteB.example

or

  • myserver.example
  • myhost.example
  • mydns.example
13
  • 1
    Thanks for chiming in! Can you explain why siteA.example or myhost.example are clearer than siteA.com or myhost.net? Since foo.example just doesn't look like a TLD as we're not used to seeing such long ones in the wild, even if there is an RFC recommending them, it seems like the recommendation would only make sense when writing for experts not the general public.
    – terdon Mod
    Jun 26 at 10:24
  • 3
    Sure, I've added info about that case. Using an example domain on .com that isn't example.com is a bad thing to to. Jun 26 at 10:34
  • Wow, I’d completely missed the .example reference in RFC 2606! Thanks for taking the time to write this up (and to edit the posts). I was under the impression that the rel="nofollow" applied to links on SE was sufficient to negate SEO benefits, but I guess that’s not the case, right? Jun 27 at 10:10
  • 2
    nofollow helps, BUT: 1. Stack Exchange doesn't apply nofollow if the post scores high enough 2. Google announced that it doesn't always honor nofollow anymore (it will use it as a hint) 3. nofollow only applies to links, not to mentions. There is a strong suspicion that mentions are important to Google's algorithm, it isn't just links that matter. Jun 27 at 10:52
  • Sigh. I've been a mod for 8 years almost to the day and I'd never seen that /blocklist page you linked to! I will console myself with the fact that you've been a mod for a year longer and that's why you know it :P.
    – terdon Mod
    Jun 27 at 16:16
  • @terdon It's listed in the "links" section of the mod dashboard, but since the moderators can't actually make any changes to the blocklist, it is an information-only page and not one that you would typically need to know about. Jun 27 at 16:49
  • IANA reserves example.com and example.org. Is that not sufficient for domain matching examples? iana.org/domains/reserved Jul 12 at 15:44
  • @PhilipCouling The RFCs from the IANA there also list the entire .example TLD. There are plenty of posts that need more nuance than example.com and example.org can provide. client.example and server.example; or mysite.example vs othersite.example; also cases which need to compare three or more different example domains. Jul 12 at 16:39
  • @StephenOstermiller You may not be wrong. I've personally not come across a case where this was not an obviously fixable issue with subdomains foo.example.com bar.example.org bob.example.org. But hey, I can't speak for the examples you've seen. I certainly wouldn't reject an edit that changes foo dot com to foo.example just because one of them has publicly available DNS records pointing to a HTTP server and the other is IANA reserved. Jul 12 at 17:25
  • Subdomains work sometimes too, but there are certainly issues with cookies and CORS that work differently with subdomains. That may come up less on Unix and Linux than on other stacks like Webmasters where I'm more active. Jul 12 at 17:56
  • 1
    Browsers treat domains and subdomains differently in terms permissions. They have a list of what levels you're allowed to register and make security decisions at that level. So for example a subdomain can read cookies of the main domain but two separate domains can't read each other's cookies. Jul 12 at 21:42
  • @StephenOstermiller purely from a point of curiosity... The hierarchy rule makes sense. Under what context might the rule apply laterally. Can one subdomain read another subdomain's cookies? Jul 13 at 10:07
  • Subdomains have the option of setting a cookie at the domain level where it can be read by other subdomains, but they also have the option of limiting the cookie scope to just the subdomain. URL paths have similar cookie functionality. You can set a cookie to apply to the whole domain or just to sub-directories of the current path. Jul 13 at 13:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .