The technical SEO checklist we run before publishing any AI content
A pre-publication technical SEO checklist is a fixed sequence of checks that confirm a site can be discovered, crawled, indexed and understood before new content is added to it. Its purpose is to prevent the most common failure in content programmes: publishing well onto a foundation that cannot surface the result.
Why the order matters more than the list
Most technical SEO checklists are alphabetical or grouped by tool. That is the wrong shape, because the checks are not independent. A schema problem on a page that cannot be crawled is not a problem worth fixing yet. Working in the wrong order means spending effort on faults that do not bind.
The sequence below is ordered by what blocks what. Each check is only worth running once the one above it passes, and the first failure you hit is usually the only one that matters that week.
We wrote this list from a real audit, and the ordering reflects a finding that surprised us: a site can pass every on-page check with full marks and still be invisible, because discovery failed two steps earlier. On-page perfection with zero discovery is a diagnostic signal, not a contradiction.
The eight checks, in order
Run these top to bottom and stop at the first failure.
- Discoverability. Does anything on the open web link to this site? A new domain with zero inbound links gives crawlers no path in. Sitemap submission helps, but a site nobody references is a site with no reason to be recrawled. This is the check that is skipped most often and blocks everything below it.
- Crawlability. Fetch robots.txt and confirm it returns 200 and does not disallow what you care about. Check the response headers for an X-Robots-Tag. Confirm no page-level noindex survives from a staging configuration.
- Indexability. In Search Console, run URL Inspection on the homepage and one commercial page. The distinction between "URL is on Google" and "Discovered, currently not indexed" is the single most informative data point in the whole checklist, and no amount of on-page work substitutes for it.
- Canonical integrity. Every page should declare itself canonical unless you deliberately want otherwise. Cloned or templated builds are where this breaks: a canonical pointing at the site the template came from silently removes the page from consideration.
- Redirect hygiene. Confirm the www and apex versions resolve one way, permanently. A temporary redirect where a permanent one belongs is a small, persistent leak of link equity that nobody notices because the page still loads.
- Sitemap accuracy. The sitemap should list every page you want indexed and nothing you have retired. Removed URLs should return 410 rather than 404 when the removal was deliberate, because it tells engines to drop them faster.
- Structured data validity. Organization, LocalBusiness, Service, FAQPage and BreadcrumbList where each applies, with entity details matching what appears elsewhere on the web. Mismatched name, address or phone between schema and directory listings weakens the entity rather than strengthening it.
- Heading hierarchy and rendering. One h1 per page, no skipped levels, and the main content present in the server-rendered HTML rather than assembled after hydration. Skipped levels are easy to introduce when section labels are styled as headings but marked up as paragraphs.
The check people skip, and why it is first
Discoverability sits at the top of the list for a reason that is uncomfortable for anyone selling content. It is the only check on the list that cannot be fixed inside the codebase.
A technically flawless site with no inbound links is in a strange position: everything an audit measures comes back clean, and nothing happens. The temptation at that point is to conclude the on-page work was insufficient and to do more of it. That is the wrong inference. When on-page checks pass completely and visibility is still zero, the constraint is almost certainly discovery or authority, and both live outside the repository.
The practical consequence is that a content programme launched on a site with no links is spending its budget in the wrong order. Directory listings, a business profile, a handful of genuine references and a webmaster tools submission cost very little and unblock everything the content is supposed to achieve.
When the checklist passes
Once all eight pass, content work becomes worth doing, and the priorities change. The question shifts from whether pages can be found to whether they deserve to be, which is a judgement problem rather than a technical one.
Keep the checklist as a recurring job rather than a launch task. Technical faults are introduced by ordinary work: a framework upgrade changes rendering, a redesign restructures headings, a new section ships without schema. Running the sequence on a schedule catches these while the change that caused them is still identifiable.
Frequently Asked
What should I check before publishing new content on my site?
Work in dependency order rather than alphabetically: discoverability, crawlability, indexability, canonical integrity, redirect hygiene, sitemap accuracy, structured data validity, then heading hierarchy and rendering. Stop at the first failure, because a fault higher in the sequence usually makes everything below it irrelevant until it is fixed.
My site is technically perfect but gets no traffic. What is wrong?
That combination is diagnostic rather than contradictory. When every on-page check passes and visibility is still zero, the binding constraint is almost always discovery or authority, not on-page work. The usual cause is that nothing on the open web links to the site, so crawlers have no path in and no reason to return.
What is the difference between a 404 and a 410 for removed pages?
A 404 says the page is not found, which leaves open the possibility that it will return. A 410 says it is deliberately gone. When you have intentionally retired URLs, 410 communicates the decision clearly and tends to get them dropped from the index faster, which matters when the removed pages were content you no longer want associated with the site.
How often should this checklist be run?
Treat it as a recurring job rather than a launch task. Ordinary development introduces technical faults: framework upgrades change rendering, redesigns restructure headings, new sections ship without schema. Running the sequence on a schedule, or on every significant deploy, catches regressions while the change responsible is still easy to identify.
Want this built for your brand?
See how we approach ai seo agency dubai.