WordPress SEO checklist: 23 verifiable launch and maintenance checks

Why check this

A test result is ambiguous when the environment, responsibility, or reader job is unknown. Ownership also determines who can act when a launch blocker appears.

Example

Production: example.com; staging: noindex and access-controlled; technical owner: A; editorial owner: B; launch approver: C.

How to verify it

1. Record production and staging URLs.
2. State the site's main reader job and conversion or public-service goal.
3. Assign technical, editorial, privacy, and release owners.
4. Record the launch or review date and escalation contact.

Evidence to record

• Production URL
• Environment boundary
• Named owners
• Review date

Common mistakes

• Testing staging and reporting the result as production.
• Giving every task to an undefined site administrator.

Useful tools

• Site brief
• Release record

Why check this

A reused domain can carry old URLs, links, reputation problems, or ownership gaps. A domain name alone does not create rankings or authority.

Example

The migration record lists the registrar owner, renewal date, prior snapshots, legacy URLs requiring redirects, and Search Console security/manual-action status.

How to verify it

1. Confirm registrar ownership, renewal, DNS access, and recovery contacts.
2. Review archived versions and known legacy URLs.
3. Inspect available backlink and Search Console history without assuming every old link is harmful.
4. Document redirects, removals, and unresolved risks.

Evidence to record

• Ownership confirmed
• Renewal date
• Legacy URL inventory
• Unresolved risks

Common mistakes

• Choosing a domain only because it contains a keyword.
• Buying an expired domain without reviewing its prior use.

Useful tools

• Registrar
• Internet Archive
• Search Console
• Link data source

Why check this

A hosting label such as shared, VPS, or managed does not prove speed or resilience. Evidence must come from the deployed environment and its operating limits.

Example

The host record includes PHP and database versions, HTTPS status, uptime monitoring, backup retention, resource limits, support route, and a tested representative page.

How to verify it

1. Confirm supported WordPress, PHP, database, and TLS versions.
2. Record resource limits, caching layers, backup ownership, and log access.
3. Test a representative uncached and cached request.
4. Document the support and incident escalation path.

Evidence to record

• HTTPS
• Software support state
• Availability evidence
• Backup and log access

Common mistakes

• Treating a premium plan name as performance evidence.
• Adding a CDN before locating the actual bottleneck.

Useful tools

• Hosting dashboard
• Site Health
• Uptime monitor
• Browser diagnostics

Why check this

These settings affect visible identity, dates, routing, discussion, feeds, and whether WordPress asks search engines not to index the site.

Example

Production uses the correct timezone and static homepage; staging is access-controlled and noindex; the production visibility checkbox is cleared.

How to verify it

1. Review Settings > General, Reading, and Discussion.
2. Confirm the homepage and posts-page assignments.
3. Verify the production Search Engine Visibility state.
4. Test the public output and record the setting date.

Evidence to record

• Title and language
• Timezone
• Homepage mode
• Visibility state

Common mistakes

• Assuming the visibility checkbox blocks public access.
• Launching with the staging timezone or placeholder tagline.

Useful tools

• WordPress Settings
• Public page test

Why check this

WordPress supports several valid permalink structures. Stability, clarity, internal linking, canonicals, and redirects matter more than declaring one preset universally best.

Example

New posts use /descriptive-slug/; an old dated URL returns one permanent redirect to its matching current URL.

How to verify it

1. Review Settings > Permalinks and sample public URLs.
2. Choose a structure that fits the content model and can remain stable.
3. Inventory existing indexed or linked URLs before changing the structure.
4. Test redirect targets, status codes, canonicals, and internal links.

Evidence to record

• Stable pattern
• Redirect status
• Final canonical
• Broken internal links

Common mistakes

• Changing live permalinks without a redirect map.
• Removing useful words merely to make every URL short.

Useful tools

• WordPress Permalinks
• Crawler
• HTTP checker

Why check this

WordPress roles grant different capabilities. Unnecessary administrator access increases operational and security risk.

Example

Writers are Authors, the managing editor is Editor, two named administrators use MFA, and an unused contractor account is removed.

How to verify it

1. Export or review the user list and last known owner.
2. Map each account to the minimum required WordPress role.
3. Remove or disable stale and shared accounts.
4. Protect privileged accounts and document emergency access.

Evidence to record

• Administrator count
• Stale accounts
• Shared accounts
• MFA coverage

Common mistakes

• Giving contributors administrator access for convenience.
• Leaving accounts owned by former contractors.

Useful tools

• WordPress Users
• Password manager
• MFA provider

Why check this

