WordPress SEO Checklist: Indexing Settings, Sitemaps and Publishing Checks
Published:
Last Updated:
Category: SEO & Content, Media Strategy
Authors: Shusaku Yosa
WordPress SEO is a publishing and review process, not a task completed by installing a plugin. Begin with public access and the output that readers and search engines receive. Then decide whether a setting, technical issue or article needs attention.
Separate discovery, indexing and ranking
A public page, a discovered URL, an indexed page and a visible result are different states. Separating them helps when someone says, “We submitted a sitemap, but the article has no rankings.” The next useful check depends on the stage, not that statement alone.
Stage | Question | Example evidence |
|---|---|---|
Access | Can an ordinary visitor read it? | No unintended login requirement or error |
Discovery and crawl | Can it be found and fetched? | Links, controls and server response |
Indexing | Which version is indexable? | Robots, canonical and inspection |
Visibility | Which searches produce impressions? | Matched page and date conditions |
These checks organize an investigation; they do not guarantee indexing or a position. Review technical access and useful content together. Google’s SEO Starter Guide provides a reference for the broader process.
Check public access and search engine visibility settings
WordPress includes a search engine visibility setting. Review Settings and the Reading screen to determine whether a public site unintentionally discourages indexing. Labels and available controls can differ between installations.
The official Reading settings documentation explains this setting. It is not access control that makes a site private to ordinary visitors. A staging site’s restriction requirements need a separate solution.
Check | Inspect | Record |
|---|---|---|
Reading setting | Whether visibility is discouraged | Intended state and owner |
Public page | Draft, private or login-only behavior | Ordinary visitor experience |
Output | Robots and canonical | Consistency with intent |
HTTPS and redirects | Final public address | Unexpected destinations |
A checkbox alone does not establish the final output. A theme, plugin or custom configuration may add behavior. If a change is necessary, understand the scope and recovery plan before making it on a live site.
Treat new-site URLs and changes to existing URLs differently
Choose a consistent URL convention before publishing a new site. For an established site, changing permalinks is a migration decision. A cleaner-looking address is not automatically a good reason to replace URLs that readers and other sites already use.
Fictional situation | Decision | Preparation |
|---|---|---|
Unpublished blog | Choose a descriptive convention | Naming and future workflow |
Existing 100-article site | Keep working URLs unless change is needed | Existing references and links |
Required migration | Plan changes separately | Mapping, redirects, updates and owners |
If a change is needed, map old addresses to new ones and consider redirects, internal links and sitemap references together. A beginner setup recommendation is not a reason to replace every published address without reviewing the consequences.
Audit what the theme, plugins and WordPress actually output
WordPress core includes XML sitemap functionality, with wp-sitemap.xml as its standard example. See the official introduction and current reference. Plugins or custom settings can change the actual output, so inspect the installation before adding another tool.
Output | Possible owner | Review |
|---|---|---|
Title and description | Theme or SEO plugin | Intended output appears once |
Robots and canonical | Theme, plugin or configuration | Instructions do not conflict |
Sitemap | Core or plugin | Known address and contents |
Headings | Theme and post body | Structure matches meaning |
Clarify responsibility rather than multiplying overlapping tools. Record sitemap retrieval, individual URL inclusion and indexing state separately. Successful submission does not prove that every listed page is indexed.
Review article headings, links and images
Review the article around the reader’s sequence of decisions. A theme may already turn the post title into an H1; inspect the output before adding another main heading to the body. Visual size should not determine semantic hierarchy.
Write links that explain what the destination helps the reader do, rather than relying on “click here.” Google’s link recommendations are a useful reference. Images should support the explanation, with alternative text communicating their role.
- Does the introduction identify the problem?
- Are prerequisites and failure paths included?
- Do headings explain the flow when read alone?
- Are relevant guides available in the reader’s language?
More keyword variations do not necessarily make the explanation complete. Check the conditions and evidence a reader needs to act, and whether the description agrees with linked references.
Use Search Console evidence to prioritize the next step
Record the exact URL and date when reviewing Search Console. Distinguish discovery, crawl, indexing and canonical evidence. A missing performance row alone does not establish that a page is unindexed.
Record | Keep |
|---|---|
Identity | URL, language and revision date |
Access | Viewing, response and restrictions |
Instructions | Robots, canonical and crawl controls |
Discovery | Internal links and sitemap checks |
Inspection | Date, displayed state and unresolved checks |
Start with one article and follow this record through. Involve the person responsible for the setting, server or content concerned. Choose actions from evidence instead of treating every visibility problem as writing quality. Keep a dated note of the initial state so a later reviewer can distinguish a correction from an assumption and see what remains unverified.
