There is no hard cap. Pages are generated on request and cached per the page-group cache duration, so a catalog of several hundred pairings runs comfortably on standard WordPress hosting. The bottleneck is sheet size, not page count.

Edit the row in the source sheet, clear the SleekRank cache, and the next request rebuilds that pairing's page from the new data. The cache duration in the page-group config controls how often the sheet is re-read automatically. Manual flush is also available from the SleekRank settings.

Yes. SleekRank renders into a normal WordPress page, so any builder that ships with your theme (Gutenberg, Bricks, Elementor, Breakdance) handles the layout. SleekRank only swaps marked elements via tag, selector, list, and meta mappings.

Yes. Every generated URL is a real WordPress page registered with the sitemap. The base template is automatically noindexed so search engines crawl only the per-pairing URLs. Internal linking from a /pairings/ index page helps long-tail pairings get discovered.

Yes, within limits. Use conditional template logic on a column value (such as 'premium' versus 'budget') to show or hide sections like aging recommendations or price tiers. Major layout changes are easier handled by routing some rows to a second page group.

Delete the row from the sheet, clear the SleekRank cache, and the corresponding URL returns a 404. The sitemap drops the URL on the next regeneration so search engines stop crawling the removed pairing without manual intervention.

Not if each pairing has unique data. Wrapper, strength, ring gauge, drink match, and tasting notes vary row to row, so each rendered page carries distinct content. Keep the prose sections row-specific rather than boilerplate to stay safely clear of thin-content flags.

Yes. SleekRank supports Google Sheets, CSV, JSON URL, JSON file, Notion, REST API, and CSV URL data sources. A primary sheet plus a REST API endpoint for live retail prices is a common pattern, with each source feeding different mappings on the same page.