The Static Site Deployment Checklist: 20 Things to Verify Before Going Live

I have deployed hibranwar.com from scratch more times than I'd like to admit. First as an Eleventy static site. Then a rebuilt Eleventy site. Then again as a PHP includes system. Each time, something slipped through. A broken sitemap URL. A robots.txt that blocked the entire site. Schema markup referencing pages that no longer existed.

Every deployment taught me the same lesson: the launch itself is not the hard part. The verification is.

After the third rebuild, I stopped trusting my memory and wrote a checklist. Not a generic "website launch checklist" from some SEO blog. A specific, ordered protocol built from real failures on a real site. Twenty items, organized by category, each one there because I got burned by skipping it at least once.

This is that checklist.

Why most checklists fail

The internet is full of "50-item pre-launch checklists." They cover everything from choosing a domain name to writing alt text. They're thorough. They're also useless for experienced practitioners, because they mix trivial items with critical ones and provide no sequencing.

A good deployment checklist is not a list of everything you should do. It's a list of things that will break your site if you skip them, ordered by when they should be checked, with a clear tool for verification.

The checklist below is organized into five categories: Crawlability, Structured Data, Content Integrity, Performance and Security, and AI Accessibility. The order matters. Start with crawlability, because nothing else matters if search engines can't reach your pages.

The deployment workflow

Before the individual items, here's how the verification fits into a deployment sequence. You don't run all 20 checks simultaneously. They follow a logical order.

The loop back is intentional. If any item fails, fix it and re-run that entire category. Don't skip ahead hoping you'll fix it later. You won't.

Category 1: Crawlability (Items 1 to 4)

Nothing else matters if crawlers can't reach your pages. This is where most deployment failures hide.

1. robots.txt returns 200 and allows target crawlers

Visit yoursite.com/robots.txt directly. Confirm it returns a 200 status code, not a 404 or 500. Then read the directives. Are you blocking anything you shouldn't be? Are you allowing the crawlers you need?

I once deployed a site with a staging robots.txt that contained Disallow: /. The site was live for eleven days before anyone noticed Google had stopped indexing everything. The old pages gradually fell out of search results. Eleven days. That's how long a silent failure can persist when nobody is checking.

Tool: Browser (direct URL visit), Google Search Console robots.txt tester.
Priority: Critical.

2. Sitemap XML is valid, accessible, and contains only live URLs

Visit yoursite.com/sitemap.xml. Check that it parses as valid XML. Then verify every URL in it returns a 200 status code. A sitemap full of 301 redirects or 404 errors is worse than no sitemap at all, because it actively wastes your crawl budget.

As I covered in Cara Membuat Sitemap XML yang Benar, auto-generated sitemaps from SSGs and CMSs frequently contain URLs that are wrong. Trailing slash inconsistencies. HTTP instead of HTTPS. Old URLs that were renamed. Don't trust the generator. Verify the output.

Tool: XML Sitemaps Validator, Screaming Frog.
Priority: Critical.

3. Sitemap is referenced in robots.txt

Your robots.txt should contain a Sitemap: directive pointing to the full URL of your sitemap. This is how many crawlers discover your sitemap. Without it, they have to guess or wait until you submit it manually through a webmaster tool.

User-agent: *
Allow: /

Sitemap: https://yoursite.com/sitemap.xml

One line. Easy to forget. Verify it's there.

Tool: Direct inspection of robots.txt.
Priority: High.

4. Canonical URLs are correct and consistent

Every page should have a <link rel="canonical"> tag pointing to its own URL. Sounds obvious. In practice, I've seen canonical tags pointing to localhost, to staging domains, to HTTP versions of HTTPS pages, and to URLs with query parameters that shouldn't be canonical.

Check the homepage, one inner page, and one deep page (like a blog post). View source. Find the canonical tag. Confirm it matches the actual URL you're visiting.

Tool: View source, Screaming Frog, Ahrefs Site Audit.
Priority: Critical.

Category 2: Structured Data (Items 5 to 9)

Schema markup is how you tell search engines and AI systems what your content is about in machine-readable format. Broken schema is invisible to humans but catastrophic for machines.

5. JSON-LD validates without errors

Run every page type through Google's Rich Results Test or Schema.org's validator. Not just the homepage. Check your about page, a blog post, a service page. Different page types have different schema, and each one can fail independently.

Common errors: missing required properties, wrong data types (string where a URL is expected), and referencing @id values that don't resolve to anything.

