GDPR for Spanish Business Websites: What You Actually Need

You launch your website, add a contact form, embed Google Maps, install Analytics, and move on. Then someone asks: “Is this GDPR compliant?” That is the moment most business owners in Spain realise they do not actually know.

Here is the practical answer: if your website collects personal data, uses non-essential cookies, or tracks visitors in any way, you need to handle that properly. That usually means a real privacy policy, a proper cookie consent setup, and clear rules around your contact forms. We have audited plenty of business websites across Almería, Murcia, Alicante, and Granada, and the same problems come up again and again: banners that do not block cookies, forms with no data notice, and copy-paste policies that do not match the site.

What GDPR actually means for a small business website in Spain

If you run a business website in Spain, GDPR is only part of the picture. You also need to think about Spain’s own rules around cookies and electronic communications, plus the guidance issued by the AEPD.

In practical terms, your website usually needs to do three things well:

1. Tell people what data you collect and why
2. Only collect what you need, in a lawful way
3. Give visitors real control over tracking and marketing

That sounds bigger than it is. For most SMEs, holiday rental businesses, restaurants, estate agents, lawyers, trades, and expat-run service businesses, the issues are usually concentrated in a few places:

• cookie banners
• analytics tools
• contact forms
• newsletter forms
• embedded third-party content
• privacy and cookie policies

If your site has those elements, GDPR matters. If your site is bilingual, the information also needs to be clear in both languages. This is one reason we build bilingual websites natively in English and Spanish, with the legal structure and hreflang setup planned from the start rather than translated later. A rushed site often creates compliance problems before SEO or conversions even enter the conversation.

Next step: make a simple list of every place your website collects, stores, or shares visitor data. That list is the foundation of everything else.

Start with the biggest risk: cookie consent

The part most business owners get wrong is not the privacy policy. It is the cookie banner.

A compliant cookie setup in Spain is not just a pop-up with an “OK” button. The AEPD has been clear for years: if you use non-essential cookies, users need a real choice before those cookies are set. That means:

• no pre-ticked boxes
• no implied consent from scrolling or continuing to browse
• no loading analytics or ad cookies before consent
• a clear option to reject as well as accept
• access to more detailed cookie information

What counts as a non-essential cookie?

Usually:

• Google Analytics
• Meta Pixel
• Google Ads tracking
• Hotjar and similar behavioural tools
• YouTube embeds that drop tracking cookies
• some booking widgets, chat tools, and map embeds

Strictly necessary cookies are different. If a cookie is essential for the site to function, such as a basic session cookie for a secure login area, it may not require the same consent. But many marketing and analytics scripts absolutely do.

What a good cookie banner should include

A usable, compliant banner should offer:

• Accept
• Reject
• Preferences / customise
• a link to your cookie policy
• language that clearly explains what categories exist

The design matters too. A lot of cheap templates make “accept” bright and obvious while hiding “reject” in tiny text. That is not a smart direction. The choice must be real, and the reject option should not be treated like a hidden extra.

Why this matters beyond compliance

A bad cookie setup is also bad UX. It slows the site, creates clutter, and damages trust. On our own builds, we usually reduce the problem before the banner even appears by stripping out unnecessary scripts, lazy-loading heavy embeds, and only enabling non-essential tools after consent. Because we build pre-rendered HTML sites in Astro and serve them on Cloudflare’s edge network, our websites consistently hit 100/100 Lighthouse scores and load in under 0.4 seconds FCP. That performance-first approach helps with compliance too: fewer third-party tools means fewer consent and data-sharing headaches.

If website speed is already a concern, our posts on why your website speed matters in Spain and how to pass Core Web Vitals explain why fewer scripts usually means better rankings and better conversions as well.

If you do one thing today: open your site in an incognito window, accept nothing, and check whether Analytics, ad pixels, YouTube, Maps, or chat tools still load anyway.

Your privacy policy: what it should actually say

A privacy policy is not there to impress anyone. It exists to tell visitors, in plain language, what happens to their personal data.

For a typical small business website in Spain, your privacy policy should cover:

1. Who is responsible for the data

Include the business identity clearly:

• business name
• tax or company identification where appropriate
• address
• contact email
• data controller details

2. What data you collect

Be specific. Typical examples include:

• name
• email address
• phone number
• IP address
• booking or enquiry details
• billing details if applicable

Do not list data you do not actually collect. This is where a lot of template policies fail.

3. Why you collect it

You need to explain the purpose, such as:

• replying to contact enquiries
• managing bookings
• providing quotes
• sending service information
• processing payments
• sending marketing emails, if consent has been given

4. Your legal basis

This is the part many businesses skip, but it matters. Depending on the situation, your lawful basis may include:

