Technical SEO Checklist: 25 Checks Before You Launch (2026)

Launching a website without a technical SEO checklist is like opening a shop without checking that the door unlocks. The site may look perfect, but if search engines cannot crawl it, phones cannot load it, or pages send conflicting signals, the rankings and inquiries you are counting on will quietly go somewhere else. This is the exact pre-launch routine we run on every site we build or audit: 25 checks grouped into six areas, each with a short explanation of what to do and why it matters. Work through them in order, because crawlability problems make everything after them pointless.

Crawlability and Indexing

1. robots.txt is not blocking the site

Open yoursite.com/robots.txt and check that it does not contain a blanket block like Disallow: / left over from development. Staging sites are often set to discourage search engines, and that setting has a habit of traveling to the live site. Your robots file should allow crawling of all public pages and ideally point to your sitemap.

2. No accidental noindex tags

Check your key pages for a noindex meta tag or an X-Robots header. In WordPress, this is usually the “Discourage search engines from indexing this site” toggle under Settings, Reading. One forgotten checkbox can keep an entire site out of Google for months, and it produces no error message anywhere obvious.

3. XML sitemap exists and is submitted

Your sitemap should list only live, indexable, canonical URLs, with no redirects, no 404s, and no blocked pages. Submit it in Google Search Console and confirm Google reports it as successfully fetched. A sitemap does not guarantee indexing, but it is the clearest map you can hand a crawler.

4. No broken internal links

Run a crawl of the site and fix every internal link that returns a 404 or bounces through a redirect chain. Broken links waste crawl budget, strand pages, and send visitors into dead ends. Pay special attention to links in old blog posts, footers, and PDFs, which are easy to miss during a redesign.

5. Sensible URL structure

URLs should be short, readable, and keyword-relevant, like /local-seo/ rather than /page-id-482/. Decide on one format (with or without trailing slash, lowercase only) and stick to it everywhere. Avoid changing URLs after launch; every change costs you a redirect and a small amount of trust.

6. Redirects from the old site are mapped

If this launch replaces an existing site, every old URL that has traffic or backlinks needs a one-to-one 301 redirect to the closest matching new page. Skipping this step is one of the most common and most expensive launch mistakes we see; years of accumulated links can be thrown away in an afternoon.

Speed and Core Web Vitals

7. Images are compressed and in modern formats

Images are usually the heaviest part of a page. Convert large photos to WebP, compress them, and serve them at the size they are actually displayed. A 4000-pixel hero image shown at 1200 pixels is pure waste that your visitors pay for in load time.

8. Render-blocking resources are minimized

Audit the CSS and JavaScript loaded in the head of the page. Defer what can be deferred, remove plugins or scripts the site no longer uses, and avoid loading three libraries that do the same job. Every render-blocking file delays the moment a visitor sees anything at all.

9. Tested in PageSpeed Insights on mobile and desktop

Run your homepage and one or two key service pages through PageSpeed Insights and check both tabs. Mobile is the score that matters most, because most local searches happen on phones and Google indexes the mobile version of your site first. Treat anything in the red on mobile as a launch blocker, not a nice-to-have.

10. Core Web Vitals are measured, not guessed

Watch the three core metrics: Largest Contentful Paint (how fast the main content appears, aim for under 2.5 seconds), Interaction to Next Paint (responsiveness), and Cumulative Layout Shift (whether elements jump around as the page loads). These are worth tracking over time, not just at launch, because new content, plugins, and ads slowly drag them down.

11. Caching and server response are configured

Enable page caching and, where possible, a CDN or server-level cache so repeat visitors and distant visitors are not waiting on a cold server. Check the time to first byte in your speed test; if the server itself is slow to respond, no amount of on-page tuning will fix it, and the real answer may be better hosting.

Mobile Readiness

12. Checked on a real phone, not just a resized browser

Shrink your browser window as a first pass, then open the site on an actual phone. Real devices reveal problems emulators hide: sticky headers eating half the screen, pop-ups that cannot be closed, and click-to-call buttons that do not respond.

13. Tap targets and font sizes pass

Buttons and links need enough size and spacing for a thumb, and body text should be at least 16px so phones do not force a zoom. If visitors have to pinch and hunt on your contact page, many will simply call the next business on the list.

14. Forms work on mobile

Fill in your own contact form on a phone, start to finish. Check that fields do not trigger the wrong keyboard, error messages are readable, and the submit button stays visible. A surprising share of “our website gets no leads” problems turn out to be a broken mobile form.

On-Page Technical Essentials

15. Every page has a unique title tag and meta description

