5 Things I Check Before Deploying a New Website

Thing #1: I Check All Redirects and URLs

This is the one that's caused the most damage, in my experience, and it's almost always preventable. When a website changes its URL structure - whether that's a full redesign or just a reorganization of existing pages - every old URL that search engines have indexed and every old link that exists anywhere on the internet pointing to your site suddenly points to nothing, unless you've told the server where that content moved.

This is what 301 redirects are for. A 301 tells browsers and search engines, permanently, that a page has moved to a new location. Skip this step, and you get broken links, frustrated users hitting 404 pages, and search engines slowly downgrading your visibility because a chunk of your previously indexed pages now lead nowhere.

I worked on a redesign for a services company a while back where the old site had blog URLs structured like /blog/post-name, and the new site moved everything to /resources/post-name. Nobody flagged this before launch. Within about ten days, organic traffic had dropped by close to forty percent. We mapped and implemented redirects for every old URL we could find in Search Console and historical analytics, and traffic recovered over the following month - but that's a month of lost visibility that didn't need to happen.

Before any deployment now, I pull a full list of existing indexed URLs, compare them against the new site's structure, and make sure every single one that's changing has a redirect pointing somewhere relevant. Not just to the homepage as a lazy catch-all. To the actual new equivalent of that specific page.

Thing #2: I Verify Technical SEO Basics

Deployment day is the best possible time to catch technical SEO issues, because everything is fresh in your mind and you're already going through the site page by page anyway.

I check title tags on every important page, making sure none are missing, duplicated, or left as some placeholder text from development. Same with meta descriptions. I check that every page has exactly one H1 - not zero, not three - which happens more often than you'd think when different sections get built by different people or pulled from different templates.

Canonical tags get a close look too. I've seen staging environments accidentally leave canonical tags pointing to the staging URL instead of the production domain, which is a quiet but serious problem if it makes it into the live site.

robots.txt and the XML sitemap both get checked manually, not just assumed to be correct. I've seen a robots.txt file accidentally blocking the entire site from being crawled, left over from a staging environment configuration that nobody updated before going live. That one is particularly nasty because the site looks completely fine to a human visitor. Search engines, meanwhile, can't see any of it.

Schema markup, where relevant, gets validated too. It's easy to implement schema that looks correct in the code but throws errors when actually tested, which means it does nothing useful at all.

None of this takes long if you build it into your process. It takes considerably longer to fix three weeks after launch, once search engines have already crawled and indexed a flawed version of the site.

Thing #3: I Test Every Important Form

This is the check that taught me the most painful lesson, and it's the one I'm now closest to paranoid about. Contact forms, lead forms, inquiry forms, newsletter signups - every single one gets tested manually before launch, using real submissions, not just a glance at the code to confirm it looks like it should work.

The thing about broken forms is that they fail silently. There's no error message most of the time, at least not one the business owner sees. The form just submits, the visitor assumes it worked, and the business simply never receives the inquiry. Nobody gets an error notification. Nobody knows anything went wrong. The business just quietly stops getting leads from that channel, and unless someone is comparing form submission counts against expected volume, it can go unnoticed for a long time.

I've seen this happen because of a typo in an email notification address. I've seen it happen because a third-party form plugin had an expired API connection that nobody noticed during testing because the developer's test environment used different credentials than production. I've seen it happen because a CAPTCHA was misconfigured and silently blocking every legitimate submission along with the spam it was supposed to stop.

My process now is simple. I submit every form myself, on the live production site, after deployment, using a real email address I check. I confirm the submission arrives where it's supposed to. I confirm any auto-response triggers correctly. I do this on desktop and on mobile separately, because form behavior can differ between the two more often than people expect. It takes ten minutes. It has saved more than one client from weeks of invisible lead loss.

Thing #4: I Audit Website Performance

Performance affects two audiences that matter enormously: actual human visitors, and search engines that increasingly factor speed into ranking decisions.

Core Web Vitals get checked specifically, not just a general sense that "the site feels fast." Largest Contentful Paint, Cumulative Layout Shift, and the other metrics Google tracks all get a look using real testing tools rather than guesswork.