• consent
• contract
• legal obligation
• legitimate interest

For example, if someone fills in your quote form, you may process that data to respond to their request. If they subscribe to a newsletter, consent is likely the main basis.

5. Who you share the data with

If you use third-party providers, say so. That may include:

• email providers
• CRM systems
• booking tools
• payment processors
• analytics providers
• cloud hosting or infrastructure services

Again, accuracy matters. We often see websites using tools that are not mentioned anywhere in the policy.

6. How long you keep the data

You do not need a novel here. You do need a sensible retention explanation. For example: enquiry data may be kept for a set period to manage client communications and legal obligations.

7. User rights

Visitors should be told they can exercise rights such as access, rectification, deletion, restriction, objection, and portability where applicable. You should also mention their right to complain to the AEPD.

8. How to contact you about data protection

Make this easy. If people cannot work out who to email, the policy is not doing its job.

If your website is bilingual, do not leave the English page current and the Spanish page vague, or vice versa. We build legal and consent content into both language versions from the start so users are not getting materially different explanations depending on where they land.

Next step: open your current privacy policy and compare it line by line with the actual tools installed on your site. Most gaps become obvious in 10 minutes.

Contact forms: the small detail that causes big problems

A basic contact form feels harmless. Name, email, message, done. But from a GDPR point of view, that form is collecting personal data. You need to handle it properly.

What your form should include

At minimum, your form should make it clear:

• who is collecting the data
• why you are collecting it
• what you will do with it
• where the user can read more
• whether the data will be used only to respond to the enquiry or also for marketing

A simple short notice under the form usually works, with a link to the full privacy policy.

Do you need a checkbox?

Often, yes — but not always for the same reason people think.

If the form is purely for replying to an enquiry, you may not need a consent checkbox just to process the message itself, provided the legal basis is clear and the notice explains it properly. But if you also want to add that person to a newsletter or marketing list, that is different. Then you need separate, explicit consent.

What you should not do is bundle everything together. Someone asking for a quote from your restaurant, law firm, or holiday rental should not be silently added to promotional mailings.

Keep your forms lean

Only ask for what you need. If a contact form needs name, email, and message, do not also ask for date of birth, full address, and passport number. Data minimisation is part of good compliance and good conversion practice.

We design forms this way on all our web design services projects because a form should do two jobs at once: convert the visitor and protect the business.

Think about where form submissions go

A lot of owners focus on the form itself and forget what happens next. Ask yourself:

• Are submissions emailed to a Gmail inbox shared by three staff members?
• Are they stored inside a CRM?
• Are they sent to WhatsApp?
• Are they forwarded through an automation workflow?
• Do you delete them after use?

These questions matter. If you are using automations, they need to be configured properly too. At CostaDelClicks, our business automation work often includes form routing, lead capture, CRM syncing, and notifications via self-hosted n8n or Make.com. Zapier can work for a simple one-step task, but at scale we usually avoid it because costs climb quickly and the data flow often becomes harder to manage. For a holiday rental business, a clean enquiry-to-confirmation workflow can save 3 to 5 hours a week, but only if the handling of personal data is documented properly from the start.

Before you change the form design, trace exactly where each submission goes after the user clicks send. That is usually where the real compliance risk sits.

Embedded tools, maps, videos, and chat widgets

Here is where many otherwise tidy websites become messy.

Your site may look simple, but behind the scenes it might be loading:

• Google Maps
• YouTube videos
• Meta Pixel
• reCAPTCHA
• WhatsApp widgets
• Calendly
• booking systems
• review plugins
• live chat tools

Each of those can affect privacy, cookies, data sharing, or consent.

Common trouble spots

Google Maps embeds

Useful, but they may involve data transfers and tracking. If you embed them directly, review whether consent is needed first. In many cases, a simple click-to-open map link is cleaner and lighter.

YouTube videos

Standard embeds can place cookies before the user agrees. Privacy-enhanced mode helps, but it is not a magic fix for every setup. Sometimes the better answer is to use a preview image and load the video only after user interaction.

Chat widgets

Many live chat systems collect personal data and load third-party scripts immediately. If you do not need them, do not add them. A well-built contact form often does the job with far less risk and less clutter.

reCAPTCHA

Spam protection is important, but reCAPTCHA introduces Google’s infrastructure into the process. You should account for that in your privacy information and review whether a lighter alternative would suit your site better.

