How to scrape conference exhibitor lists accurately

To scrape conference exhibitor lists reliably, first map how the public directory works, define an event-specific schema, build one record for each exhibitor listing, follow profile links for additional fields, and make sure every page or dynamically loaded result is covered. Only automate the sitemap after a limited test produces a complete, correctly structured export.

The difficult part is rarely extracting a company name. It is preserving the relationship between the exhibitor, its booth, categories, profile, and event edition without missing records or deleting legitimate duplicates.

Decide what the exhibitor dataset should represent

A conference exhibitor list is not simply a generic company directory. It records participation in a particular event edition. That distinction matters when the same company attends several events, returns the following year, appears under more than one brand, or occupies multiple stands.

Before creating selectors, define the business question. Common examples include:

• preparing target-account research before a trade show;
• mapping suppliers or competitors within an industry;
• comparing the exhibitor mix between event editions;
• tracking new, removed, or changed exhibitors as an event approaches; and
• building an event-intelligence dataset for internal analysis.

This guide focuses on exhibitor information available on public event websites. Private attendee databases, networking apps, LinkedIn, social platforms, and large behind-login projects require a different access and compliance assessment.

Inspect the exhibitor directory before building the scraper

Open the directory in a normal browser and identify how a person would reach every exhibitor. Event websites commonly combine several patterns.

Directory pattern	What to inspect	Suitable sitemap approach
One complete list	Whether all cards are present in the page	One repeated Element selector
List and profile pages	Which fields appear on cards and which require opening a profile	Repeated Element plus a child Link selector
Numbered pages or Next button	Whether the URL or page content changes	Pagination selector
Load more button	Whether each click adds new cards and eventually stops	Pagination selector for the control
Infinite scroll	Whether more cards appear only after scrolling	Scrolling on the repeated Element selector
A-Z or category filters	Whether there is a complete view and whether filters overlap	Prefer a complete view; otherwise use stable filter URLs and record their context
Modal or AJAX profile	Whether clicking changes the URL	Test an interaction selector rather than assuming a normal link exists

Check early and late cards, several profile layouts, and an exhibitor with missing fields. Note whether sponsored exhibitors are repeated and whether company links use redirects. Visible totals and filter counts are useful validation clues, but categories can overlap and one company can have several listings.

Some directories place the full list in the returned HTML. Others render results with JavaScript after the initial page load. This affects the Cloud driver choice later. Fast works from the returned HTML, while FullJS runs a browser environment for JavaScript and interaction-dependent sitemaps. Use the simplest driver that reproduces the tested directory correctly.

Define an event-aware schema

Choose the output columns before selecting elements. This prevents the sitemap from becoming a collection of whatever happened to be easy to click.

Field	Why it belongs in the dataset
event_id	Keeps one event edition separate from another
event_name and event_year or event_dates	Makes the participation context explicit
exhibitor_name_raw	Preserves the organiser's source value
exhibitor_profile_url	Provides provenance and often a strong source-level key
source_exhibitor_id	Preserves a platform identifier when one actually exists
booth_raw	Retains stand, booth, or hall formatting, including multiple values
categories_raw	Preserves the organiser's one-to-many categories or show sections
country_raw and address_raw	Captures published location evidence without premature restructuring
description	Stores the exhibitor-provided event profile text
website_url	Captures the published company destination
filter_value or discovery_path	Explains which filter or A-Z route produced the record
source_url	Allows a reviewer to trace the row back to the event website
scraped_at	Turns recurring runs into dated observations

Keep raw and normalised values separately. For example, retain booth_raw = "Stand: C37+C38" even if downstream processing also creates hall and booth columns. The same principle applies to company names, addresses, categories, and URLs.

Fixed values such as event name and edition do not need to be extracted from every card. They can be added consistently after collection. The scrape timestamp can be added with Parser or in the downstream pipeline.

Do not assume that every profile has an email or phone number. Some event pages publish only a contact form. A form URL can be recorded if it serves the use case, but it is not an extracted email address.

How to scrape a conference exhibitor list step by step

Create and test the sitemap in the Web Scraper browser extension. For a typical paginated directory with separate profiles, the listing and detail-page workflow looks like this:

_root
└── pagination
    └── exhibitor (Element, Multiple)
        ├── exhibitor_name
        ├── booth_raw
        ├── country_raw
        └── profile_link (Link)
            ├── description
            ├── categories_raw
            ├── address_raw
            └── website_url

If the directory has no pagination, omit that level. The exact CSS selectors are site-specific, so the structure can be reused as a model even though the selectors cannot be copied unchanged between event websites.

1. Choose a stable start URL

