The Technical SEO Checklist We Run Before a Site Goes Live

Launch is a crawl problem first

A site can look finished and still be a mess to index. Two hosts, two slash styles, a sitemap that lists URLs the page redirects away from, and HTML that is an empty shell until JavaScript paints the heading. Google does not owe you a recovery month because the banner was approved. The checks below are what we run on an ASP.NET site before DNS cuts over — and again the morning after, when staging habits have a way of following you.

This is not a content strategy. It is the boring agreement between what the page says, what the canonical says, and what you submit. Speed belongs here only where it blocks a first paint of real HTML. The longer vitals argument is in Core Web Vitals explained. Do not use that article as an excuse to skip canonicals.

We run this on sites we build and on sites we inherit. The stack is usually ASP.NET Core, sometimes an older Framework app with a new front. The checklist does not care about your theme. It cares whether a crawler and a human land on the same document.

One host, one slash, one canonical

Pick https, pick www or not, pick trailing slash or not. Then make every other shape redirect once, to that shape. A chain — http to https to www to slash — wastes crawl time and loses referrers. ASP.NET’s HTTPS redirection and a single host rule should do this. If IIS and the application both redirect, you will invent a loop on one path and a 200 on another. Test with curl, not only with a browser that hides hops.

Canonical tags must name the same URL you redirected to. A page at https://example.com/services/web-development that canonicals to the slash version, while the slash version 301s back, is a fight with yourself. On this site the canonical form is without a trailing slash, except the root. The sitemap emits that form on purpose so every loc matches the tag. Your site can choose the other slash. It cannot choose both.

Query strings that do not change the document should not create a second indexable URL. Sort orders, UTM leftovers, and “?page=1” on the first page are how you split signals. Canonicalise them to the clean URL, or noindex the parameter versions if they must exist. Do not leave them as equal siblings.

Staging and preview hosts must not be indexable. A leftover noindex on production is the opposite disaster. We have seen both in the same week: a staging site that ranked for the brand, and a live site that politely asked not to be indexed because someone copied appsettings.Development behaviour. Check the live HTML, not the intent.

Indexable HTML, not a shell

The first response should contain the heading, the first paragraph, and the links you care about. If those appear only after a script runs, you are hoping the crawler executes your stack the way a developer’s laptop does. Hope is not a launch check. View source, or fetch without JavaScript. If the article is missing, you are not ready.

ASP.NET Razor is an advantage here if you use it as HTML. It becomes a disadvantage if the layout is an empty div and a SPA boot. A business site does not need a client router for Services and Contact. Ship the document. Enhance if you must. Do not invert that.

One H1 that matches the job of the page. The public template already prints the title as H1 — so the body must not print another. This series does not put H1 in the article HTML for that reason. Duplicate H1s are not a penalty so much as a sign you do not know what the page is. Two titles in two tags are how snippets go wrong.

Title and meta description: one each, unique enough that two services do not share a sentence. Length is secondary to truth. A description that promises a calculator you did not ship is a bounce, which is a ranking problem later. Soft 404s — a pretty page that says “coming soon” with a 200 — are worse. Return 404 when the thing is not there.

Sitemap and robots that tell the same story

The sitemap should list the canonical URLs you want indexed, and only those. No admin. No thank-you pages. No empty category hubs. No URLs that 301. Lastmod should move when the document moved, not on every deploy of the CSS. Submitting a sitemap full of redirects is how you teach Search Console not to trust you.

On an ASP.NET site we generate /sitemap.xml from the published pages, services, posts, and knowledge articles. It is an endpoint, not a file someone uploaded in 2023 and forgot. If you are still serving a static sitemap.xml from wwwroot, it will rot the first week a slug changes. Generate it, cache it briefly, and keep the loc shape aligned with the canonical tag.

The same is true of /llms.txt. That URL is a generated text endpoint for AI crawlers — a curated list of services, work, and knowledge pages — not a hand-edited file in the repo that will disagree with the live catalogue. If you add a static llms.txt under wwwroot, you now have two sources of truth. Do not. Point robots and docs at the action that reads the database.