This is one reason static sites are such a strong option for SMEs. They reduce plugin bloat, limit unnecessary scripts, and simplify the compliance surface area. Plugin-heavy WordPress sites can absolutely be made compliant, but they bring extra maintenance overhead, plugin security risk, and performance challenges that many small businesses underestimate. We build in Astro for exactly that reason: fewer moving parts, cleaner output, and far less mystery when you need to audit what the site is doing. If you are weighing approaches, our guide on static sites vs WordPress explains why fewer moving parts usually means fewer headaches.

Next step: review every embedded tool on your site and ask a blunt question — does this genuinely help the business, or is it just there because the template included it?

A practical GDPR checklist for your Spanish business website

If you want the plain-English version, use this checklist.

Your website probably needs these pages and controls

• A privacy policy that matches the real site
• A cookie policy that explains categories, durations, and third-party services
• A cookie banner that blocks non-essential cookies until consent
• A clear legal notice if applicable to your business structure and local obligations
• Form notices and consent wording where required

Your forms should do these things

• explain why data is collected
• link to the privacy policy
• separate enquiry handling from marketing consent
• collect only necessary fields
• send data to approved systems only

Your tracking setup should do these things

• avoid loading analytics before consent
• avoid hidden ad pixels
• review embedded third-party tools
• let users change or withdraw consent later

Your internal process should do these things

• know who receives website enquiries
• know where the data is stored
• know how long it is retained
• know how to respond if someone asks for access or deletion
• know who updates the policy when the website changes

That last point matters more than most people realise. A website is not compliant once and forever. If you add a new booking engine, Meta campaign, CRM, chatbot, or automation, your data handling changes. The documents and controls need to keep up.

Key insight: if you cannot explain your website’s data flow clearly in five minutes, the setup is probably more complicated than it needs to be.

What the AEPD expects you to take seriously

The AEPD — Agencia Española de Protección de Datos — is Spain’s data protection authority. If you operate in Spain, its guidance matters.

You do not need to become a legal specialist, but you should know this:

• Spain takes cookie consent seriously
• design tricks that push users toward “accept” are risky
• vague, generic legal text is not enough
• businesses should be able to explain what data they collect and why

If you run an expat-facing business with English-speaking clients and Spanish-speaking suppliers, the clarity of your website matters even more. We often recommend making key privacy and consent information available in both English and Spanish, especially on bilingual sites. If your audience spans both markets, that is not just good service. It is sensible risk reduction.

For businesses building or rebuilding their digital presence, our posts on building a digital presence as an expat in Spain and should your website be bilingual? are worth reading next.

Treat AEPD guidance as your benchmark, not as optional reading after launch. It is much easier to build around those expectations than to retrofit them later.

The mistakes we see most often on local business websites

After reviewing websites for businesses across Almería and beyond, these are the repeat offenders:

1. “Accept cookies” banners that do not reject or customise

This is still everywhere.

2. Analytics loading before consent

The banner appears, but the tracking has already started.

3. Privacy policies copied from another site

Wrong business name, wrong tools, wrong legal basis.

4. Contact forms with no data notice

Visitors submit personal data with no explanation of what happens next.

5. Mailing list consent bundled into general contact

That is not clean consent.

6. Embedded third-party tools not mentioned anywhere

Maps, videos, booking widgets, and chat plugins often get forgotten.

7. Spanish version updated, English version outdated

On bilingual sites, consistency matters. If the legal page exists in one language only, or the wording differs materially, that creates confusion. When we build English and Spanish sites, the legal pages are planned in both languages from day one, and the hreflang structure makes sure users and search engines reach the correct version.

This is exactly why we prefer clean, custom builds over bloated theme-based websites. The more plugins and third-party add-ons a site relies on, the easier it is to lose track of what data is being processed.

Fix the first three items on this list and most SME websites are already in a much safer position.

What to do next if you want to fix this properly

Do not start by downloading another legal template and hoping for the best. Start by mapping your actual website.

Make a list of:

• every form on the site
• every analytics or ad platform installed
• every embed or widget
• every place personal data is stored or forwarded
• every page where privacy or consent information appears

Then review whether your website:

• blocks non-essential cookies before consent
• explains data handling clearly
• uses forms responsibly
• reflects the real tools you use
• gives users a way to manage consent

If you are rebuilding the site anyway, fix this at build stage. It is much easier to create a compliant structure from day one than to patch a messy one later. That is how we approach web design Almería projects and wider work across Murcia, Alicante, and Granada: speed, clarity, bilingual structure, forms, and compliance are planned together from the first wireframe. In practice, that usually means a lighter stack, fewer third-party scripts, cleaner policies, and a website that is easier for your team to manage after launch.

Start with an audit of what exists today, then rebuild only what the business genuinely needs.

FAQ

If you are still unsure which of these rules apply to your site, start with the basics: audit your forms, cookies, embedded tools, and privacy pages before you touch anything else.