Use the narrowest public URL that contains the complete target directory. An “all exhibitors” URL is normally better than the event homepage or a broad site search. Use separate start URLs only when they are necessary for coverage and their overlap can be measured.

2. Create one wrapper for each exhibitor

Add an Element selector around the smallest repeated card or row that contains one exhibitor's name, booth, categories, and profile link. Enable multiple records, then place the list-level fields beneath that Element.

The repeated Element is the record boundary. If several multi-value selectors sit beside one another without a shared wrapper, their matches are processed independently. That can produce plausible-looking rows with the wrong booth or category attached to a company.

3. Extract the listing-page fields

Add selectors for values already visible on each card, such as exhibitor name, booth, country, sponsor label, or profile URL. Use descriptive selector names because they become output columns.

4. Collect fields from the exhibitor profile

Add a Link selector for the exhibitor profile beneath the repeated Element, then add profile-level fields beneath that Link selector. A Link selector with child selectors follows the destination and runs those selectors there. Simply extracting the URL does not make profile fields execute on the destination page.

If clicking a company opens an AJAX modal without changing the URL, the interaction must be modelled and tested differently. Do not assume a normal Link selector can follow a destination that does not exist.

The Advanced Sitemap Builder can help generate listing and single-item selectors. Inspect the result and preview different profile layouts before relying on it.

5. Cover pagination, load more, or infinite scrolling

The sitemap must reproduce the mechanism that reveals additional exhibitors.

• Numbered pages, Next, or arrow controls: add a Pagination selector and place the exhibitor Element below it. When both numbered links and a Next control work, the Next control is generally the more stable target.
• Load more: select the control with a Pagination selector. Confirm that each click adds records and execution stops when the button disappears or no new cards appear.
• Infinite scroll: enable scrolling on the repeated exhibitor Element. Run a limited test that proves later records, not only the first viewport, are extracted.
• Pagination plus scrolling: put the scrolling exhibitor Element below Pagination so the scroll behaviour runs again on every page.

The complete setup is covered in the guide to pagination, load more, and infinite scrolling. Test a later page and the end condition because a control can behave differently after the page state changes.

Finally, preview several cards and profiles, then run a limited job and inspect the exported records before increasing the scope.

Use filters without creating a duplicate factory

Filters help visitors browse, but they can make extraction less reliable if every combination becomes a separate crawl path.

Use this order of preference:

1. A verified “all exhibitors” view that exposes the complete list.
2. Stable A-Z or category URLs when the complete view is capped or does not exist.
3. Interactive filter actions only when the directory provides no stable, complete route.

Do not assume that category totals add up to the number of unique exhibitors. One company can belong to several product categories, show sections, or countries of operation. A-Z navigation can also have a separate 0-9 page, while category navigation may omit uncategorised exhibitors.

When multiple filters are necessary, capture the filter value or discovery path in every row. That makes duplication explainable and allows event-aware deduplication after extraction. Avoid running every country-category-letter combination unless testing shows that those combinations reveal otherwise inaccessible records.

Validate the dataset, not just the job

A completed scraping job confirms that execution ended. It does not prove that the dataset is complete or correctly structured.

Use Element Preview and Data Preview, then run a limited scrape. Include later pages, varied profile layouts, missing fields, multiple booths, and content loaded by interaction.

Inspect the actual export and calculate a few basic checks:

Check	What it can reveal
Extracted rows versus visible directory total	Missing navigation or duplicate participation records
Unique profile URLs or source IDs	Repeated filter paths and true source-level duplicates
Empty company-name rate	Broken record wrapper or selector
Website, booth, and category fill rates	Profile-layout variation or stopped selectors
Duplicate company names with different booths	Legitimate multiple participation or records needing review
Records by A-Z page or filter	A missed branch or unexpectedly overlapping filters

If a directory reports 1,200 exhibitors but the export contains 1,050 unique profile URLs, investigate the difference before using the data. A page may have been missed, one pavilion may be excluded, promoted records may be counted twice, or some exhibitors may not have normal profile links. The objective is to explain the discrepancy, not force the output to match an unverified total.

After establishing a normal baseline, Web Scraper Cloud data quality control can monitor minimum record count, failed or empty pages, and required field fulfilment. Allow for normal event-list changes rather than copying one run as an unrealistically rigid threshold.

Common exhibitor-directory scraping problems