Duplicate title tags and meta descriptions confuse search engines about which page should rank and make your listings look careless in results. Each page needs its own title that reflects its actual topic and location, written for a human first.

16. One H1 per page, logical heading order

The H1 is the page’s headline; there should be exactly one, followed by H2s and H3s in order. Heading chaos (multiple H1s, skipped levels, headings used just for styling) makes the page harder for search engines and screen readers to parse.

17. Canonical tags are correct

Each indexable page should carry a canonical tag pointing to itself, and duplicate or near-duplicate versions (print pages, parameter URLs, HTTP and HTTPS variants) should canonicalize to the one version you want ranked. This stops your own pages from competing with each other.

18. Internal links point to your money pages

Your service pages should be reachable within two or three clicks from the homepage, and your blog posts should link to them with descriptive anchor text. Orphan pages with no internal links are crawled rarely and rank poorly, no matter how good they are. Our SEO services work always starts with this map of the site, because structure comes before tactics.

Structured Data for Your Technical SEO Checklist

19. LocalBusiness schema on key pages

If you serve a local area, add LocalBusiness structured data with your name, address, phone, opening hours, and service area exactly as they appear on your Google Business Profile. Consistency between schema, your website, and your profile is itself a trust signal.

20. Service, FAQ, and Article schema where they fit

Service pages can carry Service schema, blog posts should carry Article or BlogPosting schema, and pages with a genuine question-and-answer section can add FAQ schema. Use Google’s own structured data documentation as the reference, and validate everything with the Rich Results Test before launch. Add schema only for content that is actually visible on the page; markup for hidden content is against Google’s guidelines.

21. No duplicate or conflicting schema

If your SEO plugin generates schema automatically, check that your manual markup is not duplicating or contradicting it. Two Organization blocks with different phone numbers, for example, create the kind of confusion this whole checklist exists to prevent.

Security and Housekeeping

22. HTTPS everywhere, with no mixed content

An SSL certificate is non-negotiable in 2026; browsers actively warn visitors away from sites without one, and Google treats HTTPS as a baseline expectation. After enabling it, check for mixed content, meaning pages that still load images or scripts over plain HTTP, and force HTTPS at the server level.

23. Analytics and Search Console are connected

Install Google Analytics and verify Google Search Console before launch day, not after. You cannot measure growth, catch indexing problems, or prove what is working without data from day one. Confirm that test events and your own office visits are not polluting the numbers.

24. 404 page and backups are in place

Design a helpful custom 404 page that offers navigation and a search box instead of a dead end. And before you touch anything at launch, take a full backup of files and database that you have actually verified you can restore. A backup you have never tested is a hope, not a backup.

25. Post-launch monitoring is scheduled

Technical SEO is not a one-time event. Schedule a monthly crawl to catch new broken links, speed regressions, and indexing issues as content grows. Most of the problems on this technical SEO checklist creep back in slowly, one small site change at a time.

A Note on Priorities

If you are short on time, protect the non-negotiables first: crawlability (checks 1 to 6), HTTPS (check 22), mobile usability (checks 12 to 14), and unique titles (check 15). Speed and structured data are close behind. When we build sites, these checks are baked into the process rather than bolted on at the end, which is why our web development services include a full technical audit before any site goes live.

FAQs

How long does a pre-launch technical SEO check take?

For a typical small business site, a careful pass through all 25 checks takes between a few hours and a full day, depending on how many problems surface. A brand-new, well-built site is fast to verify; a redesign with hundreds of old URLs takes longer because of redirect mapping.

Can I fix technical SEO after launch instead?

Most items can be fixed after launch, but some are far cheaper before. Redirect mapping, URL structure, and the noindex setting are the classic examples: fixing them later means weeks of lost indexing and traffic while Google reprocesses the site. Speed and schema work can safely continue after launch.

What is the single most common launch mistake?

Forgetting a development setting: a noindex toggle left on, a robots.txt block carried over from staging, or the old site’s redirects never being mapped. None of these are visible when you look at the site, which is exactly why a written checklist matters.

Do I need Core Web Vitals to be perfect to rank?

No. Core Web Vitals are one signal among many, and relevant content with good links can outrank a faster page. But in local markets where competitors are otherwise similar, a slow, unstable site is a self-inflicted handicap. Aim for the “good” thresholds, not a perfect 100 score.

Before You Hit Publish

Run this list once more on launch morning, because settings change during final edits. If you would rather have a second pair of eyes, we run this exact audit as part of every launch and as a standalone check for sites built elsewhere. Talk to us via our contact page and we will tell you plainly what we find, whether you hire us or not.