How Core dna caches pages, what makes a render fast, how code reaches a site and what stays behind, the go-live checklist, and running a site once it is live. For developers, leads and site operators who already build pages in a theme repository.
L2–L3
Unit 05 · Go-live
The go-live checklist
Go-livePage 24 of 34Updated
One page to print and tick, ordered by when each item must be done rather than by topic. Each item links to the page that explains it.
Who this is for. The person who owns the launch of a site on Core dna, usually the agency's lead developer or project manager. Print it, fill in a name and a date against each line, and tick it; afterwards nothing on launch day depends on memory.
The order matters more than it looks: several items depend on the one before, and a few cannot be undone once the domain moves. The two missed most often, the redirect map and a test payment or tax provider left active, each have a page of their own.
Two weeks before
Item
Detail
☐
Redirect map built from every URL the old site serves, imported on staging and tested in full
Mail sender set: the Mailer settings Default sender email and Default sender name on the client's domain, and the client's own SendGrid account in SendGrid API Key with that domain authenticated. Left blank, mail goes out under the platform's shared sender identity
Ask Core dna for the DNS records the domain needs
☐
Analytics and tags load on the production hostname only
Redirects in place on the production site, every one published. Imported on staging, they are there already, because a site's environments share their records; import them now only if the build was done on a separate copy
Cache cleared after the redirects and the robots change, because a stored page is served before redirects are checked. Clearing an environment's cache in the admin needs a super administrator