Sitecore XM Cloud Case Study: 3 Specialty Brands, One Site

After a large cancer-care network launched its new website on Sitecore XM Cloud, I joined the agency's content team that kept it running and growing. Over about nine months we folded three specialty brands into the main site and cleaned up content problems left over from the earlier migration.

• Who it serves: patients and families looking for doctors, locations, treatments and clinical trials across hundreds of clinic sites.

• My role: content editor on the agency's content entry team. I built, moved and audited content, then passed each change to QA, the project manager and the client for approval.

• Scope: about 75 support requests, from single-page fixes to brand moves, audits and data imports.

• Way of working: sprint-based support. Every change went through preview, QA and client sign-off before it was published.

The new platform was live, but some content hadn't come across cleanly, and three specialty practices still had their own separate websites.

• Separate brand sites: a proton therapy centre, a urology practice and a breast-care practice each needed their own look inside the main site without becoming separate builds.

• Empty pages in public: a set of patient story pages had gone live at launch with placeholder text or no content at all.

• Inconsistent opening hours: location pages showed hours in different formats, which looked untidy and was harder for patients to read.

• Moving without breaking links: doctors' profiles and pages had to move to new addresses without losing visitors or search rankings.

The site runs on Sitecore XM Cloud with a headless Next.js front end, edited through Sitecore Pages and the Content Editor, with redirects managed both in the CMS and at the Vercel edge. Its content model keeps reusable data, such as locations, providers and hours, in shared Content Base Templates, linked to pages through tag categories rather than direct references. Specialty brands live as sub-areas inside one site tree, each with its own menu and footer, instead of using Sitecore's multi-site feature. Most of my work came down to understanding where content actually lived in that model before changing anything.

1. Bringing specialty brands into one site tree

Each specialty practice needed its own look and URLs while sharing components and data with the main site.

• Brand sub-areas: pages were moved or created under each brand's folder (for example /proton-therapy/…, /breast-care/…), with that brand's menu and footer applied, so pages in the sub-area inherit the right design options.

• Brand-specific copies with noindex: where a brand needed its own version of an existing page, such as a breast-cancer page with brand-specific tabs, FAQs and accordions, we duplicated the page and its content base, rewrote it for the brand and set it to noindex. That kept the brand experience without creating duplicate content for search engines.

• One clinic, two brands: one building housed both the proton therapy centre and a urology practice under a single location page. We duplicated that page twice into proton-therapy and urology child pages to match the existing tab-style URLs. We then emptied the parent, set it to noindex as a folder, and attached a new location record to each child so each brand could stand alone.

• A mistake caught by QA: one move accidentally took a whole shared folder under a brand folder. QA flagged it, and we moved it back and duplicated only the page the brand needed. The re-check then caught a brand title left on the restored page, which we fixed before sign-off.

2. Moving pages without breaking links

Fifteen proton therapy doctor profiles moved to a new path, and their old addresses, including links from the brand's former domain, had to keep working.

• Two layers of redirects: old CMS paths went into the Sitecore Redirect item, which only takes effect after a full site publish. Old-domain URLs were handled as Vercel redirects through the development sprint, because they never reach the CMS.

• Updating destination links: provider grids read each card's destination link, so updating those links to the new path fixed the grids without any front-end changes.

• Form thank-you pages: when a support-group form's thank-you page moved, a new redirect wasn't needed. Forms first go to /thank-you?formID=… and are routed by a CMS redirect entry, so updating that entry and publishing the site fixed it.

• Avoiding publish conflicts: full-site publishes were scheduled with the client and paired with a short freeze on their side, so nobody's in-progress edits went live by accident.

3. Finding and pulling empty pages

The client noticed that some patient story pages were blank. The first job was to work out why before deciding what to do.

• Checking version history first: Sitecore's version history showed the pages had been empty since launch. That ruled out a recent editing error or a rendering bug.

• A page-by-page record: I recorded the real state of all 20 pages. Most held only placeholder text, one had two sentences, one had a sentence and a broken link, and one had nothing.

• Unpublish, then rebuild: with the client's approval, all 20 were unpublished and disappeared from the stories listing. Each then got its own ticket to be rebuilt from the original content.

4. Auditing location hours before touching the data

Hours displayed inconsistently, and both the client and the team first assumed it was a display bug.

• Root cause: the component worked as specified. If Use Hours is ticked, it shows the structured day-by-day fields. If not, it falls back to a free-text Hours Additional Text field. The previous vendor's migration had left many structured fields empty and filled the free-text field instead.

• A structured audit: I exported all 194 location address records from the shared content base. I sorted them into six cases, based on whether the structured hours were filled in, whether Use Hours was ticked and whether free text was present, and gave each a recommended action and an estimated effort in minutes.

• Pushing back on scope: the client asked to clear some locations' hours so they would inherit a primary location's hours. I flagged that this could remove the fallback and leave pages with no hours at all. We kept the work to fixing the free-text formatting and noted the rest for a later strategy discussion.

• Publishing dependent pages: QA found some fixes weren't showing, because location pages render cached values from the content base. We republished every affected location page as well as the data records, after confirming the client had no edits in progress under that path.

5. Smaller fixes and a data import

Day-to-day requests covered navigation, profiles and recurring data. Each followed the same preview, QA and approval path.

• Breadcrumbs: on 10 pages the breadcrumb showed the full SEO-style title (for example "Breast Cancer | Texas…") instead of a short label. Each was corrected with its item path and the requested label recorded for QA.

• Provider profiles: new clinician bio pages were created and linked to their locations, and specialties and locations on existing profiles were updated.

• Clinical trials import: a weekly trials CSV was imported into the CMS, first in a lower environment to time it (about 1 hour 44 minutes including publishing), then in production (about 2 hours 4 minutes). QA confirmed every trial card in search led to a real page, with no duplicates.

Three specialty brands now sit inside one site with their own menus and footers, and the content problems patients could see were dealt with.

• Three brands, one site: proton therapy, urology and breast-care content was brought under the main site across about 37 tickets, with 15 doctor profiles moved and redirected.

• 20 empty pages taken down: patient story pages that had been blank or full of placeholder text since launch were unpublished and queued for rebuilding.

• 194 location records audited: hours formatting went from a mix of free text and structured data to the standard format, and the client signed off after two final tweaks.

• Limitations: we didn't measure traffic or search impact. The patient stories still need the client's original content, and the wider question of how hours should work was moved to a future strategy discussion.