A publishing calendar can tell you when an article is due. It cannot tell you whether the article deserves a public URL. A useful pre-publish check makes an explicit decision: ship, revise, merge with an existing page, or hold. That decision should be based on the reader's task, evidence, technical behavior, and a named owner—not a target number of posts per day.
This checklist is designed for a small editorial team using a CMS and a production website. It separates content review from deployment checks so a clean URL cannot disguise weak content, and a strong article cannot be lost behind a broken route. It is a process guide, not a ranking formula or a promise that Google will index a page.
Write one sentence describing who the page helps, what that person is trying to do, and what information this page can provide that is not already on the site. “Publish an SEO article” is not a reader task. “Help a site owner identify which layer is returning a 503 before changing DNS” is specific enough to guide evidence and structure.
Then check the existing archive. Search the CMS and the public site for the same question, close variants, and pages that could reasonably satisfy the intent. If an existing page already answers the task, improve or consolidate that page instead of creating a second URL. A new title is not proof of a new topic. Look for substantive overlap in the questions answered, examples, and recommended actions.
| Gate | Ask | Pass evidence | Hold if |
| --- | --- | --- | --- |
| Reader task | Can the intended reader and task be stated in one sentence? | A concrete question and intended next action | The brief is only a keyword or traffic target |
| Original contribution | What does this page add beyond generic summaries? | Verified process, original analysis, useful example, or clear limitation | No evidence or accountable source is available |
| Distinct URL | Does another page already answer the same task? | Archive comparison shows a materially different purpose | This is a near-copy or a new title over the same outline |
| Claim review | Can factual and changing claims be traced to a source or owner? | Links, dates, calculations, and reviewer recorded | Facts are unsupported, outdated, or attributed to a fictional expert |
| User outcome | Can a reader take the next step without guessing? | Clear decision, action, prerequisites, and boundaries | The page ends in broad advice or repeated calls to action |
Do not pass a weak draft because it has a high word count. Do not fail a concise utility page only because it is short when it fully completes a narrow task. The right format follows the job.
For every important claim, mark whether it is a sourced fact, an editorial interpretation, or an illustrative scenario. Link primary documentation for platform behavior, official rules, product limits, and definitions. State the page's research date where information can change. If a source does not support the exact wording, narrow the wording instead of adding stronger language.
Examples can make a technical decision easier, but label hypothetical numbers and conditions. Do not present an invented incident, customer, survey, performance result, or quote as site experience. When an article depends on expertise, identify the real reviewer and their actual role; if that person has not reviewed it, do not claim they did. AI assistance can help with drafting, but it is not evidence and does not certify the facts.
A useful review pass asks:
1. Which sentence would cause harm or a costly mistake if it were wrong?
2. Is that sentence supported by a primary source or a named accountable reviewer?
3. Is the source about the same product, jurisdiction, version, and time period?
4. Does the article distinguish what the source says from what the author recommends?
5. What fact would change the recommendation?
If these questions cannot be answered, hold the affected claim or page. A disclaimer at the bottom does not repair a fabricated fact near the top.
Edit for decisions, not for a template
Use a structure that fits the question. A troubleshooting guide may need symptoms, diagnostic order, safe fixes, and verification. A comparison needs criteria, trade-offs, and a “choose this when” conclusion. A policy explainer may need scope, exceptions, and links to authoritative text. Reusing a generic summary–benefits–steps–FAQ outline across every subject makes articles look interchangeable and often leaves decision-makers without a decision.
During editing, remove paragraphs that only restate the headline, duplicate an earlier section, repeat a keyword, or make a claim without evidence. Replace “it depends” with the variables it depends on. Add a worked example only when the assumptions are explicit and the reader can follow the reasoning. If no useful example exists, do not invent one to satisfy a layout rule.
The ending should resolve the opening task: recommend a bounded next action, state when the recommendation does not apply, and identify what remains uncertain. Avoid claims such as “guaranteed rankings,” “instant indexing,” or “this always fixes the problem.” Search engines, vendors, and customer behavior are not under the publisher's control.
Technical release gate: inspect the exact public URL
Before publishing, confirm the post has a stable title, a clean slug, the correct language, a responsible author attribution, and a canonical URL that matches the intended public address. Check that it is not accidentally marked noindex and that no duplicate canonical points elsewhere. Verify every external and internal link, image source, and required disclosure.
After the CMS saves the post, request the public URL without authentication. Check the HTTP status and final redirect target. A successful editor preview does not prove that the production route works. Inspect the rendered page for the correct article body, title, canonical, robots directive, language metadata, and structured data. A generic error page returned as 200 is not a successful release.
Run the same check for the sitemap and robots.txt. Confirm the sitemap contains the canonical article URL once, only after the page is intended to be public and indexable. A sitemap is a discovery signal, not a guarantee that a URL will be crawled or indexed. Do not put drafts, redirects, error pages, or intentionally noindex URLs into an indexable sitemap.
Release decision: ship, revise, merge, or hold
| Decision | Use when | Owner's next action |
| --- | --- | --- |
| Ship | Reader task is answered, claims checked, page is distinct, and production URL is correct | Publish and record the reviewer and release time |
| Revise | The page has a valid purpose but a fixable evidence, clarity, or technical gap | Assign the missing source, section, or route check and retest |
| Merge | Two pages target the same task and one can serve it better | Choose the canonical destination, preserve useful material, and plan redirects |
| Hold | Core facts, permissions, expertise, or an accountable reviewer are missing | Keep it unpublished; state what evidence would unblock it |
Do not turn “revise” into automatic publication after a fixed number of retries. A rejected draft should keep its reason and return to a human editor or a research step. If the system cannot obtain the sources or produce a distinct answer, it should stop rather than repeatedly changing the title and slug.
Worked example: a short article on a broad topic
Suppose a hypothetical draft is titled “Daily SEO checklist.” It has a thousand words, several headings, and a list of routine actions. Those counts alone do not tell the editor whether it adds value. The archive already contains several daily checklists, and the new draft cites no documentation or original observations.
The editor writes down the intended reader task. If the answer is “check whether a newly published page can be crawled,” the broad checklist may be replaced by a focused release procedure: inspect status and canonical, verify robots access, check the sitemap, then use Search Console to inspect the URL. Each step must link to the relevant official documentation and explain what to do when the check fails. If the draft cannot add verified details beyond the existing article, merge it or hold it rather than publishing another list.
This hypothetical example contains no measured performance results. The decision comes from task fit and archive overlap, not a claim that a particular number of headings or words improves ranking. After editing, the owner tests the actual public page and records the URL and release result. If that test fails, the article remains unpublished until the failure is corrected.
Monitor outcomes without pretending to control them
Once a page is live, record its canonical URL, publication date, topic, reviewer, and any external source with a review date. Use Search Console to monitor the page's impressions, clicks, queries, indexing status, and enhancement reports where relevant. Google explains that these reports help site owners understand performance and crawling; they do not guarantee a specific number of visitors.
Compare like with like over a suitable period. One day's movement can reflect reporting delay, seasonality, or a change in search demand. If impressions occur for an unexpected query, inspect whether the page really answers that task before changing the title. If the page gets clicks but users do not take the intended next step, investigate page clarity, service fit, and the conversion path; Search Console alone will not reveal all of those reasons.
For a small set of important URLs, URL Inspection can show Google's current view and support a request to recrawl. For a larger set, maintain a valid sitemap. Google states that crawling can take days to weeks and that repeated requests do not make the same URL crawl faster. Report “submitted” as submitted, not “indexed.”
Review and update articles when their core facts, product interface, policy, or source documentation changes. An update should change material information, not merely refresh the date. If a page no longer serves a reader task, consolidate or retire it with a deliberate redirect or a proper not-found response; do not keep low-value URLs alive just to preserve a count.
A compact editorial handoff
Every proposed article should arrive with a brief containing the audience, one reader task, reason this deserves a new URL, primary sources, known uncertainties, a real internal subject-matter contact, and the intended next action. The editor should return a decision and a specific reason. After publication, the operator records HTTP, canonical, robots, and sitemap checks. These are small steps, but they create traceability from idea to reader outcome.
The process should be allowed to say “no.” A realistic content system is not measured only by how many drafts it produces. It is measured by whether it withholds unsupported or repetitive pages, preserves a clear archive, and releases content that a reader can use. A lower publication count during a cleanup period is preferable to training readers and search engines to expect another near-identical page.
Scope and sources
This article describes a general editorial workflow, not a Google ranking formula or a legal suitability assessment. It uses a hypothetical example and makes no claim about Favokres customer research or traffic results. It was prepared with AI assistance; no human subject-matter review is claimed.
Nine years in software — backend and frontend with equal weight, not a slogan. I also spent a year in IT operations, the kind of work that makes you respect uptime.
The same hands that ship APIs come from graphic design through modeling, 2D and 3D. I care how a thing looks and how it holds together.
Favokres is my personal digital hub: AI-assisted publishing, SEO, a forum, and a shop. An autonomous brain keeps the site moving so pages stay useful, not frozen.
October 19, 2026 at 10:10 PM11 min read