The number of plugins is not a performance score. Code quality, overlap, update state, output, queries, assets, and maintenance ownership determine the risk.

Example

The inventory names the owner and purpose of each active component, removes two duplicate schema features, and records the tested rollback.

How to verify it

1. List active and inactive themes, plugins, must-use plugins, and drop-ins.
2. Record each component's purpose, owner, support state, and output.
3. Identify duplicate features, abandoned packages, and unnecessary front-end assets.
4. Back up, test removal, and record the result before production cleanup.

Evidence to record

• Unsupported components
• Duplicate features
• Front-end assets
• Named owner

Common mistakes

• Replacing one page builder with another without measuring output.
• Deleting a plugin before confirming its data and rollback path.

Useful tools

• Plugins screen
• Site Health
• Query Monitor on staging
• Browser network panel

Why check this

Keyword lists do not resolve overlapping pages, unclear intent, or missing information. Distinct page jobs make consolidation and internal linking decisions possible.

Example

A category page helps readers choose a path; a guide completes a task; a tool produces an output. Two pages with the same job are reviewed for merge or repositioning.

How to verify it

1. Inventory important URLs and templates.
2. Write one reader-job sentence for each page type.
3. Mark overlapping, thin, obsolete, or orphaned pages.
4. Choose keep, improve, merge, redirect, noindex, or retire with an owner.

Evidence to record

• Pages with defined jobs
• Overlaps
• Orphans
• Action owner

Common mistakes

• Creating a page for every keyword variation.
• Keeping duplicate archives indexable without a purpose.

Useful tools

• Content inventory
• Search Console
• Crawler

Why check this

Google can build title links and snippets from several page signals and may rewrite either. Google documents no fixed title or meta-description length limit.

Example

The title identifies the page and site without boilerplate repetition; the description explains the decision and boundary in plain language.

How to verify it

1. Inspect the rendered title element and meta description.
2. Compare them with the visible H1 and page purpose.
3. Remove duplicate, vague, stuffed, or stale wording.
4. Preview likely display and record rewrites as observations, not failures.

Evidence to record

• Unique titles
• Useful descriptions
• Rendered HTML
• Promise alignment

Common mistakes

• Enforcing a fixed character limit as a ranking factor.
• Writing metadata that promises information absent from the page.

Useful tools

• SERP Snippet Preview
• Browser source
• Crawler

Why check this

Headings are structural labels, not a keyword-placement quota. The public hierarchy should reflect the actual content and remain understandable when read as an outline.

Example

One visible H1 names the page; H2 sections answer major questions; H3 headings divide subsections without skipped levels used only for styling.

How to verify it

1. Extract or inspect the rendered heading outline.
2. Confirm the main heading matches the page job.
3. Rewrite vague headings and correct hierarchy used for visual sizing.
4. Test keyboard and screen-reader navigation on a representative page.

Evidence to record

• Visible main heading
• Logical outline
• Descriptive section labels
• Accessibility check

Common mistakes

• Using headings only to make text large.
• Repeating the same keyword in every heading.

Useful tools

• Browser accessibility tree
• Heading outline extension
• Manual review

Why check this

Internal links help people navigate and help search engines discover and understand pages. Link volume or exact-match anchors are not a substitute for relevance.

Example

A launch guide links from the section about metadata to the snippet preview tool using a descriptive phrase, not 'click here'.

How to verify it

1. Find important pages with few or no internal links.
2. Add links from contextually relevant pages and navigation surfaces.
3. Use anchor text that describes the destination without stuffing.
4. Crawl the site and fix broken, redirected, JavaScript-only, or misleading links.

Evidence to record

• Orphan pages
• Broken links
• Redirecting links
• Relevant referring pages

Common mistakes

• Adding sitewide links to every page.
• Using identical keyword anchors mechanically.

Useful tools

• Crawler
• Search Console Links report
• Manual path test

Why check this

Image performance and accessibility depend on the delivered bytes and meaning, not a single preferred format or filename formula.

Example

A 1200×675 featured illustration has responsive variants, intrinsic dimensions, descriptive alt text, a useful caption when attribution or context is needed, and is not lazy-loaded when it is the LCP image.

How to verify it

1. Measure rendered and intrinsic dimensions on mobile and desktop.
2. Compare delivered bytes and visual quality across supported formats.
3. Write alt text for informative meaning and use empty alt for decorative images.
4. Verify responsive srcset/sizes, aspect ratio, lazy loading, and LCP behavior.

Evidence to record

• Rendered vs intrinsic size
• Transfer bytes
• Alt-text accuracy
• CLS and LCP behavior

Common mistakes