Image optimization is one of the most common things I find overlooked. Developers build a site locally, drop in placeholder or client-provided images, and never circle back to compress them properly before launch. A homepage hero image that's six or eight megabytes will tank load time on mobile regardless of how clean the underlying code is.

CSS and JavaScript bundles get checked for anything unnecessarily large or unused. It's common for projects to accumulate libraries or plugins during development that never get removed even after the feature using them gets cut or changed.

Mobile performance gets tested specifically, on an actual throttled connection - not just on a fast office wifi network where everything loads instantly regardless of how heavy the page actually is. A site that feels snappy on a developer's machine can feel sluggish and frustrating on a real visitor's phone on a real mobile connection, and that gap is invisible unless you deliberately go looking for it.

Thing #5: I Double-Check Analytics and Tracking

This is the check that's easiest to forget because it doesn't affect how the site looks or functions for visitors. It just determines whether anyone will actually know what's happening on the site after launch.

I verify Google Analytics is firing correctly, on every page, not just the homepage where it's easiest to spot during a quick check. I verify Google Tag Manager containers are publishing the live version, not a draft version that looks fine in preview mode but never actually goes live.

Conversion tracking and form submission tracking get tested specifically, confirming that a real form submission actually fires the event it's supposed to. I've seen tracking set up correctly in theory, using the right event names and triggers, that simply never fired because of a small configuration mismatch that only showed up under real-world testing.

Search Console gets verified and the new sitemap gets submitted as part of the launch process, not as an afterthought days or weeks later.

Missing analytics doesn't break anything visibly. It just means that whatever happens in the first days or weeks after launch - often the most important period for catching problems early - goes completely undocumented. By the time someone notices analytics were never tracking properly, that data is gone permanently. There's no way to retroactively recover it.

Common Deployment Mistakes I've Seen

Beyond the five core checks, a few specific mistakes show up often enough that they're worth calling out directly:

• Missing redirects after a URL structure change - covered above, but it bears repeating because of how often it happens and how avoidable it is.
• Broken internal links that pointed correctly on staging but break in production because of an environment-specific path issue. These are easy to miss because they often only affect a handful of pages, not the whole site, so a quick spot check won't always catch them.
• Incorrect canonical tags, especially in multi-environment setups where staging, development, and production all exist simultaneously and something gets crossed.
• Tracking issues, where analytics appears to be installed but isn't actually capturing the events that matter for the business - like leads or purchases specifically.
• Mobile testing failures, where a site gets thoroughly tested on desktop and only briefly glanced at on mobile, missing layout issues, touch target problems, or form usability issues that only show up on a small screen.

I've worked through deployment audits with teams like Ultramodern Technologies Pvt Ltd where catching these issues before launch, rather than after, made a measurable difference in how smoothly the first weeks of a new site went.

Most of these problems aren't hard to fix. They're just easy to miss if nobody is deliberately looking for them at the right moment. Having an actual website deployment checklist - something written down rather than held loosely in your head - is honestly the simplest fix for most of this. It turns "I think I checked everything" into something you can actually verify, point by point, every single time.

Wrapping Up

Deployment isn't the finish line. I used to think of it that way, and it cost me a few uncomfortable client conversations before I stopped.

The five checks I run now - redirects and URLs, technical SEO basics, form functionality, performance, and analytics tracking - catch the overwhelming majority of issues that otherwise surface only after a client calls asking why their leads dried up, or why their rankings dropped, or why a form has apparently never worked.

In a launch review I worked through with Ultramodern Technologies Pvt Ltd., we found three of these issues on a single site within the first hour of checking, none of which would have been obvious without deliberately looking for them. That's fairly typical, honestly. It's rarely one big thing. It's a handful of small things, each easy to overlook individually.

If you don't already have a personal deployment checklist, build one now - based on whatever has actually gone wrong on your own past projects. Not a generic list copied from somewhere else. Yours, built from your own mistakes, because those are the ones you're most likely to repeat if you don't write them down.