Tool: Google Rich Results Test, Schema Markup Validator.
Priority: Critical.

6. Person or Organization schema is present on the about page

If you're building entity infrastructure (and you should be), your about page needs a Person or Organization schema block with sameAs links to your verified profiles. This is the foundation of entity recognition. Without it, you're relying on Google to figure out who you are by inference. Google is busy. Help it.

Tool: Rich Results Test, manual JSON-LD inspection.
Priority: High.

7. WebSite schema with SearchAction is on the homepage

The WebSite schema tells Google your site exists as a coherent entity, not just a collection of pages. The SearchAction property enables sitelinks search box in search results. It's a small schema block with outsized impact on how your site appears in SERPs.

Tool: Rich Results Test.
Priority: High.

8. BreadcrumbList schema matches visible breadcrumbs

If your pages show breadcrumb navigation, the BreadcrumbList schema should match exactly. Same URLs. Same names. Same hierarchy. A mismatch between visible breadcrumbs and schema breadcrumbs is a trust signal failure. Google sees inconsistency and trusts neither.

Tool: Rich Results Test, visual comparison with rendered page.
Priority: Medium.

9. No schema references broken or non-existent URLs

This is the one that bit me during a rebuild. I had schema markup referencing pages from the old URL structure. The schema was syntactically valid. The URLs returned 404. Google's validator doesn't check URL availability. It only checks syntax. So the schema "passed" validation while pointing to dead pages.

Crawl every URL inside your schema blocks. Confirm they all return 200.

Tool: Custom script, Screaming Frog (crawl URLs extracted from JSON-LD).
Priority: High.

Category 3: Content Integrity (Items 10 to 14)

The pages exist. Crawlers can reach them. Schema is valid. Now make sure the content itself is correct.

10. No internal links return 404

Crawl the entire site and check every internal link. Broken internal links damage both user experience and crawl efficiency. On a static site, this is especially common after reorganizing URL structures.

I keep a simple rule: after every deployment, run Screaming Frog against the live URL. Sort by status code. Fix every non-200 internal link before doing anything else.

Tool: Screaming Frog, Linkchecker, W3C Link Checker.
Priority: Critical.

11. Hreflang tags are reciprocal and self-referencing

If your site is bilingual, this is where things get subtle. As I detailed in The hreflang Tag: Setting Up Bilingual SEO Correctly, hreflang implementation requires both self-referencing and reciprocal tags. Every English page must reference the Indonesian version and itself. Every Indonesian page must reference the English version and itself. Plus x-default.

One-directional hreflang is worse than no hreflang. Google discards the entire cluster.

Tool: Screaming Frog (hreflang report), Ahrefs, manual view-source check.
Priority: High (if multilingual site).

12. Meta titles and descriptions are unique per page

Duplicate meta titles across pages is one of the most common issues I find in site audits. It happens when a template has a fallback title and nobody overrides it per page. Or when someone copies a page file and forgets to change the metadata.

Export all meta titles and descriptions. Sort. Look for duplicates. Each page should have a unique title under 60 characters and a unique description between 150 and 160 characters.

Tool: Screaming Frog, Google Search Console (Coverage report).
Priority: High.

13. Open Graph and Twitter Card tags render correctly

Share your homepage and one inner page on Facebook, LinkedIn, and Twitter (using their debug/preview tools). Confirm the title, description, and image all render correctly. OG tags are invisible until someone shares your link. By then it's too late to fix a broken preview that makes your site look unprofessional.

Tool: Facebook Sharing Debugger, Twitter Card Validator, LinkedIn Post Inspector.
Priority: Medium.

14. 404 page exists and returns correct status code

Visit a URL that doesn't exist on your site. Two things should happen: you see a helpful 404 page, and the HTTP response code is actually 404. A surprising number of sites show a custom error page but return a 200 status code. This is called a "soft 404" and it confuses search engines, because they think the page is real content.

Check the response code in your browser's developer tools (Network tab), not just the visual appearance.

Tool: Browser DevTools (Network tab), curl.
Priority: High.

Category 4: Performance and Security (Items 15 to 17)

These items affect both user experience and search ranking signals.

15. HTTPS works and HTTP redirects to HTTPS

Visit the HTTP version of your site. It should redirect to HTTPS with a 301 status code. Not a 302. Not a meta refresh. A 301 permanent redirect. Then check that the HTTPS certificate is valid, not expired, and covers your exact domain (including www if you use it).