• Forcing every image into one format.
• Stuffing keywords into alt text or duplicating surrounding captions.

Useful tools

• Media Library
• Browser network panel
• PageSpeed Insights
• Image editor

Why check this

robots.txt controls crawling, while noindex controls indexing when a crawler can read it. Canonicals are signals, redirects change location, and none should contradict the page's intended state.

Example

An internal search result returns 200 with noindex and is omitted from the sitemap; an old article returns one 301 to its matching replacement.

How to verify it

1. Declare the intended state for each URL type.
2. Check final status, redirect chain, robots.txt access, meta/X-Robots-Tag, and canonical.
3. Compare visible content and internal links with the declared canonical.
4. Resolve contradictions and retest live output.

Evidence to record

• Final status
• Crawl allowed
• Index directive
• Canonical target

Common mistakes

• Blocking a URL in robots.txt and expecting Google to see its noindex.
• Canonicalizing unrelated duplicate pages instead of fixing the page model.

Useful tools

• URL Inspection
• robots.txt tester
• HTTP checker
• Crawler

Why check this

A sitemap helps discovery and monitoring but does not guarantee crawling or indexing. WordPress or an SEO plugin may already generate it.

Example

The sitemap returns 200, lists only HTTPS canonical URLs, excludes noindex and redirecting URLs, and shows Success in Search Console.

How to verify it

1. Locate the generated sitemap and identify its owner.
2. Test fetchability and syntax.
3. Sample URLs for 200 status, indexability, and self-canonical consistency.
4. Submit or monitor it in Search Console and Bing Webmaster Tools, then record errors.

Evidence to record

• Fetch status
• Parse status
• Noncanonical URLs
• Search Console status

Common mistakes

• Creating a second competing sitemap.
• Treating discovered URLs as indexed URLs.

Useful tools

• Search Console Sitemaps report
• Bing Webmaster Tools
• Crawler

Why check this

Valid markup can make a page eligible for supported search features, but it does not guarantee display. Duplicate generators and invented properties create inconsistency.

Example

An Article object names the visible headline, dates, author, publisher, and representative image; one system owns the output and the Rich Results Test reports no critical errors.

How to verify it

1. Inspect all JSON-LD and microdata on representative templates.
2. Choose types supported by the content and applicable search features.
3. Compare required and recommended properties with visible facts.
4. Remove duplicate or conflicting generators and retest rendered pages.

Evidence to record

• Critical errors
• Warnings reviewed
• Visible-content match
• Single output owner

Common mistakes

• Adding FAQ markup to content that is not a visible FAQ.
• Promising a rich result after a passing test.

Useful tools

• Rich Results Test
• Schema Markup Validator
• Browser source

Why check this

Editor settings do not prove public output. Theme templates, JavaScript, caching, consent layers, security rules, and logged-in state can change what is delivered.

Example

A logged-out mobile fetch shows the same main answer, navigation links, canonical, title, and Article data as the intended production page.

How to verify it

1. Open representative pages logged out on mobile and desktop.
2. Compare raw HTML and rendered output for critical content and links.
3. Run live URL inspection where appropriate.
4. Record blocked resources, rendering differences, or conditional content and their owners.

Evidence to record

• Main content visible
• Links crawlable
• Metadata present
• Rendering differences

Common mistakes

• Testing only while logged in as administrator.
• Assuming a page builder preview equals the public page.

Useful tools

• Browser
• URL Inspection
• Mobile-friendly manual test
• HTML validator

Why check this

Current good Core Web Vitals thresholds are LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1 at the 75th percentile. One lab score is not field evidence.

Example

Mobile field data identifies a slow LCP image; a lab trace confirms the asset and response chain before the team changes image delivery.

How to verify it

1. Check Search Console or CrUX field data by mobile and desktop when available.
2. Run repeatable lab tests on representative templates and states.
3. Identify the actual LCP element, long interactions, layout shifts, bytes, and request chain.
4. Record the baseline, change, retest date, and guardrails.

Evidence to record

• LCP
• INP
• CLS
• Transferred bytes
• Requests

Common mistakes

• Optimizing only for a perfect lab score.
• Installing caching or a CDN without diagnosing the bottleneck.

Useful tools

• PageSpeed Insights
• Chrome DevTools
• Search Console Core Web Vitals

Why check this

Minification, deferral, combination, and caching can improve delivery but can also break rendering, forms, consent, logged-in behavior, or freshness.

Example

After removing an unused library and enabling server caching, median lab LCP improves without console errors, stale personalized pages, or broken forms.

How to verify it

