What makes a high-quality website? It's not using the latest fashionable framework, or having the most polyfills. High-quality websites are largely timeless, bucking fleeting trends and staying the course to produce a stable, secure, and enjoyable user experience.
When building a website that will give a client good service for years to come, it's important to have that timeless aspect. Not everyone can afford to rebuild their site every few years, so making pragmatic decisions will benefit the client, the user, and any future developers.
Speed
A website should be fast. Aim for an initial server response in under 200ms, with a complete page load in under 1000ms. To aid this the page weight should be kept small—most pages should be under 1MB uncached, with a significant drop once shared assets are cached locally.
Speed helps users achieve their goals more quickly and, as Google's research1 shows, encourages them to spend more time using a website. It's important to note this is not only a network/server problem; perceived speed can be increased by designing interfaces which don't get in the users' way2.
Security
Websites should be secure, both for the user and the operator. Secure user data, strive to use SSL and strong encryption everywhere they're needed, and harden infrastructure by keeping software up to date.
Code quality
The quality of the underlying website code should be high. I fully subscribe to Abelson's assertion that programs should primarily be human-readable, and write my code accordingly.
Programs must be written for people to read, and only incidentally for machines to execute.
Harold Abelson
Alongside writing tests, promote high code quality by using linting. Linting not only eliminates fragile programming patterns but also enforces a common standard for formatting, which can minimise nitpicking comments during code review. When experienced programmers like John Carmack endorse linting and static analysis3 as a valuable method of eliminating bugs, it's worth taking note.
Inclusivity
Websites should be inclusive, catering to as many use cases as practically possible. Inclusivity encompasses a range of concerns, including progressive enhancement (the core functionality of a site must work without JavaScript) and accessibility.
Accessibility is often seen as affecting a small portion of a website's audience, but it can improve the experience of a huge spectrum of users. For example: colour contrast. Those subtle grey tones that look great on a designer's screen aren't so helpful on a brightly lit phone. Think of your users' needs, and compromise where needed.
Well documented
All non-trivial code should be well documented. The code itself should have comments to document its functionality, and the system should have documentation related to its usage. "The code is the documentation" is a lazy excuse—unless you're extending the system it's a wasted exercise to pick apart the code when a simple set of API documentation and examples would give the necessary information in a fraction of the time. Production-ready code is incomplete without documentation.
Conclusion
This is by no means an exhaustive list, or anything that people haven't said before (Jeremy Keith, in particular, has written and spoken in a similar vein). However, I feel it's a topic worth reiterating, since many sites still seem to miss the basics. Make websites you'll still be proud of in five years, and everyone will be better off.