What a Small Business Website Actually Needs for Privacy: Policy, Cookies, Forms and Consent

Someone asked whether your website is “GDPR compliant”, or a customer wanted to know what you do with the details they typed into your contact form, and you realized you do not really know. Maybe you have a privacy policy a previous designer pasted in years ago. Maybe you have no cookie banner and wonder whether you need one, or you have one and wonder whether it does anything.

This guide is the practical, non-lawyer version: what a typical small business WordPress site collects, what paperwork and settings usually go with that, and how to find out what your own site actually does. It is not legal advice. Privacy law depends on where you and your visitors are, what you sell and how you use data, and only a qualified adviser can tell you what applies to you. What this guide can do is make sure you walk into that conversation knowing exactly what your site collects.

What is happening

Privacy rules attach to personal data: anything that identifies a person directly or indirectly. On a website that includes names and email addresses from forms, IP addresses in logs and comments, cookie identifiers set by analytics or advertising tools, and order details in a shop. The important point is that much of this collection happens without you writing any code. Plugins, embeds and third-party scripts collect it on your behalf.

Where data comes from	Typical examples	Where it ends up
Forms	Contact, quote, newsletter, booking	Your inbox, the form plugin’s entries table, a mailing service
Comments and accounts	Commenter name, email, IP address, user agent	The WordPress database
Cookies and similar storage	Analytics client IDs, advertising pixels, chat widgets, local storage	The visitor’s browser, plus the vendor’s servers
Embeds and remote assets	YouTube, Google Maps, fonts loaded from a third-party server	The third party sees the visitor’s IP address and browser details
Server and security logs	Access logs, firewall logs, login attempt logs	Your host and your security plugin
Backups	Full copies of the database and uploads	Your host, a backup plugin’s cloud storage

In broad terms, a small business site usually needs four things: an accurate privacy policy, a lawful approach to cookies and similar technologies, sensible handling of form and customer data, and agreements with the companies that process data for you. The details of each vary by law.

When consent banners are typically expected

• EU and UK: the ePrivacy rules (implemented in the UK as PECR) generally require consent before storing or reading non-essential information on a visitor’s device, such as analytics and advertising cookies. Strictly necessary storage, such as a shopping cart or login cookie, is generally exempt. GDPR and UK GDPR then govern how personal data is handled more broadly. The UK has legislated changes that relax consent for some low-risk uses; check the ICO’s current guidance on whether and how they apply.
• United States: there is no single federal equivalent. A growing number of states have comprehensive privacy laws, which mostly work on an opt-out model: telling people what you collect and letting them opt out of the sale or sharing of their data or targeted advertising. Whether a law applies to you depends on thresholds such as revenue or the number of residents whose data you handle, and those differ by state. Some states also expect you to honor browser opt-out signals such as Global Privacy Control.
• Elsewhere: many countries have their own laws. If you serve visitors internationally, ask your adviser which ones matter.

A banner is a tool, not a goal. A site that sets no non-essential cookies and loads no tracking may not need one at all. That is often the cheapest compliance strategy for a small business.

Before you start

You need WordPress admin access, logins for any services connected to the site (analytics, email marketing, chat, form services), and ideally SSH access. No changes in this guide are destructive until you start deleting stored data; take a full backup before you do that.

Commands run in three places. Browser checks use DevTools (F12, or Cmd+Option+I on a Mac). curl runs on your own computer: macOS and Linux include it, and on Windows 10 and 11 use curl.exe in PowerShell. WP-CLI commands run over SSH in the site folder, the one containing wp-config.php; depending on your host the command is wp or wp-cli. If you have no SSH access, every WP-CLI check here has an admin screen equivalent.

Step 1: Find out what your site actually collects

You cannot write an honest policy or decide on a banner until you have an inventory. Do this from a visitor’s point of view first.

List cookies and storage in the browser

Open a private window, load your home page and one page with a form or embed. In DevTools, open Application, then Storage, then Cookies, and click your domain. Note each cookie’s name and domain. Then check Local storage and Session storage. Also look at the cookie list for other domains shown in the left panel: those are third-party cookies.

Write down every cookie and what sets it. Names often give it away: _ga and _ga_ prefixes come from Google Analytics, _fbp from the Meta pixel, wordpress_logged_in_ from a WordPress login, woocommerce_cart_hash from WooCommerce. Search the name if you are unsure.

List third-party hosts the page talks to

On your own computer, this lists the external domains referenced in the page HTML, with a count for each.

