We use cookies to improve your experience. By continuing to use this site, you agree to our Privacy Policy.
Your site can look ready and still be invisible to Google. Find out why.
Georgiana Nutas
-1600x900.webp)
Written by
Georgiana Nutas
Building modern web applications at BluDeskSoft. We write about what we learn along the way.
We'd love to chat about your project. First consultation is always free - no strings attached.
Build a secure, scalable multi-tenant SaaS with Supabase using RLS and tenant isolation.
A pre-launch technical SEO checklist is one of those things nobody thinks about until a website is technically finished and someone asks a slightly uncomfortable question: “Is Google actually going to be able to find this?”
The homepage looks good. The forms work. The client has approved the design. The team is ready to launch.
And yet, somewhere in the <head> of the page, a noindex tag may still be sitting there from staging.
Or the canonical URL points to the old domain.
Or the sitemap contains URLs that no longer exist.
None of these problems necessarily makes the website look broken to a human visitor. That is exactly why they are so easy to miss.
Technical SEO should not be a panic check after deployment. It should be part of the launch process.
Here are the 15 things we would check before pressing publish.
Most development teams have systems for catching code problems.
There are linters.
Automated tests.
Type checking.
Build checks.
Pull request reviews.
If a variable is unused, somebody knows about it.
SEO is often different.
A title tag can be duplicated across 20 pages, and the website still builds perfectly. A canonical can point to the wrong URL without producing a visible error. A staging noindex rule can make it all the way to production while every page still looks exactly as expected.
That gap is one reason we built LintPage. It runs dozens of automated checks around crawlability, metadata, structured data, performance, and other pre-launch issues because many of these mistakes are easier to catch automatically than by staring at a finished page.
You do not need a specific tool to follow this checklist, though.
You just need to check the right things before launch.
BluDeskSoft-2-800x450.webp)
noindexStart here.
Seriously.
Development and staging environments are often intentionally hidden from search engines. That is fine.
The problem starts when the same rule reaches production.
A page containing:
<meta name="robots" content="noindex">
is explicitly telling compliant search engines not to include that page in their search results.
Google's own documentation confirms that noindex can prevent a page from appearing in Google Search once the crawler sees the directive.
Before launch, check the rendered HTML of every important page template, not just the homepage.
Pay particular attention to:
One forgotten setting can quietly undermine weeks of work.
robots.txtNext, open your site's robots.txt.
Look for accidental rules that prevent search engines from crawling areas that should be public.
A particularly painful example would be something like:
Disallow: /
That makes sense on some staging environments.
It makes considerably less sense on your new production website.
Also remember that robots.txt and noindex do different jobs. Blocking crawling through robots.txt does not work as a reliable substitute fornoindex, because a crawler may be unable to access the page and therefore unable to see the indexing directive.
Google explains this distinction in its crawler documentation.
Canonical tags help search engines understand which URL represents the preferred version of a page when similar or duplicate URLs exist.
For example, your website might technically expose variations such as:
/product
/product/
/product?source=email
Ideally, search engines should understand which version is the main one.
Before launch, make sure:
This becomes especially important during migrations.
Google uses several canonicalization signals, including redirects, sitemap inclusion, and rel="canonical" annotations.
A canonical tag is tiny.
The consequences of getting it wrong are not.
During development, titles are easy to forget.
You will see things like:
Home
New Page
Untitled
Copy
or the same brand title repeated everywhere.
Before launch, check that important pages have unique titles that clearly describe what the page is about.
You do not need to turn every title into an SEO formula.
Just make it useful.
Bad:
Services | BluDeskSoft
Better:
Custom Web Application Development | BluDeskSoft
The goal is to help both users and search engines understand the page before they even open it.
Meta descriptions are another common casualty of the rush to launch.
They do not need to be literary masterpieces.
They should simply explain why someone should click.
Avoid reusing the same description across every page, and make sure placeholder content hasn't survived from development.
For key commercial pages, write them manually.
A service page and a case study should not describe themselves in exactly the same way.
A page can look visually perfect, but its HTML hierarchy can be messy.
A giant sentence styled as a heading may actually be a <div>.
Three sections may all use H1 tags.
Or the page may not contain an H1 at all.
For most standard pages, the structure should be simple:
H1: the main topic of the page
H2: major sections
H3: subsections within those sections
Do not choose heading levels because of how large you want the text to appear. Styling belongs in CSS.
HTML should describe structure.
This helps with SEO, accessibility, and maintainability.
This is one of the most boring checks on the list.
It is also one of the most useful.
A redesign often changes URLs.
A blog post gets renamed.
A service page disappears.
Navigation changes.
An old footer link survives.
The result is a collection of internal links leading visitors to 404 pages.
Before launch, crawl the entire website and check:
Do not assume that because navigation works, internal linking works.
The forgotten links are usually buried inside old content.
If you are replacing an existing website, make a URL map before launch.
Old URL:
/web-development-services
New URL:
/services/custom-web-applications
If the original page had traffic, backlinks, or rankings, simply deleting it wastes that history and sends existing visitors to a 404.
Use a permanent redirect when the old page has a relevant new destination.
But avoid redirecting every deleted URL to the homepage just because it is convenient.
Google specifically advises against redirecting many unrelated old URLs to one irrelevant destination because that can confuse users and may be interpreted as a soft 404.
The correct redirect is not always the homepage.
Sometimes the correct response really is a 404.
Your sitemap should represent the URLs you actually want search engines to discover.
Before launch, check that it does not include:
noindex pagesAnd make sure important pages are included.
Google recommends using fully qualified canonical URLs in your sitemap and notes that many CMS platforms can generate one automatically.
Google's official sitemap guidance
Generating a sitemap automatically is useful.
Blindly trusting the generated sitemap is not.
Check it.
Do not wait two weeks after launch to open Search Console.
Set it up as part of the deployment process.
After launch, you should be able to:
For a new or migrated site, inspect a handful of critical pages manually immediately after deployment.
Homepage.
Main service page.
Important landing page.
Recent article.
Do not inspect 300 URLs one by one.
Look for obvious configuration problems early.
If your site uses structured data, make sure the markup actually matches the visible content.
Common examples include:
Do not add schema simply because somebody said: “schema is good for SEO.”
Use the appropriate type and provide accurate data.
Structured data should describe the page that exists, not the page you wish existed.
Also test it after the production build. Server-side rendering, CMS fields, and environment differences can occasionally produce different output than expected.
Open Graph metadata isn't the same as ranking optimization, but it deserves a place in a real launch checklist.
Someone launches the website.
They proudly paste the link into LinkedIn.
And the preview displays:
Not ideal.
Check:
og:titleog:descriptionog:imageYour website will be shared somewhere.
Make sure the first share does not become the first bug report.
A desktop Lighthouse score can make you feel very good about a website.
Then you test mobile.
Reality arrives.
Large hero images, third-party scripts, custom fonts, and heavy JavaScript can behave very differently on slower devices and connections.
Google's current Core Web Vitals focus on three metrics:
The recommended “good” thresholds are LCP within 2.5 seconds, INP of 200 milliseconds or less, and CLS of 0.1 or less, measured at the 75th percentile of page visits.
Read the official Core Web Vitals guidance on web.dev
Do not obsess over achieving a perfect 100 in every lab test.
Look for problems users will actually feel:
A page that takes too long to become useful.
A button that responds slowly.
Content jumping around during load.
Those matter more than bragging rights.
Images deserve their own check because they can create several different problems at once.
Before launch, look for:
Huge files.
A 5 MB hero image probably shouldn't make it into production.
Missing dimensions.
Images without reserved space can contribute to layout shifts.
Missing alternative text.
Meaningful images should have useful alt text. Decorative images don't need keyword-stuffed descriptions.
Wrong formats.
Modern formats and proper responsive image handling can significantly reduce unnecessary payload.
Broken images.
Especially inside migrated blog content.
This is another area where automated checks help, because nobody enjoys manually opening 70 old articles to find one broken image.
Strictly speaking, analytics is not an indexing factor.
Practically speaking, launching without working analytics makes every SEO decision after launch harder.
Make sure you are tracking the actions that matter.
Not every click.
The important ones.
For a typical business website, that might mean:
Then actually test them.
Submit the form yourself.
Book a test meeting.
Click the CTA.
Open your analytics platform and confirm the event arrives.
A conversion event configured in a spreadsheet is not the same as a conversion event that actually works.
This is the check teams skip because they already QA'd staging.
Do it again.
Production is a different environment.
Different variables.
Different URLs.
Different redirects.
Different caching.
Possibly different headers.
Possibly different CDN behavior.
Launch the website, then crawl it as if you had never seen it before.
Look for:
noindexThink of it as the technical equivalent of walking back into the house after moving and checking whether you left anything behind.
If 15 individual checks feel like a lot, divide them into four questions.
Check robots rules, indexing directives, and status codes.
Check titles, headings, canonicals, structured data, and sitemaps.
Check performance, mobile experience, images, links and accessibility basics.
Check Search Console, analytics, and conversion tracking.
That is usually enough to keep technical SEO from becoming an abstract specialist task.
It becomes part of shipping a website properly.
Most of these mistakes are not complicated.
That is what makes them frustrating.
A website can represent months of strategy, design, and development, then lose visibility because of one forgotten environment setting or an old canonical URL.
The solution is not more panic after launch.
It is a repeatable process before launch.
At BluDeskSoft, that experience eventually pushed us to build LintPage: we wanted the same kind of automated safety net for pre-launch SEO that developers already expect from their code.
But whether you use a tool or a manual checklist, the principle is the same:
Do not ask whether the website looks finished.
Ask whether it is actually ready to be found, understood, and used.
If you are preparing a new website, migration, or web application and want another set of eyes on the technical side before launch, you can see how we approach web projects at BluDeskSoft.
Because discovering a serious SEO problem five minutes before launch is annoying.
Discovering it five weeks after launch is expensive.