robots.txt should name the sitemap with the canonical host. It should disallow the account and health URLs, not the public site. Do not list your hidden admin path in robots. That file is public. Disallow is not authentication. Noindex and a login are what keep a back-office out of the index; advertising the path is a gift to scanners.

Search Console before you celebrate

Verify the property on the host you actually launched — URL-prefix or domain, but know which. Submit the sitemap. Fetch a handful of money URLs with URL Inspection. Read the rendered HTML if the tool offers it. Confirm the canonical Google picked is the one you meant. If Inspection says “crawled – currently not indexed” on the homepage, you do not have a content problem yet. You have a launch problem.

Set the preferred domain by redirects, not by a setting you remember from an older webmaster tool. International targeting is not a Kerala SME default. Do not click it because a plugin offered a flag.

If the site replaces an old one, map the old URLs. A new ASP.NET information architecture that 404s last year’s service pages will donate that equity to whoever still ranks. A redirect sheet is part of go-live, not a phase two. Test the top twenty old URLs from Search Console and from the old sitemap, if you have it.

Wait for field data on vitals. Shipping on Monday and panicking on Wednesday because the chart is flat is how you get a second, worse deploy. Inspection and a phone are the first forty-eight hours. The field bucket lags. That is in the vitals article; it belongs here so nobody “optimises” the launch away.

ASP.NET leftovers that bite on night one

Development error pages and swagger endpoints must not be public. A detailed exception on a live URL is a content leak and a trust leak. Environment must be Production. UseDeveloperExceptionPage is not a feature you leave “until we are sure”.

Trailing-slash middleware and your canonical helper must agree. We have fixed sites where the app added a slash and the reverse proxy removed it. The HTML looked fine in the office because the proxy sat in front. The sitemap, generated inside the app, listed the other shape. Pick one place that owns the URL.

Pagination and filter routes: if they are thin or infinite, noindex them or give them a canonical to the hub. A tag page for every blog label is how a small site becomes a thousand URLs with the same three sentences. Launch with the hubs you will maintain.

hreflang only if you truly have language-or-region variants. A single English site in Kerala does not need a theatre of alternate tags. Wrong hreflang is worse than none.

Structured data: only what you can stand behind. Organisation and, where true, LocalBusiness. Do not mark every article as a Product. Do not invent ratings. Invalid JSON-LD is a Search Console report you will ignore until it is a rich-result loss. Validate a sample, not a wish.

The morning-after pass

1. Home, one service, one blog post, contact: fetch as Google, confirm canonical and indexability.
2. Open /sitemap.xml and spot-check that each loc returns 200 and matches the canonical.
3. Open /robots.txt and confirm the sitemap line uses the live host.
4. Open /llms.txt and confirm it lists live services, not staging names.
5. Search site: your domain after a few days; if staging or thank-you pages appear, act.
6. Click the old URLs you promised to keep. Watch the hop count.

If any of those fail, you are still in launch. Marketing can wait an afternoon. Indexing the wrong host for a week is slower to undo than a delayed campaign.

What we do not do in launch week

We do not install an SEO plugin that writes a second sitemap and a second canonical. We do not buy links. We do not rewrite titles every day to “see what sticks”. We do not block the site in robots “until the client approves” and then forget. We do not treat Lighthouse as Search Console.

We do not launch ten thin location pages that share a paragraph and a city name. If you have two branches, two honest pages with hours and a pin. If you have a service area and no office, say that on one page. Fabricated locality URLs are how a new site earns a reputation you will pay to unwind.

This checklist is part of web development when we ship a site. It is not a retainer PDF. Once the property is clean, you write pages worth ranking. Technical SEO after that is change control: new templates get dimensions and a canonical, new slugs get a sitemap row, killed slugs get a redirect. The generated endpoints stay generated. That is the whole habit.

If you are inheriting a site that already ranks and you are moving it to ASP.NET, run this list on the staging host with a hosts-file cutover, then again on the live host. The second run is where www and certificates surprise you. Budget the day. A migration that “only changed the CMS” always also changed the URLs. Pretending otherwise is how you donate August.