Naming and intent. Some teams use "case study" to describe a long-form, narrative-led document; others use "customer story" for a shorter, metric-led page tied to a specific outcome. The shape is similar, the URL pattern is different (/case-studies/ versus /customers/), and the template emphasis differs (narrative depth versus headline metric and results table). Run both page groups against the same source if you want both surfaces.

Two practical patterns. Keep the customer in the source but mark a confidential boolean and exclude those rows from the rendered URLs. Or store anonymised versions ("a logistics company in the Midwest") and link to the full version behind authentication for sales. The structured source makes both patterns clean to implement.

Yes. Use blank cells in the register for sections that do not apply, and conditionally hide the rendered block in the template. Or use selector mappings to swap blocks per row, for instance B2B SaaS rows render an integration logo strip while D2C ecommerce rows render product thumbnails. The template stays one page; the per-row variation lives in the data.

Store the image URL as a column (logo_url, hero_image_url, og_image_url). Map them to img src via selector mappings, or set og:image per row using the meta mapping. For per-story OG cards, pair with SleekPixel: build a card template, point og:image at the SleekPixel URL with the customer name and metric in the query string, every share renders a branded card automatically.

Yes. Each generated URL is added to the SleekRank-managed sitemap automatically. The base template page is excluded and noindex'd because it is a scaffold. Submit the sitemap to Search Console after the first deploy and watch the URLs index over a few days.

SleekRank caches data per source for a configurable cacheDuration, typically 86400 seconds (one day) for customer stories. Edits during the day do not appear immediately. Flush manually via wp db query "DELETE FROM wp_319_sleek_rank_items" for instant updates after a CS sweep that touches many rows.

Yes, that is a primary use case. Each row gets a clean, predictable URL like /customers/orbit-dental-group/, perfect for embedding in proposal documents. Add a UTM-aware copy-link button on the page so reps can pull a tagged URL directly into their email tool.

Add a status column with values like active, refreshing, retired. Filter at the source level so retired stories either redirect to a hub page or render with a "results from 2023" disclosure. The structured source makes the audit trail systematic; hand-built customer stories tend to leak stale metrics for years before anyone notices.