Website Visitor Privacy: What to Collect and What to Leave Alone
Most sites collect far more about their visitors than they will ever use. Here is a shorter list that answers the same questions with less to protect.
On this page
The reliable way to improve visitor privacy is not better security around the data you hold. It is holding less of it.
Data you never collected cannot leak in a breach, cannot be demanded in a subject access request, cannot be sold by a vendor you did not read carefully, and cannot be misused by a future version of your own company. Every field you skip removes a whole category of risk permanently.
The useful question is therefore not “what can we collect” but “what do we actually use”.
The Short List That Answers Most Questions
For a typical content site, these five give you nearly everything you will ever act on.
Page URL. Which content gets read. This is the foundation and nothing works without it.
Referrer. Where the visit came from: search, a link on another site, social, direct. Answers the second most common question you will ask.
Country and region. Enough to know whether your audience is where you assumed, whether international readers are being served properly, and whether a spike is local or global.
Device category. Phone, tablet or desktop. Enough to make design decisions.
Timestamp. When it happened, so you can see trends and spikes.
That is it. Five fields, and between them they answer what is popular, where readers come from, where they are, what they read on, and when. If you cannot name a decision that a sixth field would change, you do not need the sixth field.
The Two Heavy Ones
Some data is heavier than other data, in the sense that holding it brings obligations that scale.
Full IP addresses. Under GDPR an IP address is generally personal data, because combined with other information it can identify a person. Storing one is not forbidden, but it means you need a lawful basis, a retention period, and a plan for access requests.
Here is the thing most sites discover when they check: they never query the IP field. It was collected because it was available. If what you actually wanted was geography, derive the country at the moment of the request and discard the address. You keep the answer and drop the liability.
Cross-site identifiers. Anything that lets a visitor be recognised across different websites is a different order of collection from anything that stays within your own. It is also what most privacy tooling and browser policy is actively working against, so it is a shrinking capability to build on.
Storage Is What Triggers Consent
The mechanism worth understanding: in the UK and EU, the rules that produce cookie banners attach to storing or reading information on a visitor’s device, largely independent of whether that information is personal data.
That is why a tool setting analytics cookies raises a consent question that a tool storing nothing on the device does not raise in the same form.
DevDome Analytics is cookieless by default: no analytics cookies are set, so there is nothing on the visitor’s device and no analytics cookie to ask permission for. That makes it GDPR-friendly rather than compliant, because compliance is a property of your whole site and your own practices, not something a plugin can grant you. Check your own obligations.
The practical benefit beyond the legal one is that measurement which does not wait for a consent click measures everybody, not just the people who clicked accept.
Set a Retention Period and Mean It
Almost nobody looks at raw visit data from two years ago. Almost everybody still has it.
Decide how long you need detail for, keep aggregates beyond that, and delete the rest on a schedule. Aggregates are usually what you actually want for long term comparisons anyway: monthly pageviews per post, not the individual visits that made them up.
Shorter retention shrinks every risk at once, and it costs you almost nothing you will miss.
Know Where the Data Lives
Two questions worth being able to answer without looking anything up.
Which company processes your visitor data, and in which country are their servers? Both matter for your privacy policy, and international transfer rules mean the second one has consequences.
If you cannot answer them for a tool you use, that is a reason to find out rather than a reason to worry, but it should be findable in a few minutes.
Check What Your Plugins Collect Too
Your analytics is rarely the only thing collecting data on your site.
A typical WordPress install ships several plugins that quietly store visitor information: comment systems keeping IP addresses, security plugins logging every failed request, contact forms saving submissions in the database indefinitely, caching plugins recording visit patterns.
None of those are wrong to exist, and most site owners have never looked at what they retain. The security log is usually the largest surprise, because it is designed to keep everything forever on the theory that you might need it during an incident.
Spend twenty minutes going through your plugin list and asking the same question you asked about analytics: what does this store about visitors, and for how long. Most of them have a retention setting nobody has ever changed from its default, and turning three of those down is a bigger privacy improvement than switching analytics tools.
Write the List Down
Whatever you settle on, write it down: the fields you collect, why each one exists, how long you keep it, and who processes it.
You need this document anyway, because it is what an honest privacy policy is made of. But the more useful effect is the one it has on you: writing “we collect X because” forces the justification, and the fields that cannot complete the sentence are the ones to delete.
Most sites doing this exercise for the first time delete something within ten minutes.
Disclosure: DevDome publishes this blog and makes the products it mentions. We describe what they do rather than promise results.
Key takeaways
- Data you never collected cannot leak, cannot be requested, and cannot be misused.
- Country and region answer nearly every geography question a small site has.
- Full IP addresses and cross-site identifiers are the two heaviest things to hold.
- Storing on a visitor's device is what triggers most cookie consent obligations.
- Write down what you collect; you need it for your privacy policy anyway.
Sources
- ICO guidance on cookies and similar technologies — when storing information on a device requires consent
- European Commission: what is personal data — the definition that identifiers such as IP addresses fall under
Links last checked August 26, 2026.
Frequently asked questions
Is an IP address personal data?
Under GDPR it is generally treated as personal data, because it can identify a person when combined with other information. That does not make collecting one forbidden, it makes it something you need a reason and a retention limit for. Many sites find they never actually query IP addresses and can stop storing them entirely.
Do I need consent for analytics?
It depends on what your analytics does rather than on the fact that you have analytics. Rules in the UK and EU attach to storing or reading information on a visitor's device, so a tool that sets no cookies and stores nothing sits differently from one that does. Check your own obligations and your own jurisdiction, since consent law covers more than cookies alone.
What is the minimum I need to run a content site?
Page URL, referrer, rough geography, device category and a coarse timestamp. That is enough to know what is read, where readers come from, and which devices to design for. Everything beyond it should have to justify itself.
Should I anonymise IP addresses or not store them?
Not storing them is stronger and simpler. Anonymisation is a process you have to implement correctly and keep working, while a field you never write cannot be got wrong. If you need geography, derive the country at the moment of the request and discard the address.