Symptom	Likely cause	What to check
Only the first group is extracted	Pagination, load more, or scrolling is missing	Confirm the loading behaviour and test the control on later pages
Company and booth values are mismatched	Fields are independent multi-value selectors	Put both fields beneath one repeated exhibitor Element
Detail fields are blank	Detail selectors are outside the Link selector, or the profile opens as a modal	Inspect the selector tree and test several profile layouts
Companies appear more than once	Sponsored placement, overlapping filters, or legitimate multiple booths	Compare source IDs, profile URLs, booths, and event context before merging
The page loads but returns no records	The job received different content, or expected JavaScript content did not load	Compare the job state with the expected directory and follow the 200 OK but no data diagnostic

If the directory blocks or limits collection, reduce unnecessary requests, use reasonable intervals, and test a small sample. Proxies and retries can help with some technical failures, but they do not guarantee compatibility or establish permission. If the source is unsuitable or permission is unclear, use an authorised export, an organiser-provided list, or another approved source.

Normalise and deduplicate without deleting real participation

An exhibitor name is a weak unique key. Differences in punctuation, legal suffixes, and spacing can create apparent duplicates, while identical names can refer to separate booths, brands, or event profiles.

A durable model separates three concepts:

• Exhibitor entity: the company or organisation, with its accepted name and domain.
• Event participation: the event edition, source profile, booth, hall, and event-specific categories.
• Observation: what the source displayed at a particular scrape time.

This matters in real directories. In one public exhibitor list reviewed for this guide, the same company name appeared under two profile URLs with two different stand numbers and different categories. Deleting one row based on name alone would have removed valid event information.

Use stronger event-aware keys in this order:

1. event_id + source_exhibitor_id, when the source provides a stable identifier;
2. event_id + normalised exhibitor_profile_url;
3. event_id + normalised domain + booth or hall; and
4. fuzzy company-name similarity only to create a manual review candidate.

Preserve the raw fields even after normalisation. Web Scraper Cloud Parser can remove labels such as “Stand:”, normalise whitespace, extract part of a string, create derived columns, and add the scrape time. Incorrect extraction should still be fixed in the sitemap. Parsing should not conceal a selector attached to the wrong record.

Company identity matching, enrichment, email verification, lead scoring, CRM assignment, and outreach belong downstream. They should append reviewed data without overwriting the event's published values or source provenance. The lead-generation workflow for public business data explains this boundary in more detail.

Schedule useful event snapshots and export complete results

Exhibitor directories often evolve as the event approaches. The most useful cadence follows that lifecycle rather than scraping at an arbitrary high frequency:

• an early baseline while the exhibitor list is forming;
• periodic updates when additions and booth changes matter;
• a final pre-event snapshot for planning; and
• a post-event snapshot for historical analysis.

First create and validate the sitemap in the extension, then move it to Web Scraper Cloud. Test the same driver, request interval, page-load delay, and proxy settings that the scheduled job will use. Once the result is correct, configure the scheduler, Parser, data-quality checks, and destination.

Web Scraper Cloud can combine scheduled jobs with automatic data export to supported spreadsheet and storage destinations after each job finishes. Manual downloads and API retrieval are also available. Validate the final parsed columns and formats before relying on unattended delivery.

For change tracking, keep snapshots rather than replacing yesterday's file. Compare them downstream using the event-aware keys. This makes new exhibitors, removed profiles, booth changes, and category changes distinguishable from scraper errors.

Review access, terms, and privacy before using the data

Technical access is only one part of a responsible workflow.

• Scrape public exhibitor pages that are appropriate for the intended use. Do not bypass logins, CAPTCHAs, or private event-app controls.
• Review the event site's terms, its robots.txt instructions, and the laws that apply to the collection and intended use.
• Use reasonable request intervals and avoid unnecessary repeated filter combinations.
• Collect only the fields needed, define retention rules, and preserve source URLs and observation dates.
• Treat named work contacts and individual email addresses as potentially personal data, even when published in a business context.
• Assess outreach separately from extraction, including lawful basis, transparency, suppression, and objection requirements in the relevant jurisdiction.

The Robots Exclusion Protocol is a crawler-instruction standard, not access authorisation. Conversely, the absence of a robots.txt restriction is not blanket permission for every collection or reuse. In the UK, regulator guidance also makes clear that publicly available business contact data can still fall under data-protection and direct-marketing rules. Obtain specialist advice where the jurisdiction, data type, or proposed outreach creates material uncertainty.

Turn a public directory into a maintained event dataset

The reliable workflow is to scope the public source, define the event and participation keys, build the list-to-profile sitemap, cover every navigation path, validate the exported records, preserve raw values, and only then automate snapshots.

Reuse the event-aware schema across conferences, but keep each sitemap source-specific. Start by building and testing a representative sitemap in the free browser extension. When the dataset is correct and recurring collection is useful, move the tested sitemap to Web Scraper Cloud for scheduled execution, quality monitoring, and completed exports.