Michael Eriksson
A Swede in Germany
Home » Software development » Webdesign | About me Impressum Contact Sitemap

Errors related to websites


Apart from the errors in web design (discussed in other pages in this category) there are some common mistakes in related areas, e.g. the Internet as a whole and eCommerce. This page is a collection of some of them.


I will not bother to include rules like “never spam”, “never commit credit card fraud”, etc. Similarly, I would not include “do not rob your competition” in a discussion intended for bank managers. Nevertheless, apart from the out-right “Buy V1agra NOW!!!” spam, there are many somewhat more subtle cases that are given some mention.

Emails with “no-reply” addresses

Sending of email with “no-reply” addresses not only hinders communication (the worse, because this hindrance is often deliberate), but is also inexcusably rude. I note that if a company sends an unsolicited email (as we all know, it very rarely ends with one), it has a positive and non-negotiable duty to provide a valid return address, so that the recipient can answer. Such answers legitimately include “Stop spamming me, you jack-*ss!” (and, obviously, politer requests along the same lines), and it is the responsibility of the sender to act accordingly. Forcing the user to visit a web-page, make additional entries, possibly log-in to an existing account, or similar, is not acceptable (although it might be a valid additional mechanism).

Similarly, if a user has feedback to a newsletter, it is only reasonable that he should be able to give it by simply answering the email it was contained in. Then again, a company so stupid that it makes it hard to give feedback, is likely a company to stupid to do anything sensible with the feedback it does receive...

Assuming that the user opts-in

By presuming that users agree with being automatically included in e.g. lists for newsletters or spam, with their data being sold to third-parties, whatnot, many users are alienated, possibly even pissed off. The effect is more damage done to the senders overall reputation and profit than if it had waited for an explicit opt-in. In short: Assume that the user is not interested—until explicitly told otherwise.

I note that, apart from being pragmatically unwise, such inclusion is unethical—and stands a fair chance of eventually becoming illegal. (Since the time of original writing, 2009, there has been some progress in such legal regulations, but, as of 2023, not enough.)

An explicit opt-out possibility is better than nothing, but definitely not good. Not providing even an opt-out is inexcusable.


Some organisations do provide an opt-out, but make it so hard to complete the opt-out procedure (unclear instructions, forms that are hard to find, ...) that users refrain from opting-out, even when they want to.

It seems that many naive organisations actually believe that they will benefit from tricking users into remaining “in”. Of course, the few users who actually bring more revenue this way are far outweighed by those whose opinion of the organisation worsenes with every unwanted email.

Similar statements apply to organisations that make a registration contingent on an opt-in, hide the opt-in in their T&C’s, or add a statement like “By registering, you consent to XXX. You can at any time withdraw your consent by sending a letter to [snail post address].”.

Sending automatic responses to email

Apart from confirmation emails and other status messages, every email sent should be given a manual answer.

To exemplify how not to do it: Many years ago, I had a Hotmail account. On one occasion, I sent an email to the Hotmail help: I took some fifteen minutes out of my time, carefully stated what I needed, why I needed it, etc. What I received was an automatically generated response of (roughly) “Based on your email we have automatically detected that the following help entries are likely to explain your problem.”—absolutely inexcusable. To add injury to insult, the provided help entries had nothing to do with my query...

I note that at no point previous to the response was there any indication that I would not receive a manual response; further, that had I been given such an indication, I could have saved the fifteen minutes and received a more informative answer by simply entering a few select key-words in a search field—if, of course, Hotmail had provided a searchable help (it did not, other than the email responses). Trust Microsoft to take something user-friendly, easy-to-use, efficient, and effective—and turn it into something useless, time-wasting, and user-hostile.

Using uninformative aliases and email addresses

Many email clients will display the alias (“display name”) of the sender address without proper mention of the address it self—others will just use the local part of the address (what comes before the “@”).

The result is that users end up with a mailbox filled with “info”, “newsletter”, “customer service”, and similar—where it typically is not possibly to detect the sender based on the overview, but only upon visiting the detail view.

To avoid such problems, both the alias (if one is used: arguably, they do more harm than good) and the local part should be sufficiently clear. Compare e.g. “XXX newsletter <XXXnewsletter@YYY.com>” and “newsletter <newsletter@YYY.com>”, where “XXX” is a reasonably short and clear variation of the company name.


It can be argued that the inclusion of “XXX” in the local part is a redundancy contrary to the structure of an email address. My suggestion would be to include it with very common local parts, e.g. “info” and “newsletter”; normally not to use it with rare and long local parts; never to use it with names (“Michael.Eriksson@...”); and to use sound judgement elsewhere.

For aliases, in contrast, it should always be present for non-name addresses; and might often be wise to include even in those (“XXX: Michael Eriksson”, “Michael E. of XXX”, or similar). This will depend largely on the proportion of internal to external emails, and whether external emails are more likely to be sent to strangers than regular contacts.

Aliases should normally not contain any further information; advertising (“XXX, your partner for inspiring Internet solutions!”) is a big no-no; and lengthy aliases should be avoided. Beware, in particular, that most clients will have a limited field for the aliases in overviews, which can lead to cut-off messages. (Which is why I suggest pre-pending the company: “IBM newsletter” is reduced to “IBM newsl”, while “newsletter IBM” ends up as just “newslette”, in a nine character shortening.)

Not allowing variations on the host name

Some websites are only reachable over one host name, which can confuse the users or make them believe that the site is down.


This is an area with confusing terminology and it can be disputed whether it is better to speak of “host” or e.g. “[sub-]domain”. Arguably, neither is entirely on the spot in today’s world.

At least two variations on the host name, with and without a leading “www.”, should always be present: The former is a quasi-standard that most users will expect (even when not logically necessary); the latter allows economy when typing or copying an address—and enables use of an email address to access a website. (The last is a side-effect of “@” being a user name separator, typically used for websites with password protection on the HTTP level.)

Other variations might or might not be required depending on the organisation and circumstances. A multi-national company, e.g., would do well in keeping both a .com address and a country-specific TLD for each country it is represented in (e.g. .de, .se), and might even want to keep common misspellings and alternate variations of its name reserved. (This is a concern in particular for corporations that underlie a non-trivial risk of “imposter sites”.) For many others, the initial two variations are everything that is needed.

Importantly, when the names point to the same content (which should be the case for www/non-www and name variations, but not necessarily for TLD variations) the request should always be redirected to a canonical URL to avoid confusion. (This is also better from a SEO perspective, but that is a secondary concern for this discussion.)