Marketplace vs custom sitemap: which should you use?

Choose a Marketplace sitemap when a ready-made scraper covers your target site, accepts the pages you need to start from and returns the fields your dataset requires. Build a custom sitemap when the source, required fields or navigation differ. Marketplace sitemaps are not editable: changing the input URLs does not change their selectors, page paths or extracted fields.

Here, a sitemap means Web Scraper's instructions for navigating pages and extracting records. It is different from an XML sitemap a website publishes for search engines.

The decision at a glance

Both routes can lead to recurring Cloud jobs. The deciding question is whether the fixed collection logic produces your required records, rather than whether the job can be scheduled or exported.

Use a Marketplace sitemap when its input and output match

The Sitemap Marketplace offers ready-made scrapers for particular sources and page types. Check the individual scraper page, not just the name of the website. It should show which URLs to supply, which fields it extracts and sample output.

For example, the Amazon products listings scraper accepts category or search result URLs, follows listing pages into product pages and returns predefined product fields such as name, ASIN, price, availability and seller. The separate Amazon ASIN scraper starts from product page URLs. A team discovering products in a category and a team revisiting a known product list need different inputs, even though both collect Amazon product data.

Suppose you need one row per product with its identifier, current price and availability. If a suitable Marketplace sitemap returns those fields from the right pages, using it avoids building the navigation and selector tree yourself. Supply a few real input URLs and inspect the resulting records before putting it on a schedule. A published sample schema shows what the scraper is designed to collect; it does not guarantee that every source page will populate every field.

You can change the input set within a supported workflow, such as which category URLs to scrape. You cannot add a page visit, select another source attribute or change one product row into separate seller-offer rows by editing the Marketplace sitemap. If your only change is formatting a value already extracted, Cloud Parser can clean it or derive another output column from existing values. A parser cannot retrieve a field the scraper never collected.

The maintenance responsibility also differs. Web Scraper looks after the prebuilt sitemap's extraction definition; your team still owns its input choices, dataset checks and response to missing or unsuitable results. A ready-made scraper cannot guarantee that a source will return the same products or page state on every run.

Build a custom sitemap when you need collection control

Choose custom when the Marketplace has no suitable scraper, a required source field is absent from its fixed output, or your record requires a different page path or interaction. Imagine a retailer whose category page shows a product price, while your analysis needs stock for each size after selecting a variant. Or imagine that you need one row per seller offer instead of one per product. Those are changes to what the scraper visits and treats as a record, not changes a spreadsheet column can supply after collection.

A custom sitemap does not require writing code. The AI Sitemap Wizard can map repeated listing items and help with pagination, scrolling and fields on linked item pages. Review its results: automatic detection does not work on every site, and new listing-page fields cannot be added manually within the Wizard flow. For category traversal, complex clicks or direct control of the selector tree, use the Advanced Sitemap Builder. It lets you connect pagination, item links and detail-page fields, while keeping values beneath the right record boundary.

Control creates a repair task. When a site changes its markup or navigation, someone on your team can update the custom selectors and test them again. Name that owner before depending on the dataset for daily pricing, inventory or market intelligence work. If the workflow requires JavaScript rendering or clicks, test it with the appropriate Cloud driver; Fast cannot execute several interaction-based sitemap features that FullJS supports.

Test the dataset, not just the job status

Apply the same acceptance test to either route before committing to recurring runs:

1. Define one record. Is it a product, a variant, a seller offer or a property? List the required fields, stable key, source URL and acceptable blanks. A product count can look healthy while the seller-offer dataset you actually need is missing.
2. Check the input and route. Use the exact search, category or detail URLs you will run. Include later result pages, different layouts and any region or filter that changes visible content. Compare these with a Marketplace scraper's documented inputs and navigation.
3. Inspect real output. Sample standard, discounted and unavailable items where applicable. For custom work, use Element Preview and Data Preview before a limited run. In Cloud, use Test scrape with the driver and access settings you intend to schedule. Compare downloaded rows with their source pages, including whether prices, currency and identifiers belong to the same item.
4. Set quality checks. Look for duplicate keys, missing critical fields, unexpectedly low record counts, failed pages and pages processed without records. Cloud data quality controls can check minimum records, failed and empty page percentages, and field population. A job can finish while its data quality check fails.
5. Plan the response. Decide who will investigate a missing field or changed page, and how much page traversal the recurring job actually performs. A listing-to-detail workflow visits a different set of pages from a run that starts with known product URLs. Test actual usage and duration rather than inferring them from the number of output rows.

Neither route guarantees access or complete data on every website. A completed run is evidence that the job executed, not proof that its dataset is correct. Use a good run to set sensible thresholds, allow for ordinary variation and check a downloaded sample when the source changes.

The choice can differ by source

You can use a Marketplace sitemap for a standard product feed and a custom sitemap for another source whose variants or seller offers need their own records. Keep each job's source, record definition and required fields clear. Similar column names across sources do not automatically make their values comparable.

Start with the exact source and page type in the Marketplace catalogue. If its fixed output passes your acceptance test, use it and monitor the delivered records. If a necessary field, record boundary or navigation step is missing, build a custom sitemap and validate it before scheduling. The right route is the one your team can keep producing correct rows from.

When the chosen workflow is ready for remote runs, start a 7-day Web Scraper Cloud trial to test it on your actual pages.