curl -s https://example.com/ | grep -o -E '(src|href)="https?://[^/"]+' | sed -E 's#.*://##' | sort | uniq -c | sort -rn

Replace example.com with your domain, and repeat for a page with a form or video. grep -o -E extracts every src or href pointing to a full URL; sed strips everything up to the domain; sort | uniq -c | sort -rn counts and ranks them. Good output is mostly your own domain and a handful of services you recognize and chose. A warning sign is a domain you cannot explain, such as an ad network or a font or tracking service a theme added without telling you. This only sees what is in the initial HTML; scripts can load more, so also check the DevTools Network tab with the “3rd-party requests” filter or the Domain column.

List active plugins

wp plugin list --status=active --fields=name,title,version

Run this over SSH in the site folder. --status=active limits the list to running plugins; --fields chooses the columns. Go through the list and mark every plugin that collects or sends data: forms, analytics, newsletter, chat, reviews, security, backups, shop, booking. The same list is under Plugins in the admin.

Find where form and lead data is stored

wp db tables --all-tables-with-prefix

Run this over SSH. --all-tables-with-prefix lists every table using your WordPress table prefix, including plugin tables. Look for names containing form, entries, submissions, leads or a plugin’s name. Each of those tables probably holds personal data you need to cover in your policy and your retention plan. If the command reports an error connecting to the database, check that you are in the right folder.

Step 2: Write or update the privacy policy

A privacy policy tells visitors what you collect, why, who you share it with, how long you keep it and how they can exercise their rights. It must describe what your site really does, which is why Step 1 comes first.

Use the WordPress Policy Guide

Go to Settings, then Privacy. On the Settings tab you can create a new privacy policy page or choose an existing one. WordPress then links to it from the login screen, and themes and plugins such as WooCommerce can link it from forms and checkout. The Policy Guide tab collects suggested text from WordPress core and from plugins that register it, grouped by plugin. It is a useful checklist of what your plugins say they collect. It is not a finished policy, and plugins that do not register text will not appear.

Check which page is set and whether it is published.

wp post get $(wp option get wp_page_for_privacy_policy) --fields=ID,post_title,post_status,post_modified

Run this over SSH. The inner command reads the option that stores the privacy page ID; the outer command shows that page’s title, status and last modified date. Good: post_status is publish and the modified date is recent. Bad: an error saying the post could not be found (no page is set), draft, or a date years old.

What a small business policy usually covers

• Who you are and how to contact you about privacy.
• Each kind of data you collect (from your Step 1 inventory) and why.
• The services that receive data: your host, email provider, analytics, newsletter service, payment provider.
• How long you keep each kind of data.
• Cookies and similar technologies, often in a separate cookie policy your banner links to.
• Visitors’ rights and how to use them, which leads to the separate guide on handling data access and deletion requests.

Avoid generic templates that promise things you do not do, such as “we never share data with third parties” on a site running Google Analytics. An inaccurate policy can be worse than a short honest one.

Step 3: Decide whether you need a consent banner

Work through your cookie list from Step 1 and sort each item into strictly necessary (login, cart, security, remembering consent itself) and everything else (analytics, advertising, embeds that set cookies, chat widgets that track). If everything is strictly necessary, you may not need a banner. If anything is not, and you have EU or UK visitors, a consent mechanism is usually expected before those items load.

The options, roughly from simplest to most involved:

1. Remove the non-essential items. Self-host fonts instead of loading them from a third-party server. Replace a map embed with a static image linking to the map. Drop pixels you no longer use.
2. Load embeds on click. Show a thumbnail with a button; the third party only loads when the visitor asks.
3. Use a consent management plugin or service that blocks scripts until consent and records the choice. If one breaks parts of the site, see the separate guide on consent banners breaking sites or analytics.

A banner that appears but loads analytics before anyone clicks does not do its job. Test it: in a private window, load the page without clicking anything and check the DevTools cookie list. Analytics cookies should not be there yet.

Step 4: Choose your analytics deliberately

Analytics is the most common reason a small site sets non-essential cookies. You have real choices.

Approach	Examples	Privacy trade-offs
Third-party analytics with cookies	Google Analytics 4	Powerful and free, but sets identifiers and sends data to a third party. In the EU and UK this generally means consent first. Configure Consent Mode, data retention and data sharing settings.
Privacy-focused hosted analytics	Plausible, Fathom, Simple Analytics	Designed to avoid cookies and persistent identifiers. Fewer features, usually paid. Whether consent is still needed depends on the tool’s configuration and the law where you operate.
Self-hosted analytics	Matomo on your own server	Data stays with you; can be configured to run without cookies. You maintain it, and it adds load to your server.
Server log analysis	Your host’s statistics panel	No scripts at all. Less detail, and bots inflate the numbers.

