The habit of checking before launch was forced on me by an accident. Once, during a feature revamp, I only discovered after launch that the new page was missing a canonical — so it fought with the old page, sending duplicate-content signals and messing up rankings for a while. After that, I set myself an iron rule: before any content or feature goes live, run through a 15-minute SEO checklist.
Why pre-launch checks matter
Fixing an error before launch takes five minutes; after launch it can take five weeks — redirects, re-indexing, trust repair, all slow work. A 15-minute pre-launch checklist is the highest-value insurance.
The pre-launch checklist
My checklist has ten items: title (unique, contains the keyword, within 60 characters), description (present, appealing, accurate), URL (clean, correct slug), content (no typos, complete structure), images (alt, size, compression), internal links (at least one relevant internal link), external links (canonical correct), mobile (displays properly), speed (page loads normally), structured data (Schema without errors). Check flow: go through from top of the list to bottom item by item, fix issues immediately when found, verify indexability with the GSC URL inspection tool after fixing, then submit for indexing. Four common oversights: forgetting internal links, making new content an island spiders can’t find; images not compressed, dragging down speed; wrong canonical, duplicate-content risk; not checking mobile, content garbled on phones. Update the checklist after every stumble, reuse it every launch, and review the flow quarterly.
How to split the ten items
I split the ten into “decidable before launch” and “verify after launch.” Decidable before launch: title, description, URL, content, images, canonical, mobile, speed — these can be checked before publishing; verify after launch: confirming indexability with GSC’s URL inspection tool, checking whether real-time data is normal. Writing the two post-launch items into the checklist is to prevent a “published, done” mentality; often indexing anomalies are exactly what you should catch on day one.
Tools for checking each item
Use a preview tool for title and description to see how they look in search results, not going by feel; check the slug in the editor for URL; batch-check image alt and compression in the media library; open device simulation for mobile; run PageSpeed Insights for speed. I save these tool addresses as one group in the browser bookmark bar, clicking through them one by one before launch — much faster than hunting them down on the spot.
Launch check quick reference
| Section | Check item | What failure looks like |
|---|---|---|
| Meta info | Title/description | Truncated or hollow in search results |
| Structure | URL/canonical | Duplicate-content signal or broken addresses |
| Assets | Images/speed | Slow load, garbled mobile display |
| Verification | GSC indexability | Not indexed for a long time after launch |
Make the checklist actually get used
A great checklist is useless if nobody uses it. My approach is making it a required step in the publish flow: editors must check all ten items before they can click publish; operations spot-checks three published pages weekly for missed items. Whenever we step on a landmine (like forgetting canonical), bold that item as a reminder. This way the checklist stays alive, growing together with the accidents.
What more you can save after templating
Once the checklist stabilizes, I turn the four most common problem types into templates: new articles, revamped pages, campaign pages, and deleted pages — each with slightly different checked options. At publish, pick the matching template instead of re-reading all ten items each time. Deleting pages is the most easily forgotten — before deleting, confirm nothing links to it and a 301 catches the traffic. I save these four templates as quick options in the publishing system, so newcomers can follow along without an old hand watching over their shoulder.
The checklist and new-site launches
A brand-new site’s first launch is where items get missed most easily, because there’s no history to compare against. My approach is passing through the new site once more before launch: confirm robots isn’t wrongly blocking, sitemap is submitted, core pages’ canonical points to themselves. For the first three months of a new site, scan the page report weekly, because crawling and indexing aren’t stable yet and problems surface fast. Drop the frequency once structure stabilizes. The checklist isn’t static; the new-site phase needs extra add-ons.
Fifteen minutes before launch buys peace of mind after. Keep this checklist by your side, run through it every launch, and basic errors basically stop happening — I’ve held this iron rule for two years, and the number of times I’ve stepped on landmines has visibly dropped.
