Publishing an article is not the same as finishing a draft. Before a page goes live, someone needs to verify that it serves the intended searcher, fits the site’s existing structure, works as a page rather than just as a document, and has passed the right review gates.
A last-minute keyword check will not catch a duplicate URL, a misleading internal link, an unapproved business claim, a mobile layout problem, or a publication setting that does not match the intended page. This SEO pre-publishing checklist turns those concerns into a documented release decision. It covers page purpose and on-page relevance, links, technical settings, mobile readiness, issue ownership, and checks that can only happen after publication.
Use it when an article has been drafted but has not yet been approved for release. The goal is not to produce a perfect score. It is to establish what must be true before publishing, record the evidence, assign unresolved work, and make the approval decision visible.
Define the page’s job and the release standard
A checklist is useful only when it is connected to a decision. If the team has not agreed what the page is supposed to do, every later check becomes subjective. A title may be accurate but still too broad for the intended audience. A new article may be well written but still be the wrong action if an existing page already serves the same role.
Record the page context first
Before reviewing headings, links, or metadata, record:
Searcher job: What is the reader trying to understand, compare, decide, or do?
Intended audience: Who is the page written for, and what context can it assume?
Page role: Is it an explanation, procedure, comparison, landing page, support page, or another role?
Business context: Why is the page relevant to the organization and its content plan?
Primary reader action: What should a satisfied reader be able to do or decide?
Existing URL context: Which current pages address a related need, and how do their roles differ?
Release owner and approver: Who resolves issues, and who can approve the content, URL, technical settings, claims, and publication?
The page role matters because the same phrase can imply different content decisions. A process query might be served by a practical guide, while a product query might require a product page or comparison. A draft should not be evaluated only by whether it contains a target phrase.
Before treating the article as a new-page opportunity, inspect the site’s existing URL and page-role inventory. The relevant action may be to improve an existing page, consolidate overlapping pages, investigate the relationship further, or postpone publication rather than create another URL.
| Possible action | When to consider it | Evidence still needed |
|---|---|---|
| Improve | An existing page has the right role but needs clearer coverage or updated information. | The current page’s gaps and proposed changes. |
| Create | No existing page adequately serves the defined searcher job. | The page-role inventory and reason a new URL is distinct. |
| Consolidate | Several pages overlap enough to create confusion or maintenance risk. | The overlapping URLs, purposes, and proposed destination. |
| Investigate | The relationship between the draft and current pages is unclear. | A named owner and a specific question to resolve. |
| Postpone | Evidence, ownership, business context, or release conditions are insufficient. | The missing input and a condition for reconsideration. |
This is not a universal ranking of actions. It prevents a completed draft from creating an automatic obligation to publish it.
Define what “ready” means
A practical release standard distinguishes a launch blocker from a reasonable follow-up item. An unresolved URL decision is different from a minor wording improvement, while an unverified business claim may need to stop publication.
Record the standard before the final review. At minimum, specify:
Launch blockers: Issues that must be resolved before publication.
Required revisions: Changes needed for accuracy, relevance, or clarity.
Acceptable follow-ups: Lower-risk improvements with an owner and review date.
Unknowns: Questions that cannot be resolved from available evidence.
Not applicable checks: Items considered and excluded, with a reason.
Approval status: Draft, in review, changes requested, approved, scheduled, or postponed.
A useful stopping condition might be: “Publish when the searcher job and page role are approved, no blocker remains, the URL and technical settings have been checked, the mobile review has no unresolved release-impacting defects, and the accountable reviewer has approved the change.” This is more useful than “publish when the SEO checklist is complete.”
Keep an evidence record
A score can make a review look precise while hiding uncertainty. Use an evidence register that separates observations from interpretations and proposed actions.
| Field | Example record |
|---|---|
| Observation | The draft links to an older guide whose current page purpose is unclear. |
| Interpretation | The link may be useful, but its destination and relationship require review. |
| Unknown | It is not confirmed whether the older guide is being retained. |
| Proposed action | Confirm the destination and decide whether the link should remain, change, or be removed. |
| Owner | Content owner, with technical owner consulted if the destination changes. |
| Stopping condition | Destination and page relationship are confirmed before approval. |
| Status | Open. |
This prevents an item from being marked complete merely because somebody looked at it.
Verify on-page relevance and completeness
The on-page review asks whether the article communicates its purpose clearly and whether its important elements agree. It is not a request to repeat a keyword in every heading. It is a check that the title, introduction, structure, examples, metadata, and supporting context describe the same page.
Read the article once as a target reader would, then review the page elements separately. This helps distinguish an unclear article from a page that contains expected fields but makes no coherent promise.
Review the page promise and structure
Check the following against the recorded searcher job:
The title describes the subject and does not promise more than the article delivers.
The H1 identifies the page clearly and agrees with the title and page role.
The introduction explains the reader’s problem, scope, and expected takeaway.
The headings follow a useful sequence rather than presenting disconnected keyword variations.
The body copy answers the intended question with enough explanation, examples, criteria, or steps.
The examples fit the audience and do not introduce unsupported business, product, or performance claims.
The conclusion gives a bounded next action instead of implying that publication produces a result.
Ask a reviewer who was not the primary writer to summarize the article’s job in one sentence. If that summary does not match the recorded purpose, investigate the mismatch before editing isolated headings.
Related terms are useful when they clarify the subject, distinguish subtopics, or connect the page to a broader information structure. Review coverage by meaning: does the article address the relevant decisions and relationships, or does it merely contain related phrases?
Check visible copy, metadata, and context together
The meta description should describe the article accurately and concisely. It can explain the workflow or practical outcome covered by the page, but it should not promise rankings, traffic, conversions, or another result the article cannot establish.
Where applicable, also verify that:
Images have a clear purpose rather than being decorative clutter.
Captions explain information readers need to interpret an image or illustration.
Alternative text suits the image’s purpose and is not a keyword list.
Tables have meaningful headings and remain understandable without visual assumptions.
Author, organization, or business context is accurate and approved.
Product descriptions and business claims match the approved source of truth.
Visible copy, metadata, and the proposed URL do not imply different subjects.
A page can be technically valid and still be unsuitable for release if its visible claims lack business approval.
Use a review table, not an unexplained score
This illustrative table is not a universal scoring system. Completing every row does not establish that a page will be indexed or perform in search.
| Check | Evidence to record | Owner | Status | Release impact |
|---|---|---|---|---|
| Searcher job is clear | One-sentence page purpose and intended reader | Content owner | Open / pass | Blocker if unclear |
| Title and H1 agree | Final title, H1, and material differences | Content owner | Open / pass | Revision if misleading |
| Scope matches page role | Sections and examples mapped to the intended role | Content reviewer | Open / pass | Blocker if the draft serves a different job |
| Topic coverage is natural | Missing concepts or unnecessary repetitions | Content reviewer | Open / pass | Classify by risk |
| Meta description is accurate | Proposed description and outcome it describes | Content owner | Open / pass | Revision if it overpromises |
| Claims have an owner | Product, business, factual, and illustrative claims reviewed | Subject or business owner | Open / pass | Blocker for unapproved consequential claims |
| Supporting content is usable | Images, captions, tables, and alternative text reviewed | Content or design owner | Open / pass / N/A | Classify observed defects |
| Reader action is appropriate | Next step fits the page purpose and audience | Content owner | Open / pass | Revision if misleading or out of scope |
Write evidence another person can inspect. “Looks good” does not identify what was checked; “title describes the checklist, H1 matches, and introduction states the review areas” does.
Audit links and URL relationships
Links create pathways through the site and failure points. Check not only whether links are present, but whether each helps the reader, points to the intended destination, and fits the site’s page relationships.
Review internal links for purpose
For every internal link, record the destination, reason for inclusion, and expected reader transition. Ask:
Does the destination resolve to the intended current URL?
Does it add context, evidence, a next step, or deeper explanation?
Is the anchor text understandable without guessing what follows?
Does the link fit the sentence naturally?
Is the destination’s page role compatible with the article’s purpose?
Would a reader be confused by a different audience, date, or level of detail?
Is the link still appropriate if the destination is improved, consolidated, or retired?
Do not add links merely to increase a count. A smaller set of relevant links is easier to review and maintain than a dense set of weak pathways.
For a broader method of mapping page roles and deciding when to improve, consolidate, or create, see how to build topic clusters and internal link architecture. The same role-first reasoning applies here: ask what relationship the page should have with the rest of the site.
Check external destinations carefully
Confirm that each external destination is relevant to the surrounding claim or explanation and appropriate for the audience. If attribution, permission, or another editorial requirement applies, record it separately.
Do not treat a linked source as automatic proof. A destination may provide background, an example, or a data point, but the article should distinguish what the source supports from what remains an interpretation. If the destination changes or no longer supports the statement, make a new decision.
Confirm the proposed URL does not duplicate an existing role
The URL review is more than a slug review. Confirm that:
The proposed path reflects the approved page role.
The URL is distinct from existing pages serving the same searcher job.
The team has considered improving an existing URL instead.
Any consolidation or redirect decision has an accountable owner.
The final URL is consistent across the draft, metadata, navigation, and publication record.
The URL does not rely on an unresolved temporary naming decision.
Record missing links, redirects, broken destinations, uncertain ownership, and unresolved URL relationships as separate findings.
| Link or relationship | Intended purpose | Destination status | Risk | Owner | Next action |
|---|---|---|---|---|---|
| Internal guide | Give readers a deeper procedure | Destination exists; role needs confirmation | Medium | Content owner | Confirm role before approval |
| Existing related article | Determine whether the draft duplicates it | Relationship unresolved | High | SEO manager | Choose Improve, Create, Consolidate, Investigate, or Postpone |
| External reference | Support a specific explanation | Destination reviewed | Low | Writer | Retain with accurate attribution |
| Proposed URL | Give the new page a stable location | Not approved | High | SEO and business owner | Approve URL before publication |
The statuses are working records, not universal thresholds. Define what each risk level means for the team and record the reason.
Check technical publication settings
Technical checks should confirm that the publishing configuration matches the approved page decision. They should be performed in the environment that will actually publish the page, not assumed from a draft editor.
Verify the final URL and indexability intent
Review the final URL, slug, publication state, and indexability-related directives in the publishing system. Confirm with the accountable technical reviewer that:
The final URL is approved, not temporary or duplicated.
The publication state is understood: draft, scheduled, preview, or live as applicable.
Indexability directives match the release decision.
The canonical setting, where used, represents the intended primary version.
The title and relevant metadata map to the fields the site actually renders.
Parameters, trailing-slash differences, or other variants are not creating an unintended second version.
Any redirect decision has been reviewed rather than inferred from a default.
These are verification questions, not instructions to change settings blindly. If the team cannot establish which value the system will render, record an unknown and assign it to the appropriate owner.
Review structured data without treating it as a guarantee
If structured data is relevant to the page type, check that it is applicable, valid in the connected system, and consistent with visible content. Do not add fields solely because they might produce a richer search representation, and do not describe valid markup as a ranking guarantee.
Ask why the markup applies, whether it describes visible and accurate content, whether it has been reviewed in the publishing environment, and what happens if it is omitted, rejected, or rendered differently.
Confirm discovery and publication behavior
Check how the website handles sitemap inclusion, internal navigation, publication state, and deployment. The exact behavior depends on the connected system, so identify the observed configuration rather than relying on a general assumption.
Review whether:
The live page is represented in the intended navigation or contextual pathway.
Sitemap handling is understood for the publication state and URL type.
A preview or draft cannot be mistaken for the final page.
Deployment changes are identifiable and attributable.
Failure handling and recovery steps are known.
Permissions support the approved change without bypassing the review gate.
If the article is published through a connected repository, treat the repository change as consequential. LUUMERA connects to GitHub and publishes approved articles by committing them directly to a site repository. That workflow does not remove the need to verify the repository, URL, technical settings, business claims, and approval status before publication.
For further discussion of repository contracts, validation stages, and recovery considerations, see how to automate website publishing with GitHub. Use that workflow as an implementation input, not as a reason to skip release review.
Name accountable technical owners
| Decision | Accountable owner | Required evidence | Approval gate |
|---|---|---|---|
| Page role and URL | SEO manager or content lead | Existing URL review and approved role | Before URL is finalized |
| Product or business claims | Product or business owner | Approved source of truth | Before content approval |
| Indexability and canonical settings | Technical or SEO owner | Rendered or system-level review | Before scheduling or publication |
| Structured data | Technical or SEO owner | Applicability and implementation check | Before release if used |
| Repository or deployment change | Engineering or publishing owner | Change record and recovery path | Before consequential change |
| Publication | Named release approver | Completed evidence register | Final gate |
The person who notices an issue is not automatically the person authorized to approve the consequential change.
Test the article on mobile and at realistic widths
A desktop review cannot represent every reading and interaction condition. Mobile readiness is an inspection of the actual page experience at representative widths, not an assumption that a responsive template is correct everywhere.
Use a defined device or viewport for each observation and record what was seen. Avoid inventing a universal device list or performance threshold when the current technical requirement has not been established.
Inspect reading and layout behavior
Review the rendered article for:
Heading wrapping that makes the structure difficult to follow.
Paragraphs that become unusually dense or hard to scan.
Lists whose spacing or numbering becomes confusing.
Tables that require excessive horizontal movement or lose their headings.
Images that are clipped, distorted, or disconnected from captions.
Embedded content that creates overflow or unusable controls.
Links and buttons that are difficult to identify or use.
Sticky elements or overlays that obscure content.
Navigation behavior that prevents the reader from reaching or leaving the article.
Tables deserve special attention in a checklist article. The appropriate fix might be a simpler table, a stacked record, shorter labels, or an explanatory list. Do not preserve a table merely because it is convenient for the author.
Separate observation from performance assumptions
Record observed rendering, image, or interaction issues with the device, viewport, environment, and method used. Do not turn one observation into a universal performance claim. Mobile performance, accessibility behavior, interaction requirements, and technical thresholds may depend on the site and current implementation standard.
| Check | Viewport or device used | Observation | Interpretation | Release impact | Owner |
|---|---|---|---|---|---|
| Table readability | Representative narrow viewport | Three columns require repeated horizontal movement | The checklist is difficult to scan | Required revision | Content and design owner |
| Heading wrapping | Representative narrow viewport | One heading wraps into four lines | Review whether wording obscures hierarchy | Follow-up or revision | Content owner |
| Link interaction | Representative mobile device | Links are visible and usable in the observed section | No defect observed in this test | No blocker identified | Reviewer |
| Image rendering | Representative mobile device | Image appears clipped | Rendering needs correction or removal | Blocker if information is lost | Technical owner |
“No defect observed” is narrower and more honest than “mobile optimized.” It records the scope of the test without claiming every environment was validated.
Run a release review and classify unresolved issues
The final review converts observations into an action decision. It should identify what stops publication, what can be scheduled, and what remains unknown because evidence is missing.
Classify every finding
Use a consistent set of categories:
Blocker: Publication should not proceed until the issue is resolved or formally accepted by the accountable approver.
Required revision: The article or configuration needs a change before it meets the release standard.
Acceptable follow-up: The issue is documented, owned, and scheduled without unacceptable release risk.
Unknown: The team lacks enough evidence to classify the issue confidently.
Not applicable: The check was considered and does not apply, with the reason recorded.
An unknown is not a pass. If nobody knows which URL will be rendered, whether an important claim is approved, or whether the intended setting will apply, obtain evidence or escalate the decision.
Use an action matrix
| Finding | Evidence | Risk or release impact | Owner | Proposed action | Stopping condition | Status |
|---|---|---|---|---|---|---|
| Existing page may overlap | Two pages appear to address the same searcher job | High; new URL could create an unclear relationship | SEO manager | Choose Improve, Create, Consolidate, Investigate, or Postpone | Approved page relationship and URL decision | Open |
| Product statement lacks approval | Claim appears in visible copy but source is not recorded | High; business review incomplete | Product owner | Confirm, revise, or remove the claim | Approved wording or removal | Open |
| Mobile table is difficult to scan | Narrow viewport review shows repeated horizontal movement | Medium or high depending on information loss | Content/design owner | Simplify or redesign | Reviewer confirms usable presentation | Open |
| Repository change is ready | Content is prepared for the connected repository | Consequential change | Publishing owner | Verify change, permissions, and approval | Named approver authorizes publication | Open |
| Minor wording improvement | Sentence is accurate but could be clearer | Low | Writer | Revise or schedule follow-up | Owner and review date recorded | Open |
The impact classification should reflect the team’s release standard and the specific page. It is not an objective score that predicts search performance.
Require approval for consequential decisions
Human approval should remain explicit for:
URL selection, redirects, consolidation, or changes to an existing page role.
Product, business, legal, or other consequential claims.
Repository, deployment, or publication changes.
Technical settings that affect how the page is represented or exposed.
Exceptions to the agreed release standard.
Automation can help collect evidence, apply repeatable checks, prepare records, and move approved content through a workflow. It does not remove judgment, maintenance, permissions, or failure recovery.
LUUMERA researches SEO opportunities, writes content, and supports publishing through connected tools. It can also create articles using SEO research, business context, and editorial style. These capabilities can support a lean team’s workflow from opportunity research through drafting and review, but an assisted article still needs editorial, factual, business, URL, technical, and approval checks before it is treated as ready for publication.
A practical way to introduce a new workflow is to run a bounded pilot on one representative article. Define the checklist, record the evidence, note unclear checks, and revise the release standard before applying it across a larger queue.
For a comparison of review gates, operational control, and bounded workflow adoption, see manual vs. automated content publishing: which workflow fits your team. The relevant question is whether the team can preserve accountability and recover from an error in its operating environment.
Separate post-publication monitoring from pre-publication checks
Some checks cannot be completed honestly until the page is live. A pre-publication review can confirm intended settings and available evidence, but it cannot guarantee how the rendered page will behave in every context or what search systems will observe later.
Define the first live-page checks
After publication, assign an owner and review date for:
Confirming that the live URL renders the approved content and metadata.
Checking that links on the rendered page lead to intended destinations.
Reviewing whether the page appears in expected site pathways.
Inspecting crawl or indexation observations where an appropriate evidence source is available.
Reviewing relevant Google Search Console data where available and appropriate.
Monitoring for broken links, duplicate versions, or deployment differences.
Confirming that technical corrections have been made and rechecked.
These are observations about a live page, not promises about future performance. Search data, ranking observations, impressions, clicks, or competitor visibility may help investigate what happened. None proves that a page will achieve a particular result or that a future change will produce one.
| Signal or observation | What it can help investigate | What it cannot establish by itself |
|---|---|---|
| Rendered live page | Whether approved content and visible settings appear as expected | That the page will be discovered or perform in search |
| Link check | Whether observed links resolve at the time of review | That every destination will remain available |
| Crawl or indexation observation | Whether a technical or discovery question merits investigation | Guaranteed indexing or future visibility |
| Search Console observation | How available search data relates to the page after publication | Guaranteed rankings, traffic, conversions, or causation |
| Reader or team feedback | Whether people encountered clarity, layout, or interaction problems | A complete measure of search demand or business impact |
Document the date, source, page, and interpretation for any signal used in the review. Avoid turning a directional signal into a release promise.
Set a review trigger and maintenance owner
The post-publication plan should state:
Review date: When the first live-page check will occur.
Owner: Who will inspect the page and record the result.
Trigger: What observation causes correction, escalation, or investigation.
Correction path: Who can change the content, URL, technical configuration, or repository record.
Closure condition: What evidence is needed to mark the finding resolved.
This keeps publication from being treated as the end of the workflow and prevents open issues from disappearing once the article is live.
Keep a complete pre-publication operating record
A useful release record preserves the page decision, evidence, ownership, and approval status. It can contain:
Page identity: Draft title, proposed URL, page role, and content owner.
Searcher job: Intended audience, question, decision, or task.
Existing-page review: Related URLs and the selected Improve, Create, Consolidate, Investigate, or Postpone action.
On-page review: Title, H1, introduction, structure, scope, metadata, examples, supporting content, and claims.
Link review: Internal and external destinations, anchor text, redirects, missing links, and ownership.
Technical review: Publication state, URL, indexability intent, canonical setting, structured-data applicability, sitemap or navigation behavior, and deployment considerations.
Mobile review: Device or viewport, observations, defects, and required changes.
Action matrix: Findings, evidence, owners, proposed actions, stopping conditions, and statuses.
Approval: Named reviewer, date, exceptions, and final decision.
Post-publication plan: Live-page checks, review date, monitoring owner, and correction path.
A final decision might read:
Decision: Approved for publication. The page role and URL are confirmed, blocker findings are closed, the technical owner has verified the intended publication settings, the mobile review found no unresolved release-impacting defects, and the named approver authorized publication.
Or:
Decision: Postpone. The draft overlaps with an existing page, and the team has not approved whether to improve, consolidate, or create a separate URL. No publication change is authorized until the page relationship and owner are confirmed.
Both records are more useful than a generic “SEO checklist complete” label because they explain the decision and its limits.
The smallest defensible next action
Do not begin by applying a long checklist to every article in the queue. Select one representative draft and run the workflow end to end:
Define the searcher job, audience, page role, business context, and stopping condition.
Review existing URLs before confirming that the draft should become a new page.
Check on-page relevance, claims, links, technical settings, and mobile behavior.
Record observations separately from interpretations, unknowns, and proposed actions.
Classify findings and assign owners, reviewers, and review dates.
Obtain explicit approval before URL, business, repository, technical, or publication changes.
After release, compare the live page with the approved record and schedule the next review.
If a lean team needs help connecting opportunity research, content planning, writing, review, and publishing, LUUMERA can serve as an optional support layer in that broader workflow. The release standard should remain independent of the tool: the article is ready only when the evidence, ownership, technical review, and approval requirements have been satisfied.
The operating rule is simple: publish when the intended page is clear, important settings and pathways are verified, unresolved risks are owned, and an accountable person has approved the release—not merely when the draft contains the target topic.