Sign in Start free

Ship With a Publish Checklist

Publishing failures are boring and repetitive - a noindex left from staging, a title rewritten by the CMS, an image that never loaded, a canonical pointing at the template. They rarely come from ignorance; they come from the checks living in someone's head. A checklist works only if it is short enough to run every time and covers the things that actually break, which are not the things generic SEO checklists list.

CATEGORY
Content production
FORMAT
ship-with-a-publish-checklist.md
STEPS
6
PRICE
Free - no account
WHEN TO REACH FOR THIS

Use when good drafts keep going live with broken elements and nobody can say who was meant to catch them.

The skill file

ship-with-a-publish-checklist.md 
---
name: ship-with-a-publish-checklist
description: Use when good drafts keep going live with broken elements and nobody can say who was meant to catch them.
---

# Ship With a Publish Checklist

Publishing failures are boring and repetitive - a noindex left from staging, a title rewritten by the CMS, an image that never loaded, a canonical pointing at the template. They rarely come from ignorance; they come from the checks living in someone's head. A checklist works only if it is short enough to run every time and covers the things that actually break, which are not the things generic SEO checklists list.

## What you need first

- access to the live URL after publication, not just the CMS preview
- your last few publishes to see which failures actually recur
- a way to request indexing or confirm crawl

## Method

1. Build the checklist from your own last ten publishes. Include only failures that have actually happened on your stack; generic checklists are long enough to be skipped.
2. View the live page in a logged-out private window. Staging banners, draft notices and access gates are invisible when logged in and this catches most of them.
3. View the rendered source and check the title, canonical and robots meta as rendered, not as entered. CMS templates and plugins commonly overwrite one of the three.
4. Confirm the page is reachable by a crawler - linked from somewhere real and present in the sitemap. Requesting indexing on an orphan page rarely holds.
5. Check the page on a narrow viewport with images disabled. Layout breakage and missing alt text both surface immediately and neither shows in desktop preview.
6. Record the publish date and primary query in a tracking sheet at the moment of publishing, so the first performance review in six weeks has a baseline to compare against.

## What this produces

A short stack-specific checklist run against the live URL, plus a logged baseline for later performance review.

## Where this goes wrong

- Checking the CMS preview instead of the live page, which hides the entire class of template and caching failures
- Copying a fifty-point generic checklist that nobody completes, rather than a ten-point one that gets run
- Publishing without recording the date and target query, so later you cannot tell whether the page decayed or never worked

---

From the QuQi skill library - https://www.quqi.io/skills/ship-with-a-publish-checklist
Free to download · no account, no email

What you need first

  • access to the live URL after publication, not just the CMS preview
  • your last few publishes to see which failures actually recur
  • a way to request indexing or confirm crawl

Method

  1. 01 Build the checklist from your own last ten publishes. Include only failures that have actually happened on your stack; generic checklists are long enough to be skipped.
  2. 02 View the live page in a logged-out private window. Staging banners, draft notices and access gates are invisible when logged in and this catches most of them.
  3. 03 View the rendered source and check the title, canonical and robots meta as rendered, not as entered. CMS templates and plugins commonly overwrite one of the three.
  4. 04 Confirm the page is reachable by a crawler - linked from somewhere real and present in the sitemap. Requesting indexing on an orphan page rarely holds.
  5. 05 Check the page on a narrow viewport with images disabled. Layout breakage and missing alt text both surface immediately and neither shows in desktop preview.
  6. 06 Record the publish date and primary query in a tracking sheet at the moment of publishing, so the first performance review in six weeks has a baseline to compare against.

What this produces

A short stack-specific checklist run against the live URL, plus a logged baseline for later performance review.

Where this goes wrong

  • Checking the CMS preview instead of the live page, which hides the entire class of template and caching failures
  • Copying a fifty-point generic checklist that nobody completes, rather than a ten-point one that gets run
  • Publishing without recording the date and target query, so later you cannot tell whether the page decayed or never worked

Use this skill in your own AI

The download is a plain markdown file with the name and trigger in its frontmatter. Where an assistant supports skills it can load itself, that frontmatter is what it reads to decide this one applies.

Claude Code Save it as ~/.claude/skills/ship-with-a-publish-checklist/SKILL.md and Claude loads it on its own when what you are doing matches the trigger line. Put it in .claude/skills inside a project instead if the whole team should have it.
Claude Upload the file in the skills section of your settings. Once it is there it applies itself in any conversation where the trigger fits, so you do not have to remember it exists.
ChatGPT There is no skills format to install into, so paste the file contents into a Project instruction or a Custom GPT instead. It then applies to every chat in that project rather than only the one you paste it into.
Anything else Paste the markdown into the chat before your question. It works in any assistant, it just has to be pasted again each time.

Questions about this skill

When is a checklist the right answer, and why not use a published SEO one?

When good drafts keep going live with a noindex left from staging, a title the CMS rewrote or a canonical pointing at the template, and nobody can say who was meant to catch it. A fifty-point generic checklist fails because nobody completes it. Ten points built from failures that have actually happened on your stack get run every time.

What do I need before building and running it?

Access to the live URL after publication rather than the CMS preview, your last ten publishes to see which failures recur, and a way to confirm crawl. The preview hides the whole class of template and caching faults, which is most of them. Without the publish history you copy someone else's list and check things your stack has never got wrong.

What does running it produce, and which checks earn their place?

A short stack-specific checklist run against the live URL, plus a logged baseline. Three checks do most of the work: the page viewed logged out in a private window, the rendered source read for title, canonical and robots as served rather than as entered, and a narrow viewport with images disabled. The recorded date and target query is used six weeks later.

What is the mistake that costs me here?

Publishing without recording the date and primary query. When performance is reviewed later you cannot tell whether the page decayed or never worked, and those need opposite responses. The recurring operational error is trusting the CMS preview, where staging banners, draft notices and access gates are all invisible because you are logged in.

More in Content production

Write a Brief That Survives a Writer

Use when you are commissioning a page and cannot personally rewrite it if the draft comes back g...

Edit an AI Draft Into Something Publishable

Use when you have a model-generated draft that reads fine sentence by sentence but is not worth...

Verify Claims Before Publish

Use when a draft contains statistics, quotes or factual assertions that will be visible to custo...

Refresh Decaying Content

Use when pages that used to perform are losing traffic and you need to decide what to update and...