1. Choose one measured bottleneck and one change.
2. Back up configuration and define cache exclusions and purge ownership.
3. Test logged-out, logged-in, form, search, consent, and update states.
4. Compare before/after field or repeatable lab evidence and keep a rollback path.

Evidence to record

• Cache status
• Asset bytes
• Render blocking time
• Functional regressions

Common mistakes

• Combining every script by default.
• Caching personalized or sensitive responses publicly.

Useful tools

• Hosting cache
• Browser DevTools
• Performance monitor
• CDN only when justified

Why check this

WordPress security is layered. Renaming a login URL or installing one security plugin does not replace updates, access control, backups, host configuration, and incident response.

Example

Two named administrators use unique credentials and MFA; file editing is disabled where appropriate; unused plugins are removed after backup; alerts have a tested owner.

How to verify it

1. Review WordPress hardening guidance and hosting controls.
2. Protect administrator and hosting accounts with MFA and recovery records.
3. Review permissions, unused components, update state, logging, and alerts.
4. Document incident contacts and test one alert path without exposing secrets.

Evidence to record

• Supported versions
• MFA coverage
• Unused components
• Alert owner

Common mistakes

• Claiming a site is secure because a plugin is installed.
• Recording passwords or keys in checklist notes.

Useful tools

• WordPress Site Health
• Hosting security controls
• Password manager
• Monitoring

Why check this

A backup is not proven until it can be restored. Updates reduce known risk but can introduce compatibility problems, so ownership, staging, monitoring, and rollback matter.

Example

A dated database-and-files backup is restored to an isolated environment; the team records duration, missing dependencies, update order, smoke tests, and rollback owner.

How to verify it

1. Record what is backed up, where, how often, how long it is retained, and who can restore it.
2. Create a fresh backup before material updates.
3. Restore to an isolated environment and run representative smoke tests.
4. Apply updates in a controlled order, purge caches, monitor, and record rollback evidence.

Evidence to record

• Database and files covered
• Last successful restore
• Recovery time
• Update and rollback owner

Common mistakes

• Keeping the only backup on the same server.
• Enabling unattended updates without monitoring or recovery ownership.

Useful tools

• Backup system
• Staging environment
• WordPress updates
• Monitoring

Why check this

Webmaster tools expose platform observations and diagnostics. They do not prove causation, contain every query, or guarantee crawling and indexing.

Example

The HTTPS domain property has two current owners, a successful sitemap, saved Page indexing and performance exports, and no unresolved security or manual action.

How to verify it

1. Verify the canonical production scope and ownership method.
2. Submit or locate the sitemap and record its fetch status.
3. Export baseline performance and indexing reports with dates and filters.
4. Check security and manual-action areas and assign unresolved issues.

Evidence to record

• Property scope
• Verified owners
• Sitemap status
• Baseline date

Common mistakes

• Verifying only an obsolete HTTP or www variant.
• Treating Search Console clicks as all organic traffic.

Useful tools

• Google Search Console
• Bing Webmaster Tools

Why check this

A tag being present does not prove accurate measurement. Consent configuration, duplicate tags, internal traffic, cross-domain paths, ad blockers, and event definitions affect the record.

Example

After the documented consent choice, one page-view event and one form-success event appear in the expected property; denied-state behavior matches the privacy configuration.

How to verify it

1. Document the analytics purpose, owner, retention, consent, and privacy disclosure.
2. Inspect the public site for duplicate or unexpected tags.
3. Test accepted, rejected, internal, referral, and conversion paths.
4. Use realtime/debug tools and record what the system does not measure.

Evidence to record

• Duplicate tags
• Consent states
• Key events
• Internal traffic handling

Common mistakes

• Loading optional analytics before the applicable consent choice.
• Counting a button click as a completed conversion without verifying success.

Useful tools

• Google tag diagnostics
• Analytics DebugView/Realtime
• Consent platform
• Browser network panel

Why check this

A launch checklist is a dated baseline. WordPress components, templates, content, search reports, platform documentation, and business priorities change.

Example

On the first business day, the owner reviews Site Health, updates, restore evidence, critical templates, search diagnostics, Core Web Vitals, and content with update triggers.

How to verify it

1. Assign a recurring owner and review date.
2. Compare current critical evidence with the saved baseline.
3. Open issues by priority with an owner and decision date.
4. Record material content and documentation changes and preserve prior evidence.

Evidence to record

• Review completed
• Critical open issues
• Last restore test
• Stale content triggers

Common mistakes

• Refreshing modified dates without reviewing content.
• Closing an issue because a plugin setting looks correct without testing output.

Useful tools

• WordPress Site Health
• Search Console
• Monitoring
• Content maintenance ledger