If you keep GA4, review Admin, Data collection and modification, Data retention, and set the shortest event retention that still serves you. Turn off data sharing settings you do not need. Fewer data collected means less to disclose and less to protect.

Step 5: Minimize and expire contact form data

Contact forms are where most small businesses actually hold personal data, and they often keep it forever by default.

Collect less

Ask only for what you need to reply. A phone number field that nobody uses, a required date of birth, or a “company size” dropdown all add data you must protect and explain. Remove optional fields you never read.

Know every copy

One form submission can exist in several places at once: the form plugin’s entries table, the notification email in your inbox (and every device synced to it), an auto-reply log in an SMTP plugin, a CRM or mailing list the form feeds, your backups and possibly a spam log. Your retention plan has to cover each copy, not just the one you see.

Set a retention period

Choose how long you need inquiries, for example long enough to follow up and handle disputes, and write it in your policy. Then make it happen: many form plugins have a setting to stop storing entries or to delete them after a number of days; others need manual clean-up or a scheduled task. Some, such as Contact Form 7 on its own, do not store entries at all and only send email, which shifts the retention question to your inbox. Email logging plugins also store message content; set them to purge old logs.

Step 6: Put agreements in place with your processors

Under GDPR and UK GDPR, a company that handles personal data on your behalf (a processor) must have a contract with you that covers what they do with it. That includes your host, email provider, newsletter platform, analytics provider and backup storage. In practice, most established services publish a data processing agreement (DPA) or data processing addendum, often accepted in the account settings or included in their terms. Your job is to find and keep a copy.

Make a simple table: service, what data it receives, where its DPA is, and where it stores data. That table becomes the “who we share data with” section of your policy and is exactly what an adviser will ask for.

Step 7: Know the WordPress privacy tools

WordPress includes tools for privacy requests under Tools: Export Personal Data and Erase Personal Data. They find data linked to an email address in WordPress itself and in plugins that register with the tools, send confirmation emails, and produce an export file or anonymize the data. They do not reach data outside WordPress, such as your inbox or mailing list. The full workflow is in the separate guide on handling data access and deletion requests with WordPress tools.

Before you need them, test them on your own email address so you know which plugins participate.

Advanced: build a data map you can maintain

Designers and freelancers looking after several client sites benefit from a repeatable data map. For each site, record:

• each collection point (form, comment, account, checkout, analytics, embed);
• the fields collected;
• the purpose;
• every storage location (database table, inbox, external service, backups, logs);
• the retention period and how it is enforced;
• the processor and its DPA;
• whether the item needs consent, and how the banner handles it.

Re-run the Step 1 checks after every redesign, new plugin or new marketing tag, and compare the cookie and third-party host lists with the previous ones. A cheap way to catch surprises is to save the curl host list to a text file each time and compare files: a new domain appearing is your prompt to update the policy and the banner.

Remember server logs too. Access logs record IP addresses for every request. Ask your host how long they keep them, and note that in your map.

US state privacy laws

The United States has no single federal privacy law for websites, but a growing number of states have comprehensive consumer privacy laws. California’s Consumer Privacy Act, as amended by the California Privacy Rights Act (together usually called CCPA), was first. Others include Virginia, Colorado, Connecticut, Utah, Texas and Oregon, and more states have passed laws since, with different effective dates, so check the current list with an adviser. This is a summary to prepare you for a conversation with an adviser, not legal advice.

Do they apply to a small business?

Most of these laws only apply above a threshold. Under CCPA, a for-profit business doing business in California is covered if it meets any one of these: annual gross revenue above a set amount (USD 25 million in the statute, raised for inflation to USD 26,625,000 from January 2025; the California Privacy Protection Agency adjusts it every two years and publishes the current figure); buying, selling or sharing the personal information of 100,000 or more California consumers or households a year; or earning half or more of its annual revenue from selling or sharing personal information. Other states mostly use the number of state residents whose data you process each year, often with a lower number if you sell data, and a few, such as Texas, use a different small business test instead. Check the rules for each state where you have customers with a lawyer licensed in the US.

Many small businesses fall below every threshold. Two things push sites over sooner than people expect:

