Yes. Add a subspecialty-certifications column listing each board (spinal cord injury, sports medicine, brain injury, pain medicine, pediatric rehabilitation) and render it with a list mapping. A second tag mapping can surface the primary subspecialty as a hero badge.

Store accepted plans as an array column in the source sheet. Map it to a list selector on the profile, set a short cache duration on that data source, and update the row when contracts change. The next request rebuilds the page with the current plan list.

No. SleekRank only generates pages from data. Appointment booking comes from your theme, a forms plugin, or an embedded scheduler like Nexhealth or Athena placed inside the base page. SleekRank renders the page and leaves the booking integration alone.

Google Sheets, CSV files, JSON URLs and files, REST APIs, and Notion databases are all supported. Practice managers typically prefer Sheets, while academic centers with developer support read directly from an internal physician API endpoint.

Yes. Profile and rollup pages are real WordPress URLs in the XML sitemap with their own meta titles, descriptions, and OG images per row. The base template page is automatically noindexed so it does not compete with the rendered profile pages in search.

The base page sets the layout, and mappings vary content per row. For real layout variation, use a layout-variant column and conditional Twig or block-visibility logic on the base page, so a sports profile renders different sections than an inpatient SCI profile.

Remove the row from the source. On the next cache refresh, the URL returns a 404 and drops from the sitemap. No orphaned WordPress page lingers in the admin, and the condition and city rollups stop including the row automatically.

Yes. Run two page groups against the same dataset with different URL prefixes and language-specific mapping columns (intro_en and intro_es, for example). Each language version reads its own copy column while sharing the structured data like procedures and insurance.