Launch day gets all the attention, but a Drupal site’s real test is the month after it. The launch checklist gets you live; the first month decides whether the site stays healthy — whether editors can actually publish without breaking things, whether caching behaves under real traffic, whether search engines see what you think they see, and whether small issues are caught while they are still small. Teams that treat go-live as the finish line tend to meet their first real incident in week three, alone, with no plan. Teams that treat the first month as a distinct phase ship the same site with fewer surprises.
This checklist is that phase, compressed. It assumes the site just launched cleanly and the Drupal editor experience launch checklist passed before go-live; here the focus shifts from building to observing and handing over. Everything below rolls into the ongoing Drupal maintenance checklist after the first month, so nothing on this list is a permanent new duty.
Week One: Watch It Like It Can Still Break
The first week is observation mode. Set up — or confirm — error monitoring and a daily check-in on the log: PHP errors, watchdog entries, and failed cron runs are normal in small numbers after launch and must be trending down, not up. Verify cron is actually running, because a silent cron failure in week one becomes stale search indexes and missed updates in week two. Watch cache behavior under real traffic: if pages are being served stale in ways editors complain about, fix the cache invalidation rules now rather than teaching the team to flush caches manually. And do one deliberate content exercise: publish a real piece of content through the normal editor flow, on the live site, exactly as the team will. Every shortcut you are tempted to take in week one is information about where the process will break in month four.
Verify What Search Engines See
During the first month, verify the search-visible surface while it is still easy to change. Confirm XML sitemaps exist and include the content you expect, submit them in Search Console, and watch for coverage errors. Check that canonical tags, meta descriptions, and Open Graph data render correctly on the main content types — template bugs here are invisible to visitors and obvious to crawlers. Test the 404 handling and a few intentional bad URLs: a Drupal site with a theme-level 404 problem can soft-error thousands of URLs quietly. If any of this surfaces performance doubts, the Drupal performance audit is the right follow-up, but the first-month version is just confirmation: page loads render, sitemaps list, metadata shows. Deep optimization is a later decision, not a launch-week scramble.
Hand Over To The People Who Will Run It
A site nobody on the client team can operate is not delivered, whatever the contract says. In the first month, run the handover as a working session, not a document drop: the editor who will publish weekly content does it themselves while you watch, the person who will handle updates applies one real update with you nearby, and the person who will field questions learns where the logs and backups live. Write down the three things most likely to be needed urgently — rollback, restore, and cache clear — as a one-page runbook with actual commands, not links to documentation. The Layout Builder vs Paragraphs in Drupal decision (or whatever architecture choice shaped the build) deserves one paragraph in that runbook too, because future content changes will hit it.
The Stabilization List
Some tasks only make sense once real usage exists. Trim the module list against reality: anything disabled or unused in the first month is a candidate for removal at the end of it, and fewer modules means fewer updates and fewer attack surfaces. Review user accounts and roles: the launch often leaves temporary accounts, over-broad roles, or a forgotten admin from the build phase. Tighten file permissions and confirm automated backups have actually been restored once — a backup that has never been restored is a hope, not a plan (the Backup and Migrate module documents the standard restore procedure and is a reasonable reference even if your stack uses a different tool). And schedule the first update cycle: module and core security releases do not pause politely because your site is new.
The First Month At A Glance
| When | What goes in it | Done means |
|---|---|---|
| Week one | Error monitoring, cron verification, cache checks, one real publish | Logs trending down, content flows work |
| Weeks one to two | Search verification: sitemaps, metadata, 404s, Search Console | Coverage clean, metadata correct |
| Weeks two to three | Editor and operator handover with a one-page runbook | Team performs tasks unassisted |
| Weeks three to four | Module trim, account audit, backup restore test, update cycle scheduled | Attack surface down, restore proven |
| Month end | Hand off to the routine maintenance checklist | No open launch-phase tasks |
The table is the whole first month: watch, verify, hand over, stabilize, then merge into routine maintenance. None of it is exotic; all of it is skipped by teams who consider launch the end of the project.
First-Month Mistakes To Avoid
Three patterns cause most post-launch pain. The first is disappearing after go-live — the team that built the site vanishes to the next project, and week-two issues surface weeks later through the client. The second is documentation instead of handover: a forty-page runbook nobody has used is worth less than one afternoon of supervised practice. The third is treating small warnings as launch noise: the PHP notice that appears in week one becomes the error that pages someone in month three. The first month is cheap attention buying expensive insurance; spend it deliberately.