• Advertising pixels and tracking. Under CCPA, sharing personal information for cross-context behavioral advertising counts as “sharing”, and some advertising and analytics set-ups can count as a “sale”; ask an adviser how your tools are classified. Visitors counted by those tools may count toward the thresholds.
• Volume, not customers. Thresholds based on consumers or devices can be reached by website visitors, not just paying customers, depending on how each law counts consumers.

What covered sites usually need

• A privacy policy with the disclosures the state law requires, such as categories of data collected, purposes, who receives it and how to exercise rights.
• A way to opt out of the sale or sharing of personal information and of targeted advertising. In California this is commonly a “Do Not Sell or Share My Personal Information” link where the business sells or shares data.
• Honoring browser opt-out signals such as Global Privacy Control. California’s regulations require this, and Colorado and some other states require recognition of universal opt-out signals; the list of states is growing, so check with an adviser.
• A process for access, deletion and correction requests within the deadline the law sets. The WordPress tools help; see handling data access and deletion requests.
• Extra care with sensitive data, such as health, precise location or data about children, which several states restrict even for businesses below the usual thresholds; which data and which businesses are covered varies by state.

If your consent banner supports US opt-out modes and Global Privacy Control, configure them for US visitors rather than copying an EU set-up; see consent banners breaking sites or analytics if that changes what loads.

Google Fonts and GDPR

When a page loads fonts from Google’s servers (fonts.googleapis.com for the stylesheet and fonts.gstatic.com for the font files), each visitor’s browser connects to Google and sends its IP address. In January 2022 a German regional court, the Landgericht München I (case 3 O 17493/20), decided that a website had breached a visitor’s rights under GDPR by passing his IP address to Google through dynamically embedded Google Fonts without consent, and awarded him EUR 100 in damages. Later that year many German site owners received letters citing the case and demanding payment.

That is one court decision in one country, not an EU-wide rule, and it is not legal advice. But the fix is simple and usually makes the site faster too: host the fonts on your own server, so no visitor data goes to Google for fonts at all.

Check whether your site loads Google Fonts

curl -s https://example.com/ | grep -o -E 'fonts\.(googleapis|gstatic)\.com' | sort | uniq -c

Run this on your own computer, replacing example.com with your domain. grep -o -E prints every mention of either Google Fonts domain in the page HTML, and sort | uniq -c counts them. No output is good for that page; a count next to either domain means the page references Google Fonts. Fonts can also be requested by scripts after the page loads, so confirm in the browser: open DevTools, Network, reload, and type fonts.g in the filter box. Any request to fonts.googleapis.com or fonts.gstatic.com means fonts are still loading from Google. The DevTools cheat sheet explains the Network panel.

Switch to self-hosted fonts

• Theme or builder setting. Many themes and page builders have an option to load Google Fonts locally, which downloads the files to your server and rewrites the CSS. Turn it on, clear every cache and run the check again.
• Block themes. Since WordPress 6.5 the Font Library in the Site Editor can install Google Fonts. It asks your permission before connecting to Google to show the collection, then downloads the chosen fonts to your server (by default under wp-content/uploads/fonts), so visitors load them from your site.
• Manual or plugin route. Download the font files, upload them to the theme or a fonts folder, and declare them with @font-face in your CSS, or use a plugin that does this for you. Remove the old Google Fonts link afterward.
• Look for other sources. Plugins, embedded Google Maps, reCAPTCHA and some sliders load Google Fonts themselves. The Network panel shows which file requested each font in the Initiator column.

If fonts change to Times New Roman or another fallback after the switch, see fonts showing as Times New Roman. If you received a letter demanding payment over Google Fonts, do not pay or reply until you have taken advice; scary emails about your website explains how to assess demands like this.

Where to get real legal advice

For anything beyond the basics, talk to a lawyer or privacy professional who knows your jurisdiction and industry. Regulators also publish free, readable guidance for small organizations: in the UK, the Information Commissioner’s Office; in EU countries, the national data protection authority; in US states with privacy laws, the attorney general’s office or a dedicated agency such as California’s privacy agency. Trade associations and small business support services often offer low-cost privacy templates and sessions. Bring your data map: it turns an expensive open-ended conversation into a focused review.

When to contact your host

Your host is one of your processors, so open a ticket and ask for:

• their data processing agreement and where your site and backups are stored;
• how long server access logs, error logs and backups are kept, and whether you can shorten that;
• whether any security service they run in front of your site sets cookies or processes visitor data.

Include your domain and account details so they can answer for your specific plan. If something on the site is actually broken rather than a compliance question, the Emergency Room is the place to start, and the diagnostic tools page links tools for inspecting headers and third-party requests.