A correct cookie policy lists exactly which cookies the site uses, for what purpose, how long they last, who sets them (first or third party) and how a visitor withdraws consent. A template copied from another site is not compliant unless it reflects your real trackers — and it drifts from reality the moment you add a pixel or a chat widget. The safest option is a policy generated from a scan of your own site that updates automatically when your tracker stack changes.
What must a cookie policy contain?
A cookie policy is not filler text in the footer — it is the document through which you meet the duty to inform under GDPR and Romanian Law 506/2004 before the visitor gives consent. To be useful and correct, it has to cover every point in the table below:
| Required element | What it means concretely |
|---|---|
| Which cookies you use | The real list, by name (_ga, _fbp, the session cookie, etc.), not a vague "we use cookies". |
| The purpose of each | Strictly necessary, preferences, statistics or marketing — the category decides whether it needs consent. |
| Lifespan | How long each cookie stays: session, a few days, or months/years. |
| Who sets it | First party (your domain) or a third party (Google, Meta, a chat provider) — third parties raise the most questions. |
| How consent is withdrawn | A link or button that lets the visitor change their choice anytime, as easily as they accepted. |
| Contact details | The data controller and, where applicable, the data protection officer (DPO). |
If any row is missing, the information is incomplete — and incomplete information means that consent given on the basis of it is not truly "informed".
Why does a copied template drift from reality?
The most common way to get this wrong is to grab a template from another site and paste it onto yours. The problem is not the wording — it is that the cookie list belongs to someone else. Your policy says you use three analytics cookies, but your site also sets a Facebook pixel, a heatmap and two cookies from a YouTube embed. From that moment the document is lying, and a regulator or a visitor who compares the policy with the browser's Network tab spots the discrepancy immediately.
Worse, a policy written once is instantly out of date. Every time marketing adds a new tracker — a campaign, an A/B testing tool, an affiliate pixel — the static policy falls behind without anyone noticing. That is why a "set in stone" template is a hidden liability, not a fix.
First see what your site actually sets, with a free scan at /check — only then do you have the real list an honest policy is built from.
Policies generated from a scan, updated automatically
The alternative to a hand-written document that ages is a policy generated from a scan of your own site and hosted, one that updates when your tracker stack changes. The flow is simple:
- The site is scanned and every cookie and tracker that loads is identified, with category and provider.
- The policy is generated from the real list — with purpose, lifespan and who sets each cookie, filled in automatically from the glossary of 1,300+ documented cookies.
- It updates when a later scan finds something new, so the document never lags behind reality.
That way your policy describes what the site actually does, not what it did on the day you copied a template. FewCookies generates such policies from real scans and hosts them, so you are not left with a static file that quietly goes stale.
Why you need a bilingual policy (RO + EN)
A site in Romania primarily addresses a Romanian audience, so a cookie policy in Romanian is not optional — the information has to be in a language the visitor understands. If you also have international traffic (EU customers, tourists, buyers from abroad), you need an English version too, aligned to the same cookie list.
In practice, the two versions must say the same thing: the same cookies, the same purposes, the same durations — just in two languages. An auto-generated policy produces both versions from the same source, so you never risk the English version listing different cookies than the Romanian one. FewCookies generates bilingual Romanian/English policies for exactly this reason.
To start off right, run a free scan, check what your site sets, then see what a generated and hosted policy looks like on FewCookies. Your document should be a mirror of reality, not filler text.
Frequently asked questions
Can I use a free cookie policy generator?
You can, but only if the generator starts from a scan of your site, not from a generic questionnaire. A generator that cannot see which cookies you set produces plausible but mismatched text. The most useful option is a generator tied to a scan that fills in the real cookie list and updates it when you add new trackers.
How often should a cookie policy be updated?
Whenever the trackers on the site change — a new pixel, an analytics tool, a chat widget or an embed adds cookies that must be listed in the policy. With a hand-written document that means remembering every time; with a policy generated from scans, the update happens automatically when the scan finds something new.
Is a cookie policy the same as a privacy policy?
No. A privacy policy covers all processing of personal data, while a cookie policy specifically details which cookies and similar technologies you use, for what purpose and how consent is withdrawn. The two usually link to each other, but the cookie policy has to exist separately, with the concrete cookie list.
Want to see which cookies and trackers fire on your site before consent? The scan is free and needs no account. Check your site for free →