How to Track Dealer Locations Across Multiple Automotive Websites
Build a reliable record of dealership locations across websites, resolve mismatches, and understand how Google matches locations for vehicle listings and ads.
Track each physical dealership as its own record, with a stable internal location ID, source-specific values, the URL where each value appeared, and the date you observed it. Compare normalized addresses and phone numbers to find likely changes, then review conflicts before updating your canonical record. If Google vehicle listings or vehicle ads are in scope, map your internal ID to Google’s store code and retain the Google Place ID or Maps URL when available.
This is a practical workflow recommendation, not a Google requirement or a field-tested method. Google’s matching rules apply to its own products; other automotive websites may use different data and matching requirements.
1. Define what counts as a dealer location
Create one canonical record for each real physical dealership location. A dealer group with several rooftops should have several records, even if the locations share a brand, phone system, or corporate website.
Keep departments such as sales, service, and parts together when they refer to the same location and your operational needs treat them as one location. Keep them separate only when they have genuinely distinct location records or operational requirements. The Google material summarized here does not establish a general policy for department profiles.
Assign an internal ID that does not change when a location’s name, address, or website changes. Do not use a name or address as the ID: both may be edited, and similar names can refer to different rooftops.
2. Choose fields and retain source evidence
For each location, retain a canonical value and the values observed on each source site. Keeping the source observations lets you compare sites without losing what they actually published.
| Field | What to keep |
|---|---|
| Internal location ID | A stable key chosen by your organization. |
| Presented name | The dealership name as shown on the source page, plus a reviewed canonical name if you maintain one. |
| Address | The complete address, including suite or unit and country where supplied; keep raw and normalized forms. |
| Phone | The displayed phone number and a normalized comparison value. |
| Website | The dealership website URL shown or linked from the source. |
| Source URL | The exact page where you observed the location information. |
| Observed at | The date and time the source page was checked. |
| Google identifier, if relevant | Google store code, Place ID, or Maps URL as applicable to your Google workflow. |
| Change record | Prior value, new value, source, observation time, and review or approval status. |
Keep punctuation and address components in the raw value. For comparisons, normalize whitespace, phone formatting, and address abbreviations in separate fields. Normalization helps flag possible matches; it should not silently erase suite numbers, countries, or meaningful differences.
3. Collect location data from each website
- List the dealer group, OEM, aggregator, and other automotive websites that are in scope.
- Find each site’s location or dealer pages and record the page URL alongside every observation.
- Capture the displayed name, full address, phone, and website. Record missing fields as missing rather than filling them from another site without provenance.
- Save the observation timestamp. A later check should create a new observation or change event instead of overwriting the old evidence.
- Review likely duplicates and changes before updating the canonical record.
For a small set of pages, a reviewed spreadsheet may be sufficient. For recurring work across many pages, consider a data-management system only after confirming it supports the source coverage and evidence retention you need. Compare monitoring coverage, change history, duplicate resolution, source retention, and export options. The available research does not verify a particular vendor or arbitrary-site monitoring capability.
Use screenshots as supporting evidence
A screenshot can preserve what a location page looked like at collection time, which can help a reviewer understand a disputed or changed value. It does not replace structured fields, source URLs, timestamps, or a review trail.
For an automated capture, use a screenshot API or browser automation to capture the location page and retain the resulting file with the observation record. ScreenshotNeo is a website screenshot API and MCP server for developers. Its clean-shot options can accept consent banners and remove known consent platforms, newsletter popups, and chat widgets before capture. See the ScreenshotNeo site and API documentation.
4. Compare records and review conflicts
- Match records first by stable identifiers you already trust. If none exist, use several fields together, such as name, full address, phone, and website.
- Use normalized address and phone values to flag likely matches or changes.
- Do not merge records based only on similar names. Two locations can share a brand or street name.
- When sources disagree, preserve both observations and send the conflict for review. Record which source supports the canonical value and why it was selected.
- Log accepted changes with the prior value, replacement value, source URL, observation date, and reviewer or status.
This reconciliation process is an editorial workflow recommendation inferred from the need to match location records. Google does not prescribe this cross-site tracking method.
5. Apply Google’s location requirements only where relevant
Google’s vehicle listing feeds and vehicle ads have their own matching processes. They should not be treated as rules for every automotive site.
Google vehicle listing feeds
Google’s vehicle listing guidance uses a store code, dealership name, and postal address for matching, and strongly recommends a Place ID or Maps URL to identify the Business Profile more precisely. The onboarding guidance describes both feed files and website structured data. It says structured data is easier to implement and maintain, while Google may take longer to detect website changes; feed uploads support richer detail and dedicated support but may require development to create and maintain. The guide says multiple dealerships can be included in one feed and partitioned by dealership. See Google’s vehicle listings onboarding guidance.
Google vehicle ads and store data
Google Ads Help says, “The most comprehensive means of providing your dealer locations is through linking your Google Business Profile account.” A store data source is an alternative. Google Ads store data requires store_code and store_address; store name, phone, and website URL are recommended. The address must be a full street address including country, and unique in the submitted data. See Google Ads Help on store data.
Google associates a vehicle with a dealership location through store_code matched to Business Profile or store-data location information. Advertisers that own their dealership listings can use linked Business Profiles; aggregators and OEMs that do not own the listings should use a store data source. Some multi-dealership setups use multi-client account structures. These are Google-specific instructions, not a general architecture prescription. See Google’s vehicle ads integration guidance.
Provider and eligibility caveats
Google’s provider guidance says a provider must be Google-approved and inventory must be successfully matched to the Business Profile before it can appear as a provider. If a dealer does not select a preferred provider, Google may choose based on data quality, including completeness and freshness. Check current program eligibility and supported geography before diagnosing a feed or match as defective. See Google’s vehicle listings guidance and vehicle ads integration guidance.
Google product rules, eligibility, and geography can change. Recheck the current documentation before relying on an older onboarding guide or feed configuration.
6. Capture a source page with ScreenshotNeo
After deciding which pages to monitor, you can save a screenshot alongside each observation. A URL request returns an image or PDF. This example requests a WebP capture of a sample dealer page; replace the URL with the source page you are tracking. Keep your API key in an environment variable or secret store in production.
curl -G "https://api.screenshotneo.com/v1/shot" \
-d access_key=YOUR_API_KEY \
--data-urlencode url=https://www.example.com/dealers \
-o dealer-location.webp
Use the ScreenshotNeo API docs for the supported request options and response headers. The endpoint supports PNG, JPEG, WebP, or PDF output, and the API response reports page verdict and billing status in headers.
Python
import os
import requests
api_key = os.environ["SCREENSHOTNEO_API_KEY"]
response = requests.get(
"https://api.screenshotneo.com/v1/shot",
params={
"access_key": api_key,
"url": "https://www.example.com/dealers",
},
timeout=90,
)
response.raise_for_status()
with open("dealer-location.webp", "wb") as image_file:
image_file.write(response.content)
Node.js
const apiKey = process.env.SCREENSHOTNEO_API_KEY;
const query = new URLSearchParams({
access_key: apiKey,
url: 'https://www.example.com/dealers',
});
const response = await fetch(`https://api.screenshotneo.com/v1/shot?${query}`);
if (!response.ok) {
throw new Error(`Screenshot request failed: ${response.status}`);
}
const image = Buffer.from(await response.arrayBuffer());
await import('node:fs/promises').then(fs =>
fs.writeFile('dealer-location.webp', image)
);
Associate the capture with the observation
Store the image under an internal location ID and observation timestamp, or store a durable object-storage reference in the record. Keep the page URL and extracted field values with it. Avoid treating a screenshot alone as proof that the address is current; it only documents what the page showed when captured.
7. Or skip the browser setup
ScreenshotNeo takes a screenshot with one GET request. This example captures a dealer page as WebP:
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://www.example.com/dealers -o dealer-location.webp
ScreenshotNeo removes cookie banners, popups, and chat widgets before the shot. Bot checks, blank pages, and failed loads are never billed. An MCP server lets AI agents use the take_screenshot, get_page_info, and capture_pdf tools. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots. Only clean shots are billed, and responses identify page verdict and billing status. Every feature is on every plan. Read the ScreenshotNeo docs and sign up for 1,000 free screenshots a month with no card.
8. Reliability, performance, and cost
- Reliability: Keep source URLs and observation times so a missing page or failed capture is distinguishable from a real change. Preserve prior records and review conflicts instead of overwriting evidence.
- Performance: Capture only pages needed for the tracking question. For large inventories, process URLs in batches and retain a result status per URL so an individual failure does not discard the rest of a run. ScreenshotNeo supports bulk capture of up to 100 URLs per call and asynchronous jobs with signed webhooks.
- Cost: ScreenshotNeo bills only clean shots; bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing. Its free plan is 1,000 shots per month; paid tiers are Starter $5 for 3,000, Growth $15 for 15,000, Pro $39 for 60,000, Scale $99 for 250,000, and Business $249 for 1,000,000. Yearly billing gives two months free. Confirm current pricing before adopting it.
- Evidence retention: Set an internal retention period for screenshots and raw observations that fits your review needs. The research does not establish a universal monitoring interval or retention policy.
9. Troubleshooting common tracking problems
| Symptom | Likely cause | What to do |
|---|---|---|
| Two rows appear to describe the same dealer | Different formatting, former names, or duplicated pages. | Compare full address, phone, website, and source context. Review before merging; do not rely on name similarity alone. |
| One location appears to have changed address | A source page may be stale, or a move may be in progress. | Keep both dated observations, check other source pages, and review which source should update the canonical record. |
| Google does not match a location | Store code, dealership name, address, or Business Profile information may not align; eligibility may also be an issue. | Check the Google-specific requirements, full address including country where required, Place ID or Maps URL, profile ownership, and program eligibility. |
| Google Ads store data is rejected | A required store_code or store_address may be absent, or the address may be incomplete or not unique in the submitted data. | Supply both required fields and validate that each address is a full, unique street address including country. |
| Screenshot shows a consent banner or popup | The page uses a consent or overlay mechanism that is not removed in the capture. | Review ScreenshotNeo’s clean-capture options and supported controls in the API docs; individual steps can be turned off. |
| Screenshot is blank or capture fails | The page may be blank, timed out, failed to load, or presented a bot check. | Check the source page and response verdict/billing headers, then retry according to your collection workflow. These outcomes are not billed by ScreenshotNeo. |
10. Checklist for a repeatable process
- There is one stable internal ID per physical dealer location.
- Every observation preserves the source URL and observation date.
- Raw values remain available next to normalized comparison values.
- Address components such as unit and country are retained.
- Potential duplicates and conflicts receive review before canonical updates.
- Google store codes and Place IDs or Maps URLs are maintained only where the relevant Google program uses them.
- Feed, structured data, and third-party site monitoring are treated as separate data workflows.
FAQ
How do I keep dealership addresses consistent across multiple websites?
Keep a dated observation from each source, compare normalized address fields, and route discrepancies for review before changing the canonical address. Retain unit and country information.
Does Google require every automotive website to use store_code?
No. Store code is part of Google’s own vehicle listing and ads workflows described above. The research does not establish a universal requirement for other automotive websites.
Should I use a feed or website structured data for Google vehicle listings?
Google describes both. Its onboarding material characterizes structured data as easier to implement and maintain, while feeds support richer detail and dedicated support but may need development. Google may detect website changes more slowly.
How often should locations be checked?
The cited research does not establish a universal update interval. Choose a cadence based on how quickly your team needs to detect changes and the number and importance of source pages, and record each check time.


