A WordPress Technical SEO Checklist: What I Check First

Before I touch titles or write new pages, I check the technical basics. They are quick to test, they are invisible to visitors, and a mistake in them can hide good content. This is the order I use. For each item I say what I did on tonimaxx.com, because I audited this site in November 2026 with the same list.

I promise no rankings from any of this. These steps remove problems. They do not decide where a page lands.

1. Status codes and redirects

Request the important URLs and read the status code, not just what the browser shows.

The http and https versions of the home page should end on one https URL in one hop.
The www and non-www host should not both return 200. Pick one and send the other with a 301.
Old paths should 301 to the new page, not to an unrelated page.
Unknown URLs should return 404. A redirect to a different page looks like a soft 404 to a crawler.

What I found here: the www host answered 200 with the same page, and a stray copy of the home page was public under a second path. I added a 301 from www to the main host, and a 301 from the stray path to the home page. A request for /index.php now also goes to /.

2. Canonical URLs

Every page should carry one canonical link that points to its own preferred URL. Check that it matches the URL in the sitemap. On this site every canonical already matched, which is why the www duplicate was low risk. The 301 is still the better fix, because it does not depend on a crawler reading a hint.

3. Titles and descriptions

Each page needs its own title and description. Keep titles at about 60 characters or less and descriptions at about 155 or less, so search results are less likely to cut them. Write them for a person, with the page topic first.

What I changed here: the home title now says what I do (full stack developer in the SF Bay Area) and the demo hub title names WordPress and native apps. I did not add ratings, prices or client claims, because I have none to show.

4. Sitemap and robots.txt

robots.txt should load, return 200, and contain a Sitemap: line.
The sitemap should list only URLs that return 200 and match their canonical.
Do not block a page in robots.txt and also rely on a noindex tag on it. A crawler that cannot fetch the page cannot read the tag.

On this site the sitemap had 15 URLs, all returning 200, and I confirmed each one. I removed a temporary staging copy and its Disallow line once the page it staged went live. Admin pages keep the Disallow and now also send a noindex header.

5. Structured data

Use JSON-LD, make sure it parses, and use one set of entity IDs across the whole site. My audit found valid JSON on every page but three different ID namespaces for the same person. I moved to one shared graph: a website, a person and a business, with each page pointing to them. After deploying structured data, run Google's Rich Results Test yourself. I could not call it from my audit environment, so I list it as an owner step.

6. Speed basics: compression and caching

This was the biggest single gain on my audit, and it took a few lines of server configuration.

Compression. Before the change, HTML, CSS and JavaScript were sent raw. After enabling gzip, the home page went from 25,340 to 7,803 bytes, the demo hub from 89,784 to 23,457, and the API page from 180,274 to 26,569.
Caching. Add a cache lifetime for static files. I set images to 30 days and CSS and JavaScript to 1 day. File names on this site are not fingerprinted, so a longer lifetime for scripts would risk stale files.

Check it with curl -s -D- -o /dev/null -H 'Accept-Encoding: gzip' https://your-site/. You should see Content-Encoding: gzip for HTML and an expiry header for images.

7. Images

Give every image width and height so the page does not shift while loading.
Use WebP where you can, with a 2x file for sharp screens.
Write real alt text. Leave alt empty only for purely decorative images.
Lazy-load images below the first screen.

On the demo hub, 57 images all have width and height, and the five with empty alt are decorative mascot poses.

8. Core Web Vitals proxies

Field data needs real traffic. Until then I use a lab proxy: load the page in a headless browser on a throttled connection and read largest contentful paint and layout shift. My numbers for the home page were 348 to 476 ms on desktop and 516 to 560 ms on a slowed mobile profile, with layout shift at 0. These are lab figures from my own test, not what real visitors will see. The site uses a system font stack, so fonts cause no layout shift.

Run PageSpeed Insights on your key URLs as well. It adds field data once Google has enough.

9. Security basics that touch SEO

Serve everything over https and fix mixed content. I found none on the main pages.
Keep the TLS certificate renewing on its own. This one renews automatically.
Add response headers such as X-Content-Type-Options and Referrer-Policy. They matter more for hygiene than ranking. I have this on my list and have not done it yet.
Keep WordPress, themes and plugins updated, and remove unused plugins.

10. Search Console

Verify a Domain property, submit the sitemap, and use URL Inspection on your main pages after a change. Watch the Pages report for "Page with redirect" and similar states. Add the same checks to Bing Webmaster Tools through its import.

Order of work

If I have one hour: compression and caching, then redirects, then titles, then structured data. Each is reversible, so I save the old configuration first and keep a rollback copy.

Book the free consult

What I checked / where this comes from

My own SEO audit of tonimaxx.com, 11 November 2026, and the plan I executed from it. Sizes, redirect results and lab timings are from that audit.
General practice: title and description length, one canonical per page, 404 for unknown URLs, image dimensions.