You can do useful WordPress SEO without installing an SEO plugin: improve your content, fix internal links, prepare lighter images, check indexability, and verify what your pages actually publish. Some work belongs in the editor. Other tasks depend on your theme, hosting controls, or maintained code.
These 21 tasks explain where to make each change and how to check the result. They apply to self-hosted WordPress and allow external tools such as Search Console. They do not assume that your whole site has zero plugins.
If an SEO plugin already manages your titles, canonicals, or sitemap, leave that ownership in place until you have a separate migration plan. This guide is a way to work without adding an SEO plugin, not a reason to remove a functioning one.
Know which part of WordPress owns the result
Before changing a setting, identify the component that produces the output you want to improve.
| Output | Usual place to work | What to verify |
|---|---|---|
| Page copy, links, headings, image attributes | WordPress editor | The published page contains the intended content and attributes |
| Search visibility and permalink preferences | Core settings | The public response matches the intended access and URL policy |
| HTML title, description, canonical, structured data, social tags | Core and theme output, sometimes an existing plugin | Which component emits each field; whether it is correct or duplicated |
| HTTPS, redirects, page caching | Hosting or server controls | The actual response, destination, and treatment of private pages |
| Search queries and page performance | External reporting tools | The selected URL, date range, device, and available evidence |
A post title, an HTML <title>, an excerpt, and a meta description are different things. WordPress generates document titles according to context and filters; a theme can affect the final result. An excerpt is a summary that a theme may display. It is not automatically a search description field. The WordPress document-title reference and excerpt documentation explain those separate roles.
Choose a published post, a static page, and a category archive as your initial sample. Record their current titles, status codes, and head tags. A change that works on a post may not apply to an archive.
For code changes, have staging access and a recovery route before editing. An editor account alone is sufficient for many content tasks; it is not sufficient for every technical task below.
Start with access and stable URLs
1. Check public search visibility
For a site intended to appear in search, open Settings → Reading and check that Discourage search engines from indexing this site is not selected. Keep staging sites protected; do not make them public just to match this instruction.
Then inspect a public page while logged out. Check the HTML for a robots meta tag and the response headers for X-Robots-Tag. A separate theme, server rule, or existing plugin can still emit noindex even when the Reading setting is correct.
Current core uses the robots directive mechanism when the public-site setting is disabled. Do not assume that toggling this box must add or remove a sitewide Disallow: / in robots.txt.
Done when: intended public pages have no unintended indexing restriction. This permits consideration for indexing; it does not establish that Google has indexed them. The checkbox also does not provide private-site access control.
2. Verify HTTPS and the preferred host
Open a representative page using HTTP, HTTPS, and the applicable www and non-www host variants. Identify the intended HTTPS URL. Check whether other variants redirect cleanly there instead of serving competing copies or producing certificate errors.
Review Settings → General alongside the hosting configuration. The General settings documentation distinguishes WordPress Address from Site Address: they can legitimately have different paths when WordPress is installed in a subdirectory. Do not force them to match as an SEO shortcut.
Ask the hosting administrator to resolve certificate or redirect problems at their actual source. Editing URL fields without understanding the installation can break access.
Done when: the intended public URL loads successfully, supported alternative hosts resolve consistently, and internal links use the preferred form.
3. Choose stable permalinks for new content
For new content, use a readable slug that describes the page without adding disposable campaign labels. For example, /guides/wordpress-image-sizes/ is easier to maintain than a slug tied to an introductory promotion.
The Permalinks settings offer several structures. Choose one that fits your existing site. A post-name structure is an option, not a universal requirement, and a numeric URL is not inherently uncrawlable.
On an established site, changing the permalink structure is a migration involving old URLs, links, redirects, and verification. Do not do it simply to make every URL look shorter. Task 16 covers repairing an old URL when a change is justified.
Done when: new pages follow a clear policy and useful existing URLs remain stable.
Improve page content and search presentation
4. Assign one reader problem to the right page
Before creating another post, search your own site for the problem it would solve. Compare the actual answer, audience, and scope of each candidate page. Similar words do not necessarily mean the same intent, but a different title alone does not create a different purpose.
Make a small planning record: reader question, existing destination, missing answer, and proposed action. If an existing guide already serves the question, improve that guide. If the reader needs a separate workflow, explain that distinction before drafting.
For example, a broad WordPress SEO guide and a guide to implementing descriptions without an SEO plugin can serve different tasks. Our WordPress SEO overview provides broader context; the instructions here focus on ownership and checks without adding an SEO plugin.
Done when: you can state why the selected page is the right destination and what useful answer it will provide.
5. Check the post title and HTML title separately
Write a title that describes the page's actual answer. Keep it concise enough to scan, without adding promises the content does not fulfill. There is no fixed character count that guarantees Google will display it in full.
After publishing, inspect the document's <title>. Your theme may append the site name, apply a template, or receive filtered output. Verify the complete result instead of assuming that editing the post title changes only that field.
A duplicated brand suffix or a generic title across different pages is a reason to inspect the active title implementation. Avoid adding an extra hardcoded <title> to header.php; establish one owner for the output.
Google can generate a different title link from visible headings and other sources. Its title-link guidance supports descriptive, consistent titles rather than treating the HTML tag as a display guarantee.
Done when: the page title, visible heading, and emitted HTML title describe the same content, with no unintended duplicate title element.
6. Add a description only when you own its output
Inspect the current page head first. If a theme or existing plugin already emits a good description, use its supported field. Do not add a second emitter.
If there is no description output and you have a developer maintaining an already activated child theme, one option is a native custom field plus a small wp_head callback. WordPress documents both custom fields and the head hook. Custom fields store data; they do not render SEO tags on their own.
Save your draft before enabling the Custom Fields panel because enabling it may reload the editor. In editor preferences, find the Custom Fields option; its placement varies by editor version. Add a field named site_meta_description, enter a plain-language description of that particular page, and save the post.
Place the following callback in the existing child theme's functions.php, inside its PHP code. Do not edit WordPress core or paste it into a parent theme that an update could overwrite. A developer should validate it on staging with the active theme and a recovery route available. This is a documentation-based implementation example, not a report of a tested installation.
add_action('wp_head', function (): void {
if (!is_singular(['post', 'page']) || is_preview() || post_password_required()) {
return;
}
$value = get_post_meta(get_queried_object_id(), 'site_meta_description', true);
if (!is_string($value) || trim($value) === '') {
return;
}
$description = trim(wp_strip_all_tags($value, true));
if ($description === '') {
return;
}
printf(
'<meta name="description" content="%s">' . "\n",
esc_attr($description)
);
}, 5);
The callback handles ordinary singular posts and pages. It skips previews, password-protected content, empty fields, and non-string metadata. It strips markup and escapes the attribute. It does not generate archive descriptions, change titles or canonicals, or disable another component's tags. It also depends on the theme calling wp_head().
For a field containing an illustrative description, the expected public output would resemble:
<meta name="description" content="Learn how to resize WordPress images, choose useful alt text, and check the published result.">
Check two public pages with different field values and a third with the field empty. Each populated page should show its own single description. The empty field should produce no tag from this callback. Clear relevant caches and repeat after a theme change. Keep the code under maintenance alongside the theme.
Describe the page accurately rather than filling a character quota. Google primarily creates snippets from page content and may use a suitable meta description; this field does not force a specific snippet.
Done when: one maintained component emits the intended page-specific description, and empty or excluded cases behave as expected.
7. Structure the page with useful headings
Use the core Heading block to divide the answer into meaningful sections. Check the editor's document outline and the published HTML. A bold paragraph is not automatically a heading.
If your theme already displays the post title as the main heading, do not add another copy just to make the article look larger. Use H2s for main sections and H3s for their subsections where that hierarchy fits. Avoid choosing heading levels solely for font size.
The Heading block documentation explains its levels and outline view. The goal is a readable structure, not a claim that a particular H1 count earns rankings.
Done when: someone scanning the headings can understand the page's questions and navigate its answer.
Give readers and crawlers useful paths
8. Add contextual internal links
When a paragraph raises a question answered elsewhere on your site, link to that answer with descriptive anchor text. Select the text in the editor, add the destination, and open the published link to verify it.
For example, a paragraph about image dimensions could link to an image-sizing guide using those words. A reader should understand the destination without having to follow a vague “read more” link.
Check that important links become normal <a href="…"> elements in the published output. Google's crawlable-link guidance explains why this matters. There is no useful universal target such as ten internal links per article.
Done when: relevant pages connect through working, understandable links, including links into important pages from existing content.
9. Make important pages reachable from navigation
Contextual links help within an answer; navigation helps people find the answer in the first place. Identify important pages that can currently be reached only through a sitemap or a direct URL.
Add them to the appropriate menu or topic hub when that helps visitors. Block themes can use the Navigation block; classic themes may expose menu controls elsewhere. Use the controls your active theme supports rather than looking for one interface shared by every installation.
Test the published navigation while logged out and on a narrow screen. Do not automatically add every new post to the main menu. A useful category or resource hub can provide a clearer path.
Done when: a visitor can follow a sensible path from an existing public page to the important destination.
10. Give category and tag archives a purpose
Review categories and tags as collections for readers. A category for a substantial subject can help someone find related material. Dozens of nearly identical tags with one post each may offer little additional value.
Inspect the actual archive: its heading, listed posts, navigation, and any introductory copy supported by your theme. Does it collect a useful set of answers, or repeat another archive with a slightly different label?
Use a consistent taxonomy policy for new posts. For an existing archive, consider its links and reader value before merging, removing, or changing its URL. Do not apply a blanket “noindex all categories” rule or remove category bases just because another site does it.
Done when: each maintained archive has a clear grouping purpose, and editors know when to reuse an existing category or tag.
Reduce media weight without losing meaning
11. Resize and compress images before upload
Prepare images for their real display purpose. A small explanatory illustration does not need the same dimensions as a full-width image intended for detailed inspection. Resize and compress a copy before uploading, then compare the result at its intended display size.
In the Image block, choose an appropriate available resolution rather than automatically selecting Full Size. WordPress's generated sizes, the source file, and theme settings affect the options and final markup. Inspect the actual image delivered to the browser, including responsive alternatives where present; the editor label alone does not establish the downloaded file's size.
Google's image guidance covers image quality, discoverability, and surrounding context. Preserve readable labels and meaningful detail instead of pursuing the smallest possible file.
Done when: the delivered asset is appropriately sized and legible, with its actual file weight checked. Do not rename existing image URLs indiscriminately to add keywords.
12. Write alt text for the actual image use
Describe information a reader would miss if the image were unavailable. For a chart, identify the relationship it demonstrates; keep essential numbers or conclusions available in nearby text as well. Avoid repeating a keyword list or starting every description with “image of.”
Treat decorative images differently from informative ones. Use the editor's decorative-image option where appropriate, and inspect that the published image has an empty text alternative rather than an accidental filename description.
An important WordPress detail: changing alt text in the Media Library does not automatically rewrite every previously inserted Image block. The Image block documentation distinguishes an individual block's alt text from the library default used for future insertions. Review existing instances in context.
Done when: the particular published image has an appropriate alt attribute for its role on that page.
13. Remove embeds and scripts that do not earn their place
Review videos, maps, social embeds, chat widgets, and other third-party elements. Keep those that help the reader complete the task. Remove abandoned or repeated elements through their supported editor, theme, or hosting integration.
For example, a short paragraph and a normal link may serve a minor reference better than an automatically loaded social embed. That is a content decision, not a reason to remove an essential demonstration.
Make one change at a time and check the affected page. Preserve consent behavior, forms, navigation, accessibility, and other necessary functions. Do not disable scripts blindly or infer performance from the number of installed plugins.
Done when: unnecessary third-party requests are removed and the page's intended functions still work.
Check technical outputs on the published URL
14. Verify the core XML sitemap
WordPress has included core sitemap functionality since version 5.5. For an enabled core sitemap, the index URL depends on the permalink configuration:
| Permalink configuration | Core sitemap index path |
|---|---|
| Pretty permalinks | /wp-sitemap.xml |
| Plain permalinks | /?sitemap=index |
These paths come from the core sitemap-index implementation. An existing sitemap provider may use a different path, so identify the current owner before diagnosing an apparently missing file.
Open the index, follow the appropriate child sitemap, and look for a representative intended URL. Confirm that the response contains sitemap XML, not a theme's HTML error page that happens to return 200.
Core sitemap availability depends on the site's public setting and can be changed by a filter, as the sitemap enablement reference shows. If it is unavailable, check those conditions with the site maintainer before creating a second sitemap. A hand-maintained XML file that becomes stale is not an improvement.
Done when: you have a valid, maintained sitemap index and appropriate child entries. A sitemap helps discovery; it does not guarantee indexing.
15. Check the canonical destination
Inspect the canonical link on a published post and page. Does it point to the intended absolute public URL, with the correct host, path, and protocol? Check that another component is not adding a conflicting second canonical.
WordPress core's canonical function operates on singular queries. Do not assume that this proves the correct canonical policy exists on every category archive, search page, or custom template.
For URL variants, compare the canonical with internal links and redirects. If they disagree, identify the owner of each output and resolve the underlying inconsistency. Avoid a global callback that makes every URL canonicalize to the homepage.
Our canonical-tag guide explains duplicate-URL scenarios. Google treats canonical declarations as signals rather than commands; a correct tag is not proof that Google selected it.
Done when: intended pages publish a coherent canonical policy without conflicting emitters, and exceptions have a named owner.
16. Repair broken internal links and useful old URLs
Start with a broken internal link and open its destination. Determine whether it contains a typo, points to content that moved, or refers to content that no longer exists.
Fix a typo at the source. If a page moved and a genuinely equivalent replacement exists, configure a suitable permanent redirect through supported hosting or server controls, then update internal links to the final destination. Google's redirect documentation explains the available approaches; implementation depends on your server.
Keep a mapping of old URL, destination, reason, and verification result. Test the final response rather than merely saving a rule. Avoid unnecessary chains and redirects to unrelated pages. A real 404 or 410 can be appropriate when deleted content has no replacement.
Done when: the internal link reaches the intended resource, and any retained old URL has a justified outcome. Do not redirect all missing pages to the homepage.
17. Audit structured data against visible facts
Inspect the structured data your page actually emits. A theme may supply it, an existing component may supply it, or it may be absent. Presence alone is not a successful check.
For an article, compare the applicable fields with the visible page:
| Field | Useful check |
|---|---|
headline |
Describes this article rather than another post |
author |
Identifies the actual credited person or organization |
datePublished and dateModified |
Match real publication and substantive modification history |
image |
Identifies a relevant, accessible article image where supplied |
| Article identity and URL references | Describe the intended page rather than a staging or unrelated URL |
Use Google's Article structured-data documentation and Rich Results Test to assess the output. A valid result does not guarantee a rich result or certify every factual statement.
If appropriate markup is missing, record the gap for the theme maintainer. Adding it correctly requires a maintained, page-aware implementation. Do not paste one fixed article object across the site or invent review ratings, author credentials, dates, or images.
Done when: existing article markup matches the page, or a concrete missing-output issue is assigned to the component owner. This audit does not assume every WordPress theme generates Article markup.
18. Audit social preview fields
Check the public page for the Open Graph fields used by sharing platforms. At minimum, inspect the title, canonical sharing URL, image URL, and object type where implemented. Check the description and image alternative text when supplied.
A common problem is every article inheriting the same homepage preview. Another is an image URL that exists in the editor but cannot be fetched publicly. Open the declared image and verify its identity and clarity. A correctly written tag cannot repair an inaccessible asset.
Use the active theme's supported controls if available. Otherwise record the missing page-aware output for its maintainer; WordPress core settings do not provide a universal social-preview editor. Sharing platforms may cache previews, so their displayed card can lag a verified HTML change.
Done when: the declared sharing fields describe the correct public page and usable image. This supports accurate sharing; it is not a Google ranking guarantee.
Improve delivery and mobile experience
19. Use host caching with the right exclusions
Check whether your hosting service already provides supported page caching or static-asset caching. If it does, use its documented controls and purge behavior before adding another caching layer.
Decide which pages are safe to cache. Public editorial pages and personalized account pages have different requirements. Cart, checkout, authenticated, and other personalized responses need explicit handling under the host's policy; do not apply a generic public-cache rule to everything.
Change a harmless piece of public content and confirm that a purge exposes the update. Separately check that private content is not delivered to another visitor. If you lack access to validate those boundaries, leave the cache configuration with the hosting administrator.
WordPress's optimization documentation describes several caching layers. They are not interchangeable. This task concerns supported host controls; it does not claim that an object-cache integration always works without additional software.
Done when: supported caching serves the intended public content, updates can be refreshed, and private or personalized content remains correctly handled.
20. Diagnose mobile layout and performance
Open a representative article on a narrow screen. Check whether readers can use the menu, read the copy, dismiss overlays, and interact with forms without obstructing the answer. Look for images or tables overflowing their containers and layout shifts while content loads.
Run PageSpeed Insights on the same public URL and record the date, device mode, and available measurements. Its documentation distinguishes lab diagnostics from field experience. Field data can be unavailable; that is not a zero score or a passing result.
Choose a specific issue, such as an oversized lead image or an unnecessary embed, and assign it to the responsible editor, theme developer, or host. Recheck comparable conditions after the change. A better lab score alone does not establish a ranking gain.
For a deeper performance workflow, see our WordPress page-speed guide.
Done when: you have a reproducible mobile problem, a scoped fix or assigned owner, and a comparable follow-up check rather than an unexplained score.
Turn Search Console evidence into the next edit
21. Refresh a page using its actual search queries
In Search Console's Performance report, select the relevant search type and page, then inspect the queries it appears for. Compare suitable date ranges while keeping country and device filters consistent. The report documentation explains clicks, impressions, CTR, and average position; each answers a different question.
Use that evidence to investigate the page. A relevant query may reveal a missing example or an answer buried below unnecessary background. Re-read the page and search intent before adding a section. Do not insert every query variation as a heading or interpret one movement in average position as proof of a content problem.
For example, if an image-sizing guide appears for a question about existing uploaded files, check whether it explains that workflow. Add a useful answer only if it belongs within the page's purpose. This example illustrates a decision; it is not a claim about an observed Screpy traffic result.
Make a focused edit, record it, and compare later performance with context. Seasonality, changing search results, other site changes, and reporting differences can affect the comparison. A before-and-after increase alone does not isolate the cause.
Done when: a real page/query question leads to a relevant improvement and a recorded follow-up, rather than speculative keyword insertion.
Keep a change and retest record
Copy this worksheet into your working document. Replace the placeholders with observed values; leave unavailable evidence marked as unavailable.
Page URL: [exact public URL]
Task number and issue: [one of the 21 tasks; specific observation]
Current output: [HTML field, response, file, or reporting evidence]
Owner: [editor / theme maintainer / host / reporting owner]
Proposed change: [smallest useful change]
Expected result: [observable output, not a promised ranking]
Change date: [YYYY-MM-DD]
Verification date and method: [how the public result was checked]
Observed result: [actual finding / unavailable / still unresolved]
Follow-up: [next action and comparable review conditions]
For sitewide checks, Screpy's Website Audit can help collect crawl findings such as titles, headings, response statuses, redirects, canonicals, and image issues. Screpy publishes this guide. An external audit can help you organize findings without installing a WordPress SEO plugin, but it does not edit your theme, prove Google indexing, or identify every runtime problem.
Use the audit or your manual sample to choose the next worthwhile change. Keep the final check tied to the public output that the task was meant to improve.