Going Live
The launch work that needs a person, and the work the site now checks for itself
Launch readiness splits in two. Some of it the site can see, and the site reads it back on every visit to the CMS dashboard. The rest needs a person, and this page is where it's written down.
What the dashboard checks
Open the CMS dashboard and the Go-live section lists what's outstanding.
- Donation forms that can't take a gift. A donation block with no form URL renders a complete, branded, fully interactive donation form that does nothing.
- Newsletter signups that can't submit. Without the Constant Contact action URL the form renders grayed out.
- Vendor embeds still showing a placeholder. Blackbaud, Constant Contact, Double the Donation, ReciteMe, GTranslate or Google Tag Manager dropped on a page with nothing wired to them.
- Integrations switched on but not configured. ReciteMe or Google Translate toggled on in Site Settings with no script URL, or Google Tag Manager enabled with no container ID. An integration left switched off is a decision and doesn't get flagged; switched on with nothing behind it is a half-finished job and does.
- Redirects pointing at an address that doesn't exist.
- Placeholder copy, missing images, missing alt text, missing meta descriptions, broken internal links. Across published pages only.
- Dining centers missing from the finder map, and events or posts whose structured data can't be emitted.
Each line names the documents at fault and links straight to them.
There used to be a Launch Checklist in the CMS, under Settings. It's gone. Six of its eight items were claims the site could verify for itself, and a ticked box never un-ticks. The two remaining kinds of item are on this page.
Vendor accounts and credentials
Each of these is a conversation with a vendor or with someone who holds an account. Once the credential is in Site Settings or on the block, the dashboard takes over and watches it.
- Blackbaud donation form. The hosted form URL, the form ID, and the embed snippet. Until these land, every donation block on the site shows the placeholder form.
- Constant Contact signup. The action URL the newsletter form posts to. The legacy site posts to a WordPress plugin that's being decommissioned, so the URL has to be minted fresh rather than copied across.
- Double the Donation. The public key, if employer matching is carrying over.
- ReciteMe accessibility toolbar. A paid product. It needs a decision about whether it's being renewed, then the script URL. Leave the toggle off until you have the URL.
- Google Translate widget. Same shape: decide, then the script URL, then the toggle.
- Redirect rules from the legacy site. Exporting them out of WordPress is manual work in an admin nobody here controls. Once they're in, the dashboard flags any rule whose destination doesn't exist. See Redirects for what's carrying across and Redirects for how to add one.
Access and permissions
- GA4 service-account access. A grant inside the organization's Google Analytics property, made by whoever administers it. The site half of analytics — the Google Tag Manager container ID — is checked on the dashboard, but no code can see whether the reporting access was granted.
Work that has to be booked
- A formal accessibility audit. An engagement with a date and a budget, not a task. Book it against the Testing and review window in the timeline. The site is built to WCAG 2.2 AA and tested along the way; the audit is the independent read.
- The full Content-Security-Policy. A code change, blocked on knowing every third-party origin the finished site loads from. It can't be written until the vendor list above stops moving.
A Content-Security-Policy denies anything not on its list. Every vendor script added after it's written needs a matching entry, so tighten it once the integrations are settled and test every embed afterwards — the donation form, the signup form, the map, the video players.
Where each item stands
| Item | Who | What done looks like |
|---|---|---|
| Blackbaud form URL and embed | Vendor, then developer | Donation blocks stop appearing on the dashboard |
| Constant Contact action URL | Vendor, then publisher | Newsletter blocks stop appearing on the dashboard |
| Double the Donation public key | Vendor, then developer | Employer-matching embed renders |
| ReciteMe: renew or drop | MOWP decision | Toggle on with a script URL, or left off |
| Google Translate: keep or drop | MOWP decision | Toggle on with a script URL, or left off |
| Legacy redirect export | MOWP, then publisher | Rules in the CMS, none flagged as dead |
| GA4 service-account access | MOWP Google admin | Reporting access confirmed working |
| Accessibility audit | Booked engagement | Report received, findings triaged |
| Full Content-Security-Policy | Developer | Written after the vendor list settles, every embed retested |
Everything in the first two sections is waiting on somebody outside the build, which makes lead time the risk rather than effort. The donation form especially: it's the one item where the unfinished state looks finished.
The rest of go-live readiness reads itself off the dashboard. Check it the week before launch rather than keeping a second list.
For how content gets from draft to live once these are settled, see Reviewing and publishing.