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. Check the actual HTTP response
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. 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
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. Treat the sitemap as an inventory, not a repair tool
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. Find pages with no internal route
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. 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. Look at performance by template