A website launch is a deadline, and deadlines compress judgment. In the final days before a site goes live, teams are triaging bugs, approving copy, coordinating redirects, and making visual adjustments — rarely stopping to ask whether the design decisions made three months earlier are going to hold up in search. By the time anyone runs a formal SEO audit, the site is already live and already losing ground on rankings it could have earned from day one.
This checklist is built for the phase before launch: the period when design and development decisions are still adjustable, when structural choices haven’t hardened into expensive technical debt. It covers 40 factors across six areas — site architecture, performance, mobile experience, semantic structure, internal linking, and on-page signals. None of these require a specialist to evaluate. They require attention, and time to fix things before they’re locked in.
Why a Pre-Launch Audit Is Different
Most SEO audits are retrospective. They’re run on live sites, often months after launch, and their recommendations become a remediation backlog rather than a build checklist. The problem with that sequence is that some of the most consequential SEO factors — URL structure, heading hierarchy, site architecture, redirect strategy — are extremely costly to change post-launch. Restructuring URLs requires 301 redirects and risks ranking disruption. Flattening a bloated site hierarchy means rethinking navigation and internal linking from scratch. Fixing semantic HTML across a template-driven CMS means touching every page.
A pre-launch audit surfaces these issues while they’re still design problems, not infrastructure problems. It shifts the conversation from “here’s what we need to fix” to “here’s what we need to get right.”
Site Architecture (8 factors)
Site architecture determines how Google discovers, crawls, and weights your content. Before launch, confirm:
- Every important page is reachable within three clicks from the homepage
- The URL structure is clean, descriptive, and consistent (no session IDs, no arbitrary parameters)
- Canonical tags are implemented correctly on all paginated, filtered, or duplicate-risk pages
- The XML sitemap includes all indexable pages and excludes paginated, filtered, and utility pages
- The robots.txt file is not accidentally blocking crawlers from key sections
- There are no orphaned pages — every page has at least one internal link pointing to it
- Redirect chains from old URLs are resolved to single 301s, not daisy-chained hops
- The navigation taxonomy reflects user intent, not internal organizational logic
Performance and Core Web Vitals (10 factors)
Google’s Core Web Vitals — Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP) — are direct ranking signals. Performance issues that are caught pre-launch are design problems. Post-launch, they’re technical debt.
- LCP is under 2.5 seconds on mobile (test with PageSpeed Insights, not just desktop)
- CLS score is below 0.1 — no layout shifts caused by images loading without declared dimensions, fonts swapping, or ads injecting into the layout
- INP is under 200ms — the page responds to user interactions without delay
- Hero images are sized correctly, compressed to WebP or AVIF, and not blocking render
- Custom fonts use font-display: swap or optional to prevent invisible text during load
- Render-blocking scripts are deferred or async
- Third-party scripts (analytics, chat widgets, pixels) are loaded after critical content
- Images below the fold use lazy loading
- CSS is not loaded globally when it’s only needed on specific page types
- The page passes Core Web Vitals assessment in Google Search Console’s lab data before launch
Mobile Experience (6 factors)
Google crawls the mobile version of your site first. What ranks is the mobile experience, not the desktop one.
- All tap targets are at least 44×44px — buttons, links, and navigation items are finger-friendly
- Font sizes are legible at 16px or above without zooming
- No horizontal scroll on any viewport under 375px
- Sticky headers and footers don’t consume more than 20% of the visible viewport
- Pop-ups and interstitials either don’t appear on mobile, or are easily dismissible and don’t cover the primary content
- The mobile navigation is genuinely usable — not just a collapsed version of a desktop menu
Semantic HTML and Structured Data (8 factors)
Semantic structure is how you communicate content hierarchy to search engines. It’s also the foundation of accessibility. These two goals are almost always aligned.
- Every page has exactly one H1 that accurately describes the page’s primary topic
- Heading levels (H2, H3, H4) follow a logical hierarchy — no levels are skipped for stylistic reasons
- Navigation is wrapped in a element; the main content is wrapped in
- Every image has descriptive alt text that conveys meaning, not just filenames
- Article and blog content is wrapped in elements
- No meaningful text is rendered as an image or inside a canvas element
- Schema markup is implemented for article, breadcrumb, and local business where applicable
- No duplicate title tags or meta descriptions exist across the site — each page has a unique, keyword-informed title under 60 characters
Internal Linking (4 factors)
Internal links distribute authority and help search engines understand which pages are most important. A site that relies entirely on navigation for internal linking is leaving most of its link equity concentrated at the top level.
- Key service and landing pages are linked from within body content — not just from navigation
- Related posts or content modules create natural pathways between topically adjacent pages
- Anchor text for internal links is descriptive, not generic (“learn more,” “click here”)
- No internal links return 404 errors — all links are validated before launch
On-Page Signals (4 factors)
These are the signals that most SEO checklists lead with, but which matter less than architecture and performance when the underlying structure is broken.
- The primary keyword appears in the H1, the first paragraph, and at least one H2
- The page title tag matches search intent — informational pages use informational framing, not sales language
- The meta description is written to earn the click, not to stuff keywords
- Image file names are descriptive — chicago-web-design-homepage.webp rather than IMG_4872.jpg
How to Use This Checklist
The most effective way to work through this list is in two passes. The first pass happens during development — ideally two to three weeks before launch, while there’s still time to make structural changes. The second pass happens 48 to 72 hours before launch, as a final verification that nothing was broken during the final push.
Assign ownership clearly. Site architecture and URL structure belong in the development review. Performance and Core Web Vitals belong with the front-end developer. Semantic HTML and structured data can be reviewed by either development or a content lead. Internal linking and on-page signals belong with whoever owns the content.
The goal isn’t a perfect score on every factor before launch. It’s ensuring that the issues most expensive to fix post-launch — architecture, structure, performance — are resolved before the site goes live, and that the remaining items have a clear owner and timeline. A site that launches with a known remediation plan is in a substantially better position than one that launches without having asked the questions at all.
For teams working with an agency, this checklist is also a useful brief. If your design and development partner can’t walk through these factors with you before launch, that’s a signal about how they think about the relationship between design quality and search performance — and whether those two things are, in their process, the same goal or separate ones.
ArtVersion designs and builds websites with SEO performance built into the process, not bolted on afterward. Learn more about our web design services.