How to Add Privacy Policies to All Your WordPress Client Sites

If you build sites for clients, privacy policies are one of those jobs that quietly becomes your problem. The client assumes it is handled. Nobody budgeted for a lawyer. And the page has to exist before launch. This guide covers what a privacy policy actually needs to do, the free tools WordPress already gives you, and when a paid generator is worth the money.

One thing up front: we are not lawyers and this is not legal advice. Privacy law varies by jurisdiction and by what your client's site actually collects. For anything high-risk, the answer is a solicitor, not a plugin.

Why client sites need one at all

A privacy policy is required once a site collects personal data, and the threshold for what counts as collecting is lower than most clients expect. A contact form collects personal data. So does a comment field, an email signup, an analytics script that sets identifiers, or an embedded video that drops a cookie. A brochure site with a contact form is already in scope.

Which laws apply depends on where the client operates and where their visitors are, not where the server sits. A small business with customers in the EU or California can fall under obligations it never considered. The practical consequence for you as the builder: assume a policy is needed, and make sure the client knows it is their responsibility to keep it accurate.

What a privacy policy needs to cover

Regardless of jurisdiction, a usable policy answers the same basic questions honestly:

• What data the site collects, and through which features.
• Why it is collected, and the legal basis where that applies.
• Who else receives it, including analytics, hosting, email and payment providers.
• How long it is kept.
• What rights visitors have, and how to exercise them.
• A real contact route for privacy requests.
• How cookies and similar tracking are used.

The failure mode is not missing sections. It is a policy that describes a site the client no longer runs, listing services they dropped two years ago and omitting the three they added last month.

Option 1: the tools WordPress already ships

This costs nothing and is the right starting point for most small client sites. WordPress has built-in privacy features that many agencies never open.

Under Settings, then Privacy, WordPress lets you designate a page as the site's privacy policy, or generate a draft one. The draft is not boilerplate to publish as-is: it is a guide with suggested wording and prompts marked for you to complete. Usefully, well-behaved plugins add their own suggested clauses to that guide, so if a plugin sets cookies or sends data to a third party, it can tell you what to disclose. That gives you a checklist of what the site actually does rather than a generic template.

WordPress also includes personal-data tooling under Tools: export personal data and erase personal data, both keyed to an email address. These exist to service subject access and deletion requests, and they are worth showing the client so they know the mechanism exists.

Option 2: write it yourself and keep it current

Also free, and often more accurate than a generated policy, because you are the person who knows exactly which services the site talks to. Start from the core privacy guide, then walk the site and write down every place data leaves it: the form handler, the analytics script, the email platform, the payment processor, the CDN, any embeds.

The catch is maintenance. A hand-written policy is a snapshot, and it goes stale the moment someone adds a new integration. If you take this route, put a recurring review in the client's calendar and make it explicit in your handover notes that updating the policy is their ongoing obligation.

Option 3: a paid generator

Paid services answer a questionnaire about the site and produce a policy, then update the wording as laws change. That update service, rather than the initial document, is what you are really buying. For an agency maintaining many sites, having policies tracked centrally and revised without your involvement can be worth a subscription.

There are several established options in this category, including Complianz, iubenda and Termly. Complianz and iubenda both publish actively maintained plugins on WordPress.org if you prefer to manage things from the dashboard; Termly is a hosted service rather than a plugin. We are not recommending one over another here: the right choice depends on the jurisdictions your clients operate in, how many sites you manage, and whether you want cookie consent bundled in.

Two things to check before you commit to any of them. First, who is responsible if the generated policy is wrong, which is usually the client rather than the vendor. Second, what happens to the policy if the subscription lapses, because some services stop serving the page entirely.

Rolling this out across many client sites

The hard part of this job is not producing one policy. It is keeping dozens honest. A workflow that survives contact with reality:

• Keep an inventory of every site you maintain and what each one collects. A spreadsheet is fine.
• Standardise your stack. The fewer distinct analytics, form and email tools across your client base, the fewer disclosure variations to track.
• Add the policy to your launch checklist, alongside the page being linked in the footer and set under Settings, then Privacy.
• Review on a schedule, and always after adding an integration.
• Put ownership in writing. Your contract should say who maintains the policy after handover.

Privacy policies are one of several legal pages worth getting right: our overview of legal issues bloggers need to be aware of covers the wider picture, and if a client site earns from recommendations it also needs a proper affiliate disclosure.

The short version

Start with what WordPress gives you free, because the built-in privacy guide tells you what the site genuinely does. Write the policy yourself if you can keep it current. Pay for a generator when the number of sites makes manual upkeep unrealistic, and buy it for the ongoing updates rather than the first draft. Whichever route you take, make sure the client understands the policy describes their site today and has to change when their site does.