No. SleekRank reads from your data source. If your sheet has a script that pulls Form 5500 filings or fee disclosures, those flow through on the cache cycle, but SleekRank does not scrape recordkeeper sites or call provider APIs. The right pattern is a separate import job that updates the sheet on a schedule, and 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.

Define another page group with a different URL pattern and source, and use the same provider sheet as a join. A target-date-fund page group could filter providers whose fund_types array includes TDF and render at /401k/target-date/. A per-feature page like /401k/auto-enrollment/ filters on a features column. Each cut is a real landing page with 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 provider name, fiduciary tier, and average fee over a styled background, pair with SleekPixel which renders OG images from data on the fly.

Update the parent_company column and any related fee or fund lineup 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.

Store fee schedules per plan tier as separate columns (small_business_fee, mid_market_fee, enterprise_fee) or as a JSON object keyed by tier. List mapping or selector mapping renders the correct schedule per page, and the comparison template can show side-by-side small-business pricing on one tab and enterprise pricing on another, all from the same row.

Yes. Add columns for current fund_count and last_lineup_review 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 lineup from the main row plus historical context from the side dataset, joined at render time.