How to Import Leads into HubSpot from a CSV (UK Field Mapping)

HubSpot's importer is forgiving, which is the problem. It will accept an unprepared file, create several thousand records, and only reveal what it did wrong once the data is live and entangled with everything else.

The work that matters happens before you open HubSpot. Here's the sequence that avoids a cleanup job.

Decide What You're Importing First

HubSpot separates contacts from companies. A contact is a person. A company is an organisation. They're different objects with different properties, and getting this wrong is the most common structural mistake.

A scraped local business list is usually company data — a business name, a website, a phone number, a generic info@ address. That's a company record, not a contact. Importing it as contacts gives you a contact list where the first name field contains "Bright Smile Dental Practice", which breaks every personalisation token you'll ever use.

If you have named individuals with their own email addresses, you want both objects, imported together so HubSpot associates them. The importer supports a multi-file import for exactly this: one file of companies, one of contacts, joined on a shared column.

For most Google Maps sourced lists, import companies. Add contacts later, when you know who you're actually speaking to.

Prepare the File Before You Open HubSpot

Five things, all of which are much harder to fix after import than before.

Phone numbers should be in E.164 — +441132496000, not 0113 249 6000. HubSpot's phone validation is far more reliable with a country code present, and its calling and SMS integrations require it outright. The E.164 formatting guide covers the conversion.

Websites should be normalised and stripped of tracking parameters. HubSpot derives a company's domain from this field, and it's the primary key it uses for deduplication. A URL with utm_source hanging off it produces a different domain match than the clean version.

Empty cells should be genuinely empty, not "N/A" or "null". HubSpot will happily store the literal text and it will appear in your emails.

Headers should be short, unique, and free of trailing spaces. A trailing space is invisible and will stop a column mapping to the property you expect.

And the file should be deduplicated before import, not after. HubSpot's own deduplication is domain and email based, so two rows for the same business with slightly different names and no shared domain arrive as two companies. Deduplicating properly is worth doing first.

The Fields That Actually Matter

For companies, the ones that carry weight are Company name, Company domain name, Phone number, City, Postal code, and Country.

Company domain name is the important one. It's the property HubSpot deduplicates company records on by default, which makes it the closest thing a company record has to a primary key. A company record without a domain is a second-class record. If a business genuinely has no website, consider whether it belongs in your CRM at all.

Country is worth setting explicitly to United Kingdom rather than leaving it blank. HubSpot infers less than you'd hope, and an empty country field degrades phone validation and any geographic reporting later.

Mapping UK-Specific Fields

HubSpot's default properties are American. Postal code is your postcode — map it there rather than creating a custom "Postcode" property, or you'll be maintaining two fields that mean the same thing forever.

State/Region has no clean UK equivalent. County is the closest but is inconsistently used and frequently absent from scraped data. Leave it unmapped rather than stuffing the city in there.

If you're working by area, a custom property for the outward code — the LS1 part of LS1 4AP — is genuinely useful for territory filtering, and it's a better place for that logic than abusing State/Region.

Let HubSpot Handle Duplicates, But Understand How

HubSpot deduplicates contacts on email address and companies on domain name — the secondary domain values as well as the primary, not just the one you'd expect. A row that matches an existing record updates it rather than creating a second one, which is usually what you want.

There are two documented ways to override that. Record ID, HubSpot's own internal identifier, takes precedence over every other mapped identifier if you include it — useful when you're updating records you previously exported from HubSpot, irrelevant for a fresh scrape. And you can mark a custom property as requiring unique values and have the import deduplicate on that instead, which is the escape hatch when your records genuinely have no domain or email.

The trap is the case with no key at all. Two rows for the same business where neither has a domain import as two companies, because there's nothing to match on. That's exactly what your pre-import deduplication has to catch, and it's the most common case in scraped local business data — plenty of small businesses have a Google listing and a phone number but no website at all.

Test With Ten Rows

Cut the first ten rows into a separate file and import that. Check the results in HubSpot: are the phone numbers formatted, did the postcodes land in Postal Code, are the company names clean, did anything land in a property you didn't intend?

Ten records are trivial to delete. Three thousand are not. This single step catches nearly every mapping mistake, and it takes two minutes.

Exporting a HubSpot-Ready File

LeadSnipe exports with a HubSpot preset that names the columns to match HubSpot's properties and applies the formatting above — E.164 phones, normalised domains, a consistent empty-cell rule, and deduplication — so the mapping step is mostly confirming what it already guessed. There's a Pipedrive equivalent if that's your CRM, and the clean CSV checklist if you're preparing a file by hand.