Most teams use Google Sheets so non-developers can edit it directly without involving a CMS workflow. SleekRank also reads CSV files, JSON URLs and files, REST APIs, and Notion databases. For larger chains, a Notion database with a shared salon view often works better than a sheet because of better property typing and per-cell change history.

Yes. Set up two page groups against the same data source. One uses /hair-salons/{slug}/ for profile pages, the other uses /hair-salons/{service}/{city}/ with row filtering on the services array column. The same row contributes to its profile, every service rollup it qualifies for, and the city rollup, with no duplication in the source data.

Edit the row in the sheet, flush the SleekRank cache for the affected page groups from WP-CLI, and the rebuilt pages reflect the new price on the next request. The change hits the salon profile and every rollup the salon participates in at once. No multi-page sweep is required because the price renders from the column, not from hard-coded copy.

No. SleekRank does not write copy or generate content. You provide the text in the data source and SleekRank places it on the rendered page through tag and selector mappings. If you want generated salon descriptions, use a separate tool to populate a description column in the sheet, then SleekRank renders that copy onto the page.

SleekRank can map any image URL field into img tags on the page or to og:image meta. Pair with SleekPixel if you want dynamic per-salon OG images instead of hosted ones — SleekPixel templates render the salon name, city, and specialty into a card automatically. For inline gallery images, host them on a CDN and reference URLs in array columns.

Yes. Add a stylists data source and a /hair-stylists/{slug}/ page group that maps each stylist row to its own URL. On the salon page, render the stylist roster via a list mapping that outputs anchors pointing at the stylist URLs. Stylist pages reuse the same base-page approach with their own credentials, specialty, and booking link fields.

Yes, with a REST API source pointed at your booking system if it exposes one. The API response feeds availability data into a list or selector mapping that renders next-available slots on the page. Cache the API response with a short duration so availability stays current without hammering the booking provider on every page request.

Store specialties as an array column instead of a single value. The salon page renders the full list through a list mapping, and each specialty rollup page group filters rows where the array contains its URL parameter. A salon offering both balayage and lived-in colour appears on both rollup pages from one row, no data duplication anywhere.