Keyword research UK GDPR: practical data safeguards

What should you map before using keyword data?

Keyword research UK GDPR planning starts with a register of the datasets involved, their purpose, source, access needs and intended deletion date. Doing this before collection helps the team see what is being used and why, rather than trying to reconstruct the decisions after analysis has begun.

Follow information from collection through export and analysis. Note which fields are added, who receives the files and whether separate records could be joined to identify someone. A data lineage check can help show how information moves and where identifiers enter the working dataset.

Record the intended use beside each dataset, and revisit it if the work changes. Keep the explanation practical enough for analysts to understand what the information is for and what use is out of scope. A planning template can keep the purpose and project tasks visible together.

When might a search record identify a person?

A keyword record may be personal data if it identifies someone directly or can be combined with other information to single them out. Aggregated volume estimates generally pose less identification risk than records associated with an account, device, IP address or email address.

Do not judge a file from its search-term column alone. Logged-in exports may connect queries to an account, while analytics can add device details or an IP address. Assess the source, identifiers and possible combinations across the whole dataset before treating any information as anonymous.

Searches can also reveal health, sexual orientation, religious belief or trade union membership. If that information can be linked to a person, special category data rules call for additional conditions. Health, finance and legal research can raise this concern, so remove identifiers early and note how the risk was assessed.

Under UK GDPR Article 9(2)(a), processing special category data may be permitted where the person has given explicit consent for one or more specified purposes. This is one possible condition, not a default for every project, so identify the condition that applies alongside the Article 6 lawful basis. The Information Commissioner’s Office (ICO), the UK’s data protection regulator, publishes guidance on special category data on its website; consult it when assessing the condition and safeguards.

The Data Protection Act 2018 supplements UK GDPR across the UK. Set out why personal information is collected, and do not retain identifiable records after that purpose has ended. The register should make the reason for collection and the limits on use clear to the people working with the data.

What information can be left out?

Collect only the information needed to answer the research question. Aggregated search volumes may be enough to assess interest in a topic cluster; individual query logs, device details and exact timestamps may not be needed to decide whether to create content.

Remove identifiers as early as practical. Depending on the task, a team can strip user IDs, shorten IP addresses, round timestamps to the month and exclude free-text fields that might contain names or contact details. These steps reduce personal information in working files while keeping analysis focused on its intended purpose.

Site search fields need particular care because a visitor might enter an email address, order number or postcode. Scrub entries before they reach a keyword spreadsheet. Pattern checks for email formats and long strings of digits can help remove such details before analysts begin reviewing the terms.

Customer-match lists share CRM information with an advertising platform, so assess the basis, transparency and contractual arrangements first. Keyword tools can differ: some provide aggregated estimates, while others may offer query-level exports associated with accounts. Check the role and processing terms of the particular service in use.

Which lawful basis fits the research?

Choose and record a lawful basis before processing begins. Consent, legitimate interests and contract may suit different keyword research tasks, but the right option depends on the information involved and what the team intends to do with it.

Consent may fit tracking, but people need a workable way to withdraw it, and the team must be able to locate and remove their records. For legitimate interests, document the purpose, why processing is needed and how it balances against people's rights and expectations.

A contract may cover research needed to deliver a paid SEO retainer or audit, but it does not automatically justify every connected activity. Record the selected basis and check it still fits as the work develops. If the basis changes during a project, make a fresh assessment and record the reason.

Public task and vital interests rarely suit commercial keyword work, while legal obligation may matter when responding to a regulatory request. Do not select a basis simply for convenience and then reshape the research around it. The UK rules for keyword research belong in the planning review.

When does tracking need consent?

Consent is needed when a tool uses cookies or similar technologies on your site, because the Privacy and Electronic Communications (EC Directive) Regulations 2003 (PECR) apply alongside UK GDPR. This can be true even if the information collected is not personal data. A service that supplies aggregated estimates without setting technology on your domain may be different.

A measurement cookie is not strictly necessary just because its results help the team. Explain tracking before it starts, offer a meaningful choice and let people change their decision later. A preselected choice, a difficult-to-find rejection option or a design that steers people towards acceptance can raise compliance concerns.

Before choosing a service, find out where it operates and what it gathers. Ask whether it sets cookies on your domain or the provider's, collects IP addresses, or enables cross-site tracking. Review the settings as well as the vendor's terms, and keep the wider compliance context in view when approving a tool.

For example, teams using Google Keyword Planner should assess the data and account settings in their own workflow; the tool name alone does not establish whether a particular use involves personal data or tracking.

What should be checked before an AI or provider receives data?

The team remains responsible for information submitted to an AI service and for decisions based on its results. Data protection requirements still apply when a service processes personal information, so check the actual inputs, outputs and service arrangements before use.

Sending customer queries, support tickets or CRM extracts to a third-party model shares that information with the service. Check what the provider does with inputs, whether they may be used for training and where processing takes place. Consider the provider's role and processing terms before sending information.

Review generated keyword lists before using them, particularly when a query could reveal health or financial circumstances. A model may reproduce personal data from its training material. Using AI does not transfer the team's responsibility for information submitted or decisions made from the output.

Practical safeguards include a no-training commitment for information that could identify someone, removing names and account numbers before prompting, logging submissions and checking outputs for personal data. Add prompt histories to the retention schedule and consider international transfers when reviewing provider locations. Keep the rules and ethics for keyword work in view.

How should identifiable records be retained and documented?

Set a retention period and deletion route for every dataset containing personal data. Do not keep identifiable records indefinitely; base the period on the research purpose rather than copying a timetable from an unrelated project.

Aggregated market information without identifiers may be kept for years, while raw site search logs with identifiers may need removal after a few months. Customer-match lists should follow the retention rule for the CRM records they came from. Note the deletion date and make sure someone is responsible for carrying it out.

Limit access to people who need it, protect information in storage and transit, and avoid copies on personal devices or unmanaged cloud accounts. Open spreadsheet links make it harder to know who has viewed information. Named accounts and audit logs give the team a clearer view of access.

Writers may need a brief and topic cluster, analysts may need an export, and account managers may need only a summary. Assign an owner and diarise deletion. A data protection workflow and quality checklist can help keep responsibilities visible.

Review the register at the start of each quarter, and treat a new tool as a change that needs approval. Compare the task with suitable keyword research tools and sources, then ensure the register describes how the selected service is actually being used.

What should we do first?

Begin with the datasets, not the tool shortlist: identify information that could single someone out, then record the purpose, lawful basis and minimum fields needed. Before collection starts, decide who needs access, how long records will remain and how deletion will happen when the research purpose ends.