Tool: Browser address bar, SSL Labs Server Test.
Priority: Critical.

16. Core Web Vitals pass on mobile and desktop

Run Google PageSpeed Insights against your homepage and one inner page. You need passing scores (green) for Largest Contentful Paint, First Input Delay (or Interaction to Next Paint), and Cumulative Layout Shift. On a static site, these should be easy to pass. If they're not, something is wrong with your asset loading.

Tool: Google PageSpeed Insights, Chrome Lighthouse.
Priority: High.

17. Security headers are present

At minimum, verify these headers exist: X-Content-Type-Options: nosniff, X-Frame-Options: DENY (or SAMEORIGIN), and a basic Content-Security-Policy. On shared hosting, you set these in .htaccess. They prevent clickjacking, MIME-type confusion, and script injection.

Not glamorous. Not optional.

Tool: SecurityHeaders.com, Browser DevTools (Response headers).
Priority: Medium.

Category 5: AI Accessibility (Items 18 to 20)

Traditional SEO checklists stop at item 17. In 2026, that's insufficient. AI search systems (ChatGPT, Gemini, Perplexity) crawl your site using their own bots. If you block them or fail to provide the signals they need, you're invisible in AI-generated responses.

18. AI crawlers are not blocked in robots.txt

Check your robots.txt for explicit blocks on GPTBot, ClaudeBot, PerplexityBot, or any other AI crawlers. Also check your server configuration. Some hosting providers and CDNs block AI crawlers at the server level, which overrides robots.txt permissions ^[1].

The decision to allow or block AI crawlers is yours. But make it deliberate, not accidental. Many sites block AI crawlers because a security plugin added a rule nobody noticed.

Tool: robots.txt inspection, server log analysis.
Priority: High.

19. llms.txt file is present and accurate

The llms.txt convention is emerging as a way to provide AI systems with a structured summary of your site's content. Think of it as a sitemap for language models. It sits at yoursite.com/llms.txt and contains a concise, machine-readable overview of what your site is about, what pages are most important, and what topics you cover ^[2].

This is not yet a standard. Support is uneven. But the cost of creating one is near zero, and the potential upside is being cited correctly when an AI system summarizes your domain.

Tool: Manual creation and direct URL verification.
Priority: Medium.

20. Content is accessible without JavaScript rendering

AI crawlers, by and large, do not execute JavaScript. If your content is rendered client-side (React, Vue, Angular without SSR), AI crawlers see an empty page. Static sites have a natural advantage here. Your HTML is the content. No rendering required.

But verify it. Disable JavaScript in your browser and visit your site. Is all the important content visible? Are navigation links functional? Static sites should pass this easily. If yours doesn't, you have JavaScript dependencies you didn't know about.

Tool: Browser with JS disabled, curl (view raw HTML).
Priority: High.

Summary table: all 20 items

How I actually use this checklist

I print it. Literally. A single sheet of paper with the 20 items and checkboxes. Every deployment, I go through it sequentially. Pen marks. No shortcuts.

This sounds primitive. It is. That's the point.

The aviation industry figured this out decades ago. Atul Gawande wrote an entire book about it (The Checklist Manifesto). The reason checklists work is precisely because they're boring and mechanical. They don't rely on you remembering everything. They don't rely on you being alert at 2 AM when the deployment finally works and you just want to go to sleep.

The checklist doesn't care how tired you are. It just asks: did you check robots.txt?

The order matters more than the items

You might look at this list and think, "I know all of these." Maybe you do. The value is not in knowing. It's in sequencing.

Check crawlability first, because if crawlers can't access your site, validating your schema is pointless. Check structured data second, because broken schema with live pages is worse than no schema with live pages. Check content integrity third, because a site that's crawlable with valid schema but full of 404 links is still broken. Check performance and security fourth, because a slow or insecure site that's otherwise correct will still lose ranking. Check AI accessibility last, because it builds on everything else.

Each category assumes the previous one passed. That's why you loop back on failure. Don't fix item 18 while item 2 is still broken.

What this checklist doesn't cover

This is a deployment verification checklist, not a website quality checklist. It does not cover:

• Content quality or writing standards
• Visual design or brand consistency
• User testing or conversion optimization
• Backlink strategy or off-page SEO
• Analytics configuration (though you should verify that too)

Those are separate concerns with separate checklists. Mixing them into a single list is how you end up with 50-item monsters that nobody actually uses.

Twenty items. Five categories. One sequence. Use it every time.