Pages render on demand and cache per cacheDuration, so the practical limits are hosting throughput and how aggressively crawlers hit new URLs. Hundreds of thousands of records work comfortably on capable WordPress hosting; millions warrant longer cache durations, a CDN in front of WordPress, and possibly chunking the dataset into multiple page groups by prefix. The dataset itself stays in CSV or JSON outside wp_posts, so database size is not a constraint.

Each source has its own cacheDuration. Pages serve from the items cache between fetches. For static reference datasets like ZIP codes or IATA codes, weekly or monthly caches are appropriate. For live REST-backed lookups like exchange rates or stock data, shorter durations match the data's freshness needs. Manual cache flushes via wp db query handle bulk dataset updates.

Yes, and the type depends on the dataset. PostalAddress JSON-LD for ZIP codes, Place for IATA codes, Book for ISBNs, FinancialProduct for SWIFT codes. Add the JSON-LD block to the base page once with selector mappings sourcing the relevant fields. Validate one record with the Rich Results Test, then trust the structural pattern: every /lookup/{slug}/ ships consistent schema because every record reads the same template.

The source is the audit surface. CSV rows or JSON entries are sortable, filterable, and bulk-editable in spreadsheet tooling. Required-field validation can run as a pre-import script. Duplicate keys surface as schema violations on import. The dataset stays clean because it lives where data tooling exists, not in WordPress where data tooling does not.

Yes. Configure a rest_api source pointing at the public endpoint. Common patterns are the OpenStreetMap Overpass API, Zippopotam.us for ZIPs, or any government open-data endpoint for canonical reference data. Cache responses generously since canonical datasets rarely change. Map fields via selector mapping. Always blend live API data with editorial overrides via a sheet for records you want to differentiate.

Only if the per-record content is genuinely thin or near-duplicate. The honest answer is that lookup datasets are at the boundary of what Google rewards. Differentiate by surfacing genuinely useful aggregations: neighboring records, contextual metadata, related external resources. Sort the source by content length to find rows with thin per-record narratives, and consider consolidating very thin records into category indexes instead of individual lookup pages.

Carry a status column with values like current, deprecated, merged, archived. The page group filter renders only current rows by default. Set up 301 redirects via your redirect plugin from deprecated URLs to current alternatives. For merged records (a ZIP code that absorbed another), point the deprecated record's URL at the new canonical record. The dataset history stays in the source as auditable record.

Yes. Each dataset becomes its own SleekRank page group with its own urlPattern. /zip/{slug}/ for ZIP codes, /area-code/{slug}/ for area codes, /iata/{slug}/ for airports. Each reads its own source and renders through its own base template if the layouts differ, or shares a generic /lookup/{slug}/ base if the structure is similar enough across datasets to justify a unified template.