A client we audited recently had what their agency was calling a finished website. The build was in staging. The launch date was set. The marketing team was already drafting the announcement post.
We ran our pre-launch checklist against the staging environment. The first audit pass surfaced more than 30 issues. It is the same audit we run on every SEO program for treatment centers when a rebuild or new site is queued for launch. The cost of catching issues in staging is a fraction of the cost of catching them in production.
Mobile Core Web Vitals were failing on every page that mattered: Largest Contentful Paint at 11.5 seconds, First Contentful Paint at 4.1 seconds, Speed Index at 6.1 seconds.
The blog template was rendering posts in a layout that looked more like a long-form article than a blog post, with no breadcrumbs and the date and author buried below the content. Headings were styled in all caps instead of Title Case with a CSS transform.
The main CTA on the homepage said “Enroll Now” but pointed to a tuition page rather than a contact form, which broke the intent for prospects who clicked the button to reach an admissions team.
We sent the audit back. The agency made fixes. We ran a second audit. Another full round of issues surfaced, including design system inconsistencies that had not been touched, hover states that were still mismatched across pages, and CTA blocks that were styled differently on every page they appeared on.
The site never launched in the state the agency originally pitched as “ready.” Two rounds of audit kept it from going live with quiet ranking and conversion problems baked in.
This is the pattern. A build the agency considers done is rarely actually done. The pre-launch SEO checklist is the gate that protects rankings, conversions, and the integrity of the launch from the assumptions that crept in during the build.
The dev team’s pre-launch checklist asks “does it work.” The SEO team’s pre-launch checklist asks “does it rank and convert.” These are different lists. Most agencies only run the first one.
Trevor Gage, Director of Earned & Owned Media, Webserv
Key Takeaways
- Pre-launch SEO QA is separate from pre-launch dev QA. Dev asks “does it work.” SEO asks “does it rank and convert.” Most agencies only run the first one, which is how sites launch with failing mobile CWV, broken schema, mismatched CTA intent, and a 30-item backlog Google starts evaluating on day one.
- A behavioral health site is YMYL. The first month after launch is the highest-volatility ranking window the site will see for the next 12-18 months. Issues that look minor in staging become quarter-long ranking suppressions when caught in production.
- The Webserv pre-launch checklist runs in two phases: pre-launch on staging (tracking, on-page SEO basics, schema, hierarchy, forms, images, footer compliance, CMS settings, design system, mobile CWV) and post-launch within 24 hours of domain switch (plugin verification, find-and-replace the staging domain, technical crawl, sitemap submission, forms verification).
- Six items dev teams routinely miss when they own the launch readiness call: schema markup (“we’ll add it after launch”), heading hierarchy (“design styles, not SEO”), mobile CWV (“we’ll optimize later”), redirects (“we have it covered”), design system consistency (“creative variation”), and the find-and-replace step.
- Run the audit twice. First on the original staging build. Second after the agency reports fixes are complete. If the second audit surfaces new issues, run a third. Every “fix” should be verified, not assumed.
This guide walks through the pre-launch SEO checklist we run on every behavioral health website before launch, the post-launch verification steps that catch what staging missed, and the specific gaps we see most often in audits.
Why pre-launch QA matters more in behavioral health
Behavioral health websites carry ranking authority that is expensive to recreate. The vertical is YMYL, which means Google evaluates trust signals more carefully than it does in unregulated categories.
A treatment center site that has been ranking for years sits on a foundation of authority signals that took years to build.
A botched launch puts every one of those signals at risk in 24 hours, and the recovery curve from a launch that went out the door with structural issues stretches across the next two to three quarters of admit pipeline. The risk asymmetry is steep. It is the same dynamic that informs when to rebuild versus optimize a treatment center website. A clean launch protects what years of ranking work built up.
The first month after launch is the highest-volatility window the site will experience for the next 12 to 18 months. Google recrawls aggressively. Every issue gets a fresh look.
Schema errors, missing redirects, broken canonicals, and hierarchy problems all get evaluated against the new state of the site. Issues that the agency assumed were “minor” turn into ranking suppressions that take months to reverse. The patterns I covered in why rebuilds hurt rankings are the same patterns that surface when pre-launch QA gets skipped.
The pre-launch checklist exists to catch those issues while they are cheap to fix. A schema error caught in staging is a five-minute fix. The same error caught two weeks after launch is a ranking recovery project.
The Webserv pre-launch checklist
The checklist runs in two phases: pre-launch (everything before the site goes live) and post-launch (everything immediately after the domain switch).
Pre-launch (run on staging)
Tracking infrastructure. Google Tag (GA4) and/or Google Tag Manager (GTM) installed on every page. CallRail or CTM call tracking code installed.
The CallRail or CTM “SwapTarget” set to the correct phone number for the site. This is one of the most-missed items, and a wrong SwapTarget routes calls to the wrong destination from the moment the site is live.
On-page SEO basics. Every page has an SEO title and meta description that target the right keyword for the page. Page hierarchy and permalink structure follow the site’s IA.
If the launch is a relaunch, redirects from old URLs to new ones are in place at the server or CMS level.
Schema markup. Proper schema is utilized throughout. Service pages, location pages, blog posts, FAQ blocks, and organization-level schema all return clean validation in the Schema Markup Validator.
Heading hierarchy. Every page has exactly one H1, with H2s and H3s nested below it. No H1s in nav or header components. No H4s before H3s.
Heading text reflects the page’s keyword intent and reads naturally. Heading styling uses Title Case at the content level with CSS transforms applied for any all-caps display preference, rather than typing headings in all caps.
Forms and conversion plumbing. Every form on the site is wired to the correct recipient. Forms include the correct hidden fields for source attribution. The thank-you page (or thank-you state) fires the correct conversion event.
Buttons are functional and route to the correct destination. The CTA intent matches the destination: a “Contact Us” button leads to a form, an “Enroll” button leads to enrollment, a “Verify Insurance” button leads to the verification flow.
Image optimization. All images have descriptive alt text. Image file sizes are optimized for web. Hero images are sized appropriately for the device they will render on (mobile-first sizing as the default).
Footer compliance. Necessary accreditations and licenses are displayed in the footer: DHCS, LegitScript, Joint Commission, and any state-specific licensure. Privacy policy and terms of service links are present.
CMS settings. Comments are turned off on blog posts. Blog template is not using date archives or categories unless desired. reCAPTCHA v3 is enabled site-wide on form submissions.
Design system consistency. Hover states are consistent across pages. Buttons have consistent styling and consistent destinations. Footer is identical on every page (universal element, not a per-page implementation).
Colors are used consistently with the design system: primary CTA color is reserved for primary CTAs, and secondary colors do not falsely imply interactivity.
Core Web Vitals on mobile. Run PageSpeed Insights on every priority page. Per Google’s Core Web Vitals guidance: mobile LCP under 2.5 seconds, FCP under 1.8 seconds, CLS under 0.1, and SI under 3.4 seconds.
If any priority page is failing on mobile CWV, fix it before launch. Failed CWV at launch is a launch-day ranking suppression. The companion patterns are in the mobile-first indexing guide. The same audit pattern that protects existing sites also protects launches.
Post-launch (run within 24 hours of domain switch)
Plugin verification. Confirm Rank Math (or your SEO plugin), Elementor (or your page builder), and any other ranking-critical plugins are active after the domain change. Plugin states sometimes reset on domain switch.
Find and replace the staging domain. Run a “Find and Replace” across the database to remove every reference to the staging domain.
Internal links pointing at staging URLs are one of the most common post-launch issues we see, and they ship internal staging URLs to production. The fix is one query; the failure is invisible until someone notices the broken links weeks later.
Technical crawl. Run an SEMrush or Screaming Frog crawl on the live site. Address every issue surfaced: 404s, redirect chains, missing meta descriptions, duplicate titles, broken canonicals, orphan pages. The same patterns covered in the technical SEO fix list apply directly here. The post-launch crawl is the first chance to catch them on the live site.
Submit the sitemap. Submit the new XML sitemap to Google Search Console. Verify the property in GSC. Confirm the sitemap parses cleanly and the URL count matches expectations.
Forms verification. Submit a test through every form on the live site. Confirm the client receives the test submission at the correct destination. Forms that worked in staging sometimes break in production due to environment differences, and the failure mode is silent until a real prospect submits.
What dev teams routinely miss
The pre-launch checklist above covers the full surface when SEO owns it, but when the dev team takes ownership of the launch readiness call, several items routinely get treated as out of scope or low priority. The pattern is consistent enough to catalog.
Schema markup is treated as “we will add it after launch.” It rarely gets added. The site goes live without schema and never gains the rich result eligibility it should have had from day one.
Heading hierarchy is treated as “the design team handles styling.” The design team styles, but they do not validate the underlying H tag structure. We routinely see sites with three H1s on the homepage, H2s skipped entirely, and H4s used where H3s should be.
Mobile CWV is treated as “we will optimize later.” Later does not arrive. The site launches in failure on mobile speed metrics and stays there because optimization gets deprioritized once the site is live.
Redirects from old URLs to new URLs are treated as “the dev team has it covered.” What “covered” means in practice is a sample of high-traffic URLs got mapped, while the long tail of indexed URLs returns 404s. Backlinks die. Ranking equity disperses.
Design system consistency is treated as “creative variation.” The design team thinks orange-vs-green hover state inconsistency is a styling choice. Google reads it as a quality signal: specifically, the absence of consistency that high-quality sites display.
The “find and replace” step gets skipped. The agency forgets to run it because the site looks fine on the surface. Internal staging URLs ship to production. Months later, someone notices that internal links go to a domain that no longer exists.
The fix for all six is the same: SEO owns the pre-launch checklist. The dev team’s QA pass is a prerequisite, not a substitute.
What gets backfilled when pre-launch is incomplete
A residential treatment center we worked with after their rebuild gives a representative example of the post-launch tail. The site launched in late 2025. We came in for an SEO retainer in January 2026. Inside the first month, we logged 7.5 credits of optimization work across 13 pages.
The work was not new content development. It was cleanup that should have happened pre-launch.
Page intent was unclear on multiple service pages. The PHP page did not distinguish itself from the IOP page. The OP page was using language that read interchangeably with the PHP and IOP pages. Each one needed clarification of what level of care the page actually represented.
Meta titles and descriptions were missing target keywords on most service pages. The H1 on the IOP page did not contain the words “intensive outpatient” or “IOP.” Image alt text was either missing or generic (“image1.jpg”).
Internal linking between blog content and service pages was sparse, with most blog posts not linking to any related service page. The “Verify Insurance” links on multiple service pages pointed to a deprecated URL.
Each fix was small. The collection took roughly a month of work. Every item on that list could have been caught in a 30-minute pre-launch audit and fixed in staging, where the cost of the fix is one CMS edit.
Caught post-launch, every item required scoping, sign-off, and CMS work on a live site that the marketing team was actively using.
The total backfill cost was meaningful. The pre-launch cost would have been a fraction.
Every engagement is built around your north star metric, reviewed quarterly, and adjusted when the industry changes.
No set-and-forget campaigns. No vanity metrics. A five-pillar system built specifically for treatment centers that ties marketing directly to admissions.
Common mistakes that cost the most
Three mistakes surface in audit after audit. Each one has a specific fix.
Mistake 1: The checklist is owned by dev, not SEO. Dev runs functional QA. SEO runs ranking and conversion QA. The two checklists overlap in some places (forms work, pages load) but diverge in others (schema, hierarchy, CWV, redirect map).
When dev owns the launch readiness call, the SEO list does not get run. The fix is to put SEO on the launch sign-off as a co-owner with dev.
Mistake 2: The audit runs once. The agency makes fixes. The site launches. No second audit confirms that the fixes worked.
We routinely see “fixes” that introduced new issues, or fixes that addressed a symptom while leaving the underlying problem in place.
The fix is to run the audit twice: once on the original staging build, once after the agency reports the fixes are complete. If the second audit surfaces new issues, run a third.
Mistake 3: Performance is treated as a post-launch project. Mobile CWV gets pushed to “we will optimize the site after launch when we have real data.” This is the path of least resistance for the dev team and the worst possible outcome for the client.
A site that launches with failing CWV ranks lower from day one. The fix is to require passing mobile CWV on every priority page as a prerequisite to launch.
What success looks like
A treatment center that runs the pre-launch checklist correctly should see a clean launch with measurable ranking stability through the first 90 days.
Day of launch: site goes live with all checklist items confirmed. No 404s on indexed URLs. All forms submitting to the correct recipient. Mobile CWV passing on priority pages. Schema validating cleanly. Internal links pointing at production URLs.
Week 1: GSC indexing the new sitemap. Daily monitoring of impressions and clicks against the pre-launch baseline. No major drops on the priority commercial keyword set.
Weeks 2 to 4: rankings stable or trending up. Conversion volume tracking against the pre-launch baseline. Any small dips correlate with normal recrawl volatility rather than structural issues.
Weeks 5 to 12: rankings climb past the pre-launch baseline as Google validates the new structure and the cleaner technical signals. Admit pipeline volume holds or grows.
Sites we have launched against this checklist consistently see traffic stability through launch and meaningful gains in the 60 to 90 days that follow. Sites we have audited where the checklist was not run consistently spend the same window recovering from preventable issues.
Frequently asked questions about pre-launch SEO QA for treatment center websites
How long should a pre-launch QA take?
A full pre-launch SEO QA typically takes 2 to 4 weeks of structured work before launch, with the depth scaling by site size. A 30-page treatment center site needs 2 to 3 weeks; a multi-location site with 100+ pages needs 4 to 6 weeks. Less than 2 weeks of QA on any treatment center site usually produces structural issues caught post-launch when they are more expensive to fix.
The work splits into discrete phases. Week one is technical audit (schema, indexability, redirects, canonical tags, robots.txt, sitemap). Week two is content audit (URL structure, internal linking, page-level SEO). Week three is HIPAA and compliance review (tracking layer, form handling, third-party scripts). Week four is final remediation and launch sign-off.
The variable that compresses the timeline is whether the dev team produced clean output in staging. A site that requires extensive remediation extends the QA window. A site that ships clean to staging can complete QA in 2 weeks. The QA timeline is partly a function of the dev team’s output quality, not just the QA team’s depth.
Can we run pre-launch QA after the site is already live?
Yes, and we run it as a post-launch audit on most sites that came to us without pre-launch QA. The work is harder and more expensive after launch because issues are now compounding on live traffic, but it is recoverable. Most post-launch audits surface 20 to 50 issues that should have been caught pre-launch. Fixing them recovers most of the ranking and traffic the issues were costing.
The cost difference is meaningful. Pre-launch QA on a 30-page site runs $5,000 to $15,000. Post-launch recovery work on the same site, after issues have been live and indexed for 3 to 6 months, typically runs $15,000 to $40,000 plus the lost traffic during the issue window. The math heavily favors doing the work pre-launch.
Programs that already launched without QA should run the audit immediately rather than waiting. Each month of issues live multiplies the recovery work needed. The fastest path to ranking stability is to surface and fix the structural issues in the first 60 days after launch, before they compound.
Who on the team should own pre-launch QA, the agency or in-house?
Pre-launch SEO QA typically works best with a specialist agency owning the audit and a named in-house lead (marketing director, operations lead, or technical project manager) owning the remediation coordination. The agency runs the audit because the technical depth is hard to maintain in-house. The in-house lead owns coordination because the dev team needs a single point of contact to action fixes against.
The model that fails is agency owns audit, dev team owns remediation, no in-house lead in between. Without the in-house coordinator, audit findings get logged in a project management tool and slowly forgotten. Half the issues never get fixed because nobody is accountable for the fix sequence.
The other failing model is in-house owns audit, agency does spot review. Pre-launch SEO QA requires depth across schema, indexability, HIPAA tracking, internal linking, page speed, and a dozen other layers. In-house teams that try to own the full audit typically miss 30 to 50 percent of the issues a specialist would catch.
What is the most expensive item we should never skip on the checklist?
Redirect mapping during a rebuild is the single most expensive item to skip. A site rebuild that ships without properly redirecting the old URL structure to the new one can drop organic traffic 30 to 70 percent overnight, and the recovery typically takes 6 to 12 months even when the redirects get backfilled afterward. The lost organic admits during that window often run into seven figures.
The second most expensive item is HIPAA tracking compliance. A site that launches with non-compliant Meta pixel, standard GA tagging, or third-party retargeting tags on patient-adjacent pages creates OCR exposure that can result in seven-figure enforcement actions. The cost of the compliant tracking infrastructure pre-launch is trivial compared to the cost of remediation after an OCR investigation.
The third most expensive item is schema markup at launch. A site that ships without MedicalOrganization, LocalBusiness, and FAQPage schema misses ranking signals that would have been working from day one. Backfilling schema 90 days post-launch produces eventual ranking lift, but the missed traffic during that window is unrecoverable.
How do we get our dev team to take pre-launch SEO seriously?
The most reliable pattern is to include a named SEO sign-off requirement in the launch criteria from the start of the build, alongside the QA, accessibility, and security sign-offs. Dev teams take SEO seriously when it is a launch gate, not a post-launch suggestion. When SEO sign-off is required to ship, the SEO audit gets resourced and respected throughout the build.
The pattern that fails is treating SEO as a final-week check before launch. By that point the architectural decisions are locked, the URL structure is set, and the schema deployment is too late to influence. The dev team gets handed a list of 30 issues a week before launch and pushes back because the timeline does not accommodate them. Most of the issues then ship live.
The other reliable pattern is to embed an SEO specialist in the build process from day one. They review the wireframes, validate the URL architecture, sign off on the schema plan, and approve the deployment checklist before the dev team starts cutting code. The cost of upfront SEO involvement is much lower than the cost of post-launch SEO remediation, and the dev team becomes a partner rather than a target.
What to ask your dev or web partner this week
Three questions surface whether your partner is set up to protect rankings through a launch.
First, ask who owns the pre-launch SEO checklist. A serious answer references SEO as the owner, with dev as a co-owner on technical items. A weak answer is some version of “we have a launch checklist.” That checklist is almost always a dev checklist, not an SEO one.
Second, ask for the mobile Core Web Vitals scores on every priority page in staging. Specific numbers are the right answer. A vague answer means the partner has not measured. If they have not measured, they cannot fix.
Third, ask for the redirect map. The map should be a row-by-row mapping of every existing indexed URL to its new equivalent. A serious partner can produce this in five minutes. A weak partner says “we are still finalizing the URL structure” two weeks before launch. Local-pack-driven sites, the kind covered in our local SEO playbook, are especially exposed when the redirect map misses the long tail of indexed location-page URLs.
The pre-launch SEO checklist is the cheapest insurance policy a treatment center website launch can carry. The cost of running it is hours. The cost of skipping it is months of admit pipeline. Book an intro call and we will run the checklist against your staging site before the launch date.
The perspective in this article comes from 9 years working exclusively inside behavioral health.
We are a team built by people in recovery who understand that behind every admission is someone asking for help. If that resonates, get to know us.
Trevor Gage is the Director of Earned & Owned Media at Webserv. Webserv works with behavioral health and addiction treatment centers on SEO, paid media, and full-funnel admissions strategy.
