No. SleekRank reads from your data source. If your sheet includes a script or formula that fetches prices, those flow through on the cache cycle. SleekRank does not scrape provider sites or call VPN APIs directly. The right pattern is a separate scraping or import job that updates the sheet on a schedule, then SleekRank renders whatever is current in the source on the next cache flush.

Both page groups read from the same source of truth — the providers sheet. The pairs page group joins two provider rows at render time using the slug pair from the pairs sheet. A change to a row updates wherever that provider is referenced after the cache cycle, including every pair page where the provider is product_a or product_b. The data layer enforces consistency that manual page editing cannot.

Define another page group with a different URL pattern and source, and use the same provider sheet as a join. A WireGuard-only page group could filter providers whose protocols array includes WireGuard and render at /vpn/wireguard/. A per-feature page like /vpn/no-logs/ filters on a no_logs column. Each cut is a real landing page with intro copy on the base template and the matching subset rendered from the source.

No. The verdict is whatever you write in your sheet. SleekRank does not write content, it injects content. For longer-form verdicts that exceed a sheet's column-character comfort, store them in a separate JSON file keyed by provider slug and join at render time. The verdict text is yours; the render layer is SleekRank's responsibility.

Yes. Map an image URL column to og:image with the meta type. Each provider page can render a custom social card via that mapping. For dynamic per-provider OG images that overlay the provider name, jurisdiction, and audit status over a styled background, pair with SleekPixel which renders OG images from data on the fly. Per-pair OG images can show both provider logos side by side.

Update the parent company column and any related jurisdiction or ownership fields in the sheet. Every page that references the provider — the per-provider page, every pair page where it appears, and any category roll-up — updates after the cache window. This is the dimension manual builds drift worst on, because nobody propagates ownership changes across dozens of pages by hand without missing some.

Store last_audit_date and audit_firm as columns. Map them into a badge or stat block on the page via tag mapping. When a new audit publishes, edit those columns and the badge reflects the new audit firm and date everywhere. For audits older than a year, you can conditionally render a stale-audit warning via selector mapping based on date logic in the template, alerting readers when a provider's audit needs a refresh.

Yes. Add columns for current server count and last-updated timestamp, then map into a stat block. For trend visualization, store a time series in a separate JSON file keyed by provider slug and render it as a small chart via a chart library on the base template. The page reflects the current server count from the main row plus historical context from the side dataset, joined at render time.