The pages every public site needs

The part engineers skip

A site that accepts users is a small institution, and institutions have paperwork. Skipping it is common and it is a bet: that nobody asks, that nothing goes wrong, and that no obligation applies to you. That bet is fine at zero users and worse every month.

This lesson is a map of what exists. It is emphatically not legal advice: the rules differ by where you are, where your users are, what data you hold and what you charge for, and several of the questions below are actively unsettled in courts and parliaments right now. What it will do is stop you being surprised.

The five documents

1. Terms of service. The agreement between you and the user. What the service is, what people may not do, what happens when they break the rules, who owns what they post, that you may change or end the service, and where disputes are handled. Its main practical function on a small site is to give you a stated basis for suspending an abusive account.

2. Privacy policy. What personal data you collect, why, on what basis, who you share it with, how long you keep it, and how somebody exercises their rights. In many jurisdictions this is not optional if you have users there. It must describe what your system actually does: a policy copied from another site that names services you do not use is worse than none, because it is a written statement that is false.

3. Contact and identity. Some jurisdictions require a public business identity and contact address. Even where they do not, a reachable address is the difference between a complaint and a legal notice.

4. Community rules, if users can post. Short, specific, and written in the language of your users rather than of lawyers. This is the document moderators actually apply, and the one users are entitled to see before they are judged by it.

5. A cookie or tracking notice, if you set anything beyond what is strictly necessary.

Cookie banners

The rule in the European regime is roughly: cookies strictly necessary for the service need no consent; anything for analytics or advertising needs freely given, informed, opt-in consent, and refusing must be as easy as accepting. Most banners on the web do not meet that standard, and regulators have said so repeatedly.

There is a cleaner answer available to a small site: do not set any non-essential cookies, and you need no banner at all. Privacy-respecting analytics (Plausible, Umami, GoatCounter, or your own server logs) measure page views without per-visitor identifiers, and several are free to self-host. This is the rare compliance question with a better technical answer than the legal one.

Where it is unsettled, and stays unsettled

Be honest about the live disputes rather than pretending they are resolved:

• Training data and copyright. Whether using copyrighted material to train a model is permitted, and under what conditions, is being litigated in several countries with different answers emerging. Anybody who tells you this is settled is describing one jurisdiction’s current position as though it were universal.
• Ownership of model output. Whether machine-generated work attracts copyright, and to whom, varies: some offices require meaningful human authorship, and the boundary is being drawn case by case.
• Cross-border data transfer. The legal mechanisms for moving personal data between regions have been struck down and rebuilt more than once. Anything you build on top of one should be able to survive the next change.
• Platform liability for user content. Different regimes, actively being amended, with different duties by platform size.

The engineering response to all four is the same: keep records of what you collected and from where, keep the ability to delete or move it, and do not build a product whose viability depends on one contested legal question going your way.

Accessibility is also an obligation

In a growing number of jurisdictions, public digital services must meet an accessibility standard, and the direction of travel is towards more sectors rather than fewer. Separately from any law, it is the difference between your site being usable by somebody with a screen reader or not.

The basics are not expensive: semantic HTML, real labels on form fields, keyboard operability, sufficient colour contrast, alt text, and not conveying meaning by colour alone. Free checkers (axe, Lighthouse, WAVE) find most of the mechanical failures in one pass.

What to do this week

1. Write the privacy policy from your own schema: open the tables, list the personal data, and describe it truthfully.
2. Publish a contact address that a human reads.
3. Remove any tracking you are not actually using: most sites are carrying a script somebody added in year one and nobody reads.
4. Run one accessibility check and fix the automated findings.
5. Note the two or three legal questions that apply to your situation, and get advice on those rather than reading forums about all of them.