a technical seo audit checklist for a live marketing site.

A technical SEO audit checks whether search engines can find, crawl, understand and index the pages of a site that is already live. Work through it in order: crawl and index first, then urls and canonicals, on-page basics, internal links, speed, mobile, structured data and security. Fix blockers before polish. A page that cannot be indexed will not rank, however good it is.

Each item below is one thing to check and why it matters.

crawl and index

• robots.txt does not block important paths. A single stray disallow rule can hide a whole section from search. Open the file and read it.
• noindex appears only where you intend it. Check both the meta robots tag and the X-Robots-Tag response header. Headers are easy to miss, and a leftover setting from staging can quietly remove pages from search.
• The xml sitemap lists only canonical, indexable pages that return 200. Redirected, blocked or duplicate urls in a sitemap send mixed signals. Submit it in Search Console.
• The page indexing report in Search Console has been read. Look at the reasons pages are not indexed: discovered or crawled but not indexed, redirect, duplicate without a chosen canonical. Each reason points to a different fix.
• No orphan pages. Every page should be linked from at least one other page. A sitemap entry alone is a weak signal that a page matters.

urls, redirects and canonicals

• One version of the site. Choose https, one host name and one trailing-slash rule, then redirect everything else to it. Otherwise the same page exists at several addresses.
• Redirects are permanent and single-hop. Old url to final url, with no stops between. Chains slow crawling and loops break it.
• Every indexable page has a self-referencing canonical. It tells search engines which address is the one to index.
• Canonicals never point to a redirect or a non-200 page. A canonical aimed at a dead end is ignored or misread.
• Missing pages return a real 404. A “not found” page that returns 200 is a soft 404 and wastes crawl attention. Request a made-up url and check the status code.

on-page basics

• Unique title and meta description on every page. Duplicates make pages hard to tell apart in results.
• One h1 per page, with headings in order. The structure should read like an outline of the page.
• No duplicate or near-duplicate pages chasing the same query. They split attention and often get left out of the index. If you find sets of pages that differ by a swapped word, read doorway pages and deindexing before deciding what to merge.

internal links

• Important pages are reachable within a few clicks of the home page. Depth signals importance, and deep pages get crawled less.
• Anchor text describes the destination. “Read more” tells a crawler nothing. “Pricing for lead generation” does.
• No links to redirected or broken urls. Update them to point straight at the final page.

speed and core web vitals

Check the Core Web Vitals report in Search Console and the field data behind it, not a single lab score from one test run. Field data reflects real visitors. Google’s published “good” thresholds are an LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less.

The usual fixes:

• Resize and compress images, and serve modern formats.
• Remove or defer render-blocking scripts.
• Cut third-party scripts you do not need. Each one costs load time.
• Give images, fonts and embeds set dimensions so the layout does not jump as they load.

mobile and accessibility basics

• The site works on a phone. Open your key pages on one and complete the main action.
• Tap targets are big enough to hit and are not crowded together.
• Text is readable without zooming.
• Images have meaningful alt text. It helps people using screen readers and helps search engines understand the image.

structured data

• Markup is valid and matches what is visible on the page. Markup describing things the visitor cannot see risks being ignored.
• Organization and breadcrumb markup are in place where they apply.
• FAQ markup appears only where the FAQ is visible.
• Test with Google’s Rich Results Test, and watch the enhancement reports in Search Console for errors.

security and hygiene

• https everywhere, with no mixed content. An insecure image or script on a secure page can trigger browser warnings.
• Staging and preview sites are not indexable. Block them with authentication, not just a robots rule.
• The business owns its analytics and Search Console access. If only a former agency or developer can log in, you cannot check anything.

how to run it

You need three things: a crawler, Search Console and a list. Crawl the whole site and export the results. Compare them with what Search Console says is indexed. Put every problem on the list with the number of pages it affects.

Then fix by impact. Indexing blockers come first, then redirects and canonicals, then everything else. Re-check after each fix so you know it worked and did not break something nearby. Repeat the audit every quarter, and after any redesign or migration.

Automate what you can. On our own product, PDFOak, an audit found a page that worked and passed the build but was missing from the sitemap, so it would never have been submitted. The fix was an explicit sitemap entry and an automated audit that crawls every sitemap url’s canonical, title, description, h1, structured data and internal links. A manual checklist finds a problem once, and an automated check keeps it from coming back.

Once the fixes are in, track the results as described in what an SEO agency should report, and allow time for them to show, as covered in how long SEO takes.

Our website SEO service starts with a technical audit and fixes speed, indexing, structure, schema and internal links, done by our own developers rather than handed back as a PDF.