A pre-publish on-page checklist for editors

A publishing checklist is most useful when it follows the order in which an editor can make decisions. There is little value in polishing a description for a page whose purpose is still unclear. Start with the reader and the content, then inspect the supporting elements and the rendered result. That order keeps small technical details from distracting attention from a missing answer.

The checklist below is intended for a normal editorial page, such as a guide, an explanation, or a product-related article. Adapt it to your publishing system and approval process. Some checks belong to an editor; others may need a developer or product expert. Record unresolved questions with an owner instead of marking them complete because the publishing deadline is close.

1. State the reader's task

Write down who should use the page and what they should be able to do after reading it. “Understand the differences between two subscription options” is a useful task. “Read about our product” is too broad to guide a review. The task gives you a standard for deciding what belongs in the opening, which details need evidence, and what the next step should be.

Read the draft against that statement. If a comparison page never explains the differences that affect a purchase, it needs more than a new heading. If a tutorial assumes access the intended reader will not have, add the prerequisite or change the audience. Fix those gaps before spending time on wording that merely makes an incomplete page sound more finished.

2. Check accuracy and useful detail

Identify facts that someone might rely on: product availability, steps in an interface, dates, limitations, and quoted claims. Verify them with the appropriate source or reviewer. A screenshot can become outdated even when the surrounding prose still reads well. A copied specification can be accurate for one model and wrong for another. Ask for confirmation where the draft exceeds the editor's knowledge.

Look for missing context as carefully as incorrect statements. A price example may need a billing period. A procedure may need an account role. A recommendation may depend on the reader's equipment or location. The goal is to make the page usable by its intended audience. More words are helpful only when they answer a question the reader needs resolved.

3. Read the headings as an outline

Scan the main heading and section headings without reading the paragraphs. Do they describe the page and show a reasonable sequence? For a tutorial, the sequence should support the task. For a comparison, the headings should make the criteria easy to find. Rename vague labels where a specific description would help someone navigate.

Check the heading levels in the actual document structure, not just their appearance in the editor. A bold paragraph is not necessarily a heading, and a small-looking heading may still have a high structural level. Use the content system's heading controls deliberately. Ask a developer about template problems instead of working around them with empty headings or repeated line breaks.

4. Compare title, introduction, and body

The page title should describe the content someone will reach. The opening should confirm that subject and explain enough scope to orient the reader. Google's documentation on title links advises clear, descriptive titles and warns against repetitive boilerplate. It also explains that the displayed search title is generated automatically, so an editor cannot promise an exact search presentation.

Write the title for this page rather than copying a neighboring page and replacing one word. Then compare the introduction with the body. If the introduction promises a checklist, provide a usable checklist. If it promises examples, make the examples specific enough to teach something. Remove promises that the page does not fulfill, or add the material needed to fulfill them.

5. Follow every meaningful link

Open the links that support the main task. Check that each destination exists and contains the information implied by the link text. An internal link can be technically valid while leading to an outdated article or a page intended for a different product. Confirm the destination in context, particularly when a draft was assembled from older material.

Review the anchor text at the same time. A phrase such as “account permission requirements” gives a reader more information than “click here.” Avoid forcing a search phrase into a link when it makes the sentence awkward or misrepresents the destination. For downloadable files, explain what the reader will receive and consider whether the file itself needs a separate accessibility review.

6. Inspect the images where they appear

Check that each image adds information or appropriate context. A screenshot should show the relevant interface clearly at the size it will be displayed. If a detail is too small to read on a phone, consider a tighter crop or a separate explanatory image. Confirm that the image belongs to this version of the content and that you have the right to use it.

Write alternative text according to the image's purpose. Describe the information a reader needs from an informative image; avoid repeating a nearby caption word for word without a reason. Pure decoration may need empty alternative text. If the image contains a complex diagram or essential instructions, provide an equivalent explanation in the page rather than trying to pack the entire lesson into a short attribute.

7. Review metadata and structured data

Check the description field for a concise, accurate summary of the page. Treat it as a description of what is actually available, not a place to list every related term. Review any social preview title and image as well. Shared links can be a reader's first encounter with the page, so those fields should not refer to an old draft or a different topic.

If the template includes structured data, confirm that it represents content visible on the page and uses the appropriate type. An editor should flag unexpected review ratings, product claims, or dates rather than assuming that a plugin has made them correct. Technical validation and editorial accuracy are separate checks. A valid structure can still describe something the page does not actually offer.

8. Check publication settings with the right owner

Confirm the intended URL and whether the page should be public. If the draft replaces an existing page, coordinate any redirect and internal link changes. Ask the technical owner to verify indexing or canonical settings when there is uncertainty. Do not casually remove a restriction that may exist for a business, privacy, or duplication reason.

Google's SEO Starter Guide provides a broader reference for making content understandable and accessible to search engines. Use it to support a conversation with the technical team, not as a reason to change unfamiliar settings blindly. Publishing systems differ, and a setting that looks harmless can affect more than one page.

9. Read the rendered page on a phone

Preview the page outside the editing interface. Check narrow and wide screens, follow the main action, and look for clipped tables, oversized images, or a heading separated from the paragraph it introduces. Confirm that navigation and any form controls can be used with a keyboard. The draft may be accurate while the template makes important information difficult to reach.

Read the first screen as a new visitor would. Can you identify the subject and begin the task without dismissing a pile of interruptions? Then scroll through the rest of the page. Look for repeated blocks, accidental placeholder text, and captions attached to the wrong image. These are ordinary publishing mistakes that a source-only review can miss.

10. Leave a useful handoff

Before release, record who approved the facts, who resolved technical questions, and which items remain open. A short note is enough if it identifies the page and the decision. Give the page a future review trigger where appropriate, such as a product release or a policy change. That is more actionable than an arbitrary promise to keep everything fresh.

Apply this sequence to the next page you publish. Keep the checks that catch real problems in your workflow and clarify any that teammates interpret differently. A checklist should help editors make sound decisions consistently. It does not guarantee rankings, but it can make the finished page easier to understand, maintain, and use.