No. SleekRank reads from your data source. If your sheet pulls APYs via a script or formula on a schedule, those flow through on the cache cycle. SleekRank does not scrape bank sites or call APYs through any bank API. The pattern is a separate scraping or import job that updates the sheet, and SleekRank renders whatever is current in the source after a cache flush.

Both page groups read from the same banks sheet. The pairs page group joins two rows at render time using the slug pair from a pairs sheet. A row edit propagates to wherever the bank is referenced after the cache cycle, including every pair page where the bank is product_a or product_b. The data layer enforces consistency that manual page editing cannot.

Add columns for cd_rates and mma_rate, stored as JSON arrays or as separate fields. The per-bank page can render a full product lineup block, and a separate page group at /banks/cds/{slug}/ can target buyers comparing CD rates specifically, joined to the same banks sheet for shared bank-level facts.

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

Yes. Map an image URL column to og:image with the meta type. Each bank page can render a custom social card via that mapping. For dynamic per-bank OG images that overlay the current APY and FDIC status over a styled background, pair with SleekPixel which renders OG images from data on the fly.

Update the parent_company, brand_name, and any related FDIC certificate columns in the sheet. Every page that references the bank, including per-bank, every pair page where it appears, and any category roll-up, reflects the change after the cache window. This is the dimension manual builds drift worst on, since acquisitions rarely propagate across dozens of pages by hand.

Store promotional_bonus, bonus_requirements, and bonus_expiration as columns. Render them in a promo callout via tag mapping on the per-bank page, and join on pair pages to compare current bonuses side by side. When a promo expires or changes, edit the row and the entire catalog reflects it on the next cache cycle.

Yes. Store a time series of historical APYs in a separate JSON file keyed by bank slug and render it as a small chart via a chart library on the base template. The page reflects the current APY from the main row plus historical context from the side dataset, joined at render time, which helps readers see whether a rate is competitive within the bank's own history.