Technical SEO Checks I Run Before Writing More Content

“We need more content” is one of the most common conclusions in SEO.

Sometimes it is right. Often it arrives too early.

If search engines cannot reliably crawl, understand or index the pages already on a site, another twenty articles just create a larger pile of URLs with the same problem. Before planning content, I run a technical pass in a fixed order.

It is not glamorous, but it stops expensive work being built on a weak base.

1. Check the actual HTTP response

I start with the page itself, outside the browser interface.

curl -I https://example.com/service-page

For an indexable page, I normally expect a clean 200 response. A redirect may be intentional, but chains and loops need attention. A page can also look normal in a browser while behaving like a soft 404 because the content is thin, missing or replaced by an error message.

I check representative URLs from every important template:

• the homepage
• service and category pages
• location pages
• articles
• paginated pages
• filtered or parameterised URLs

One healthy page does not prove that the whole site is healthy.

2. Read the robots and canonical instructions together

A page can be blocked or devalued in several different places:

• robots.txt
• a meta robots tag
• an X-Robots-Tag HTTP header
• a canonical pointing somewhere else
• an authentication or firewall rule

These instructions need to agree.

A surprisingly common setup is an indexable page with a canonical to the wrong host, protocol or URL variant. I choose one version of the domain, one trailing-slash policy and one protocol, then make internal links, canonicals and sitemap entries use it consistently.

I also check rendered HTML. If a canonical or robots directive is injected by JavaScript, the source and rendered versions may not tell the same story.

3. Treat the sitemap as an inventory, not a repair tool

An XML sitemap helps discovery. It does not force indexing.

I want it to contain canonical, indexable URLs that return 200. Redirects, deleted pages, duplicates and private areas do not belong there.

For a small site, I compare the sitemap against the pages the business actually considers important. This often reveals both problems at once: URLs in the sitemap that should not exist, and valuable pages that have been left out.

A sitemap's lastmod value should also mean something. Updating every timestamp on every deployment teaches crawlers that the field is unreliable.

4. Find pages with no internal route

A URL in a sitemap can still be an orphan.

Search engines learn a great deal from internal links: which pages matter, how topics relate and what language describes a destination. A service page linked from the main navigation and relevant articles has a very different position from one that exists only in an XML file.

I check:

• the click depth from the homepage
• broken internal links
• pages with no incoming links
• repeated links to irrelevant pages
• anchor text that says nothing about the destination

I do not try to force every page into the navigation. The aim is to create sensible routes a visitor might genuinely follow.

5. Validate structured data against what visitors can see

Structured data is useful when it accurately describes the page. It is not a place to add facts that the page itself does not support.

A basic service business might use Organization, LocalBusiness, Service, BreadcrumbList or FAQPage, depending on the content. The correct type matters less than the truthfulness and consistency of the properties.

I validate the JSON-LD, then manually compare names, URLs, phone numbers, addresses, prices and opening hours with the visible page.

Invalid markup is a technical bug. Valid markup that exaggerates the page is a trust problem.

6. Look at performance by template

A sitewide performance score can hide the useful detail.

The homepage might be fast while every service page loads a huge hero image. Blog posts might shift because an advert or embedded widget has no reserved space. A booking page may respond slowly because it waits on several third-party scripts.

I review the main templates and pay particular attention to:

• Largest Contentful Paint, usually the hero image or heading
• Interaction to Next Paint, often affected by heavy JavaScript
• Cumulative Layout Shift from images, fonts and injected elements
• server response time
• unused third-party code

The fix is frequently ordinary: resize an image, set dimensions, preload the right font, remove a script or avoid loading a widget before it is needed.

7. Check whether each page has a distinct job

Technical health cannot rescue a group of pages that all answer the same query in almost the same way.

For each important URL, I write down:

• the visitor's likely intent
• the main topic
• the unique information on the page
• the action the visitor can take
• the closest competing page on the same site

If two URLs have the same answer, I decide whether to combine them, differentiate them or choose one canonical version. Writing more text onto both rarely solves the overlap.

Titles and H1s should be descriptive, but the real test is the body. A page needs to fulfil the promise made in the search result.

8. Verify after changes go live

The audit is not finished when a spreadsheet is delivered.

After deployment, I recheck response codes, canonicals, robots directives, structured data and sitemap entries. I use Search Console's URL Inspection for a sample of important pages and watch crawl or server logs where they are available.

Indexing is not instant, and not every valid page deserves to rank. The goal of the technical pass is narrower: remove accidental barriers and give worthwhile pages a clear, consistent structure.

My short pre-content checklist

Before commissioning more articles, I want to be able to say yes to these questions:

• Do priority URLs return the intended status code?
• Are they indexable and self-canonical?
• Are domain and URL variants consistent?
• Does the sitemap list only useful canonical URLs?
• Can visitors reach important pages through internal links?
• Does structured data match visible information?
• Are the main templates usable and reasonably fast?
• Does every page have a distinct purpose?
• Have the deployed fixes been verified?

Only then do I move on to content planning.

This is the same order I use at GM SEO Services: fix crawl and indexation problems first, then invest in content.