Pre-Launch Checklist for a Tampa Website Redesign

Redirect map verified

Every URL on the old site has a 301 destination on the new site. The map is built as a spreadsheet during the content migration phase and finalized here. Each redirect is tested on staging — we run the old URL through a redirect plugin pointed at staging URLs and confirm the destination loads correctly. The 301 redirect strategy page covers the methodology.

Common gotchas at this stage:

• Trailing-slash vs no-trailing-slash mismatches
• URLs with query strings (?ref=email) that don’t match the redirect rules
• Old URLs in subfolders that don’t have direct equivalents
• Old image and PDF URLs that get linked from external sites

Every “/old-url” should produce a single 301 hop to “/new-url”. No chains. No 404s. No 302s where we meant 301s.

Sitemap.xml ready

A fresh XML sitemap, generated by the SEO plugin (Yoast or Rank Math), covers every page of the new site. We open the sitemap in a browser and spot-check — every key page is listed, no staging URLs are leaking in, the lastmod dates are current.

Robots.txt switched

Staging mode robots.txt: User-agent: * / Disallow: / — blocks all crawling.

Launch mode robots.txt: User-agent: * / Allow: / plus a Sitemap: directive pointing to the new sitemap URL.

The robots.txt switch is one of the most-skipped steps in botched launches. A new site launched with the staging robots.txt still in place will get deindexed by Google within a few days. We have a literal note on the launch checklist to verify this within 30 minutes of going live.

Meta robots cleaned up

Same idea at the page level — noindex, nofollow meta tags that were on staging pages need to come off. We do a final crawl of staging with Screaming Frog or similar, filter for any noindex tags, and confirm none of them are on pages that should be indexed.

Analytics verified

Google Analytics 4 is installed on every page. We use the Tag Assistant or GA’s real-time view to confirm pageviews are firing. The tracking ID is the production property, not a test or staging property. Conversion events (form submissions, phone clicks, key page views) fire correctly.

Google Tag Manager, if used, is configured with production triggers, not staging triggers.

Conversion tracking for any paid media (Google Ads, Meta Ads) is verified. If the redesign is breaking and rebuilding conversion paths, the conversion tags need to reflect the new paths.

Call tracking (CallRail or similar) is wired correctly. The dynamic number insertion is firing on the right pages.

Search Console set up

The new site is verified in Google Search Console — usually via a DNS TXT record or a verified HTML tag in the head. We verify both the http and https properties, and both the www and non-www properties, even though we’ll be canonicalizing to one.

The new sitemap is submitted via GSC’s Sitemaps tab. After launch, we’ll request indexing for the homepage and a few priority pages.

The old GSC property stays active — we’ll use it to monitor the redirect performance for 30-90 days.

Schema markup validated

Structured data is one of the higher-value SEO upgrades a redesign delivers. We validate every schema type using Google’s Rich Results Test:

• LocalBusiness schema for service businesses
• Organization schema for B2B and SaaS
• Product schema for any commerce pages
• Service schema for service pillar pages
• FAQ schema where FAQ blocks exist
• BreadcrumbList schema for navigation breadcrumbs
• Review schema where reviews are displayed

Each schema block needs to validate without errors and warnings before launch. Warnings about optional fields are okay. Errors about required fields are not.

Forms tested end-to-end

Every form on the new site gets submitted with a test entry, and we confirm:

• The submission arrives in the destination (CRM, inbox, Slack)
• The notification email reaches the client and the team
• The user-facing thank-you page or message displays correctly
• The form does not also submit to a stale or test endpoint
• The conversion event fires in analytics

For a typical Tampa SMB site, this is the contact form, the quote-request form, the audit form, the email signup form, and any service-specific forms. Every one gets a live submission.

Mobile and cross-browser final check

A final round of real-device testing in the mobile optimization matrix — real iPhone, real Android, real network, real Tampa parking lot. Plus Chrome, Safari, Firefox, and Edge on desktop. Plus the latest tablet versions if the audience uses them.

Performance final check

Core Web Vitals on the homepage and top 5 template pages — LCP under 2.5s, INP under 200ms, CLS under 0.1, PageSpeed Insights mobile score above 85. The performance improvements page covers the targets.

Backups in place

The current live site gets a full backup the day before launch. Database plus files. The backup is downloaded and stored somewhere we can restore from if launch goes badly. This is the rollback insurance policy.

DNS plan confirmed

If launch involves a DNS change (separate-staging launch, or a hosting move), the DNS plan is documented:

• Current DNS records
• Target DNS records
• TTL set low (300 seconds) 24-48 hours before launch so changes propagate fast
• Who has access to make the change
• Estimated propagation time

The first 24 hours are the highest-attention window. We’re watching for:

404 spikes. Google Search Console’s coverage report and the server logs will show any URL that’s getting requested but not returning a valid page. Any 404 that shows up gets a 301 added to the map.

Server errors. 500-series errors mean the new site has a problem. Server logs and uptime monitoring (Uptime Robot, Better Stack, or the host’s built-in monitoring) catch these.

Form failures. Customers actually submitting forms. The submissions should be arriving in the CRM. If they’re not, we need to know within hours, not days.

Analytics integrity. Real-time traffic should be appearing in GA4 within minutes of launch. If the numbers look suspicious (way too low, way too high, wrong sources), something is wrong with the tracking.

Search Console crawl status. Google starts crawling the new site within hours. The Coverage report shows what’s getting indexed and what’s not.

Lower-frequency monitoring, but still active.

Rankings. The preserve SEO during a redesign strategy means we expect some volatility in the first 2-6 weeks as Google re-evaluates the site. We track rankings weekly using whatever tool the client has (Ahrefs, SEMrush, or Search Console).

Traffic. Organic traffic should be flat-to-slightly-down in the first 2-4 weeks, then recover. A drop greater than 20% week-over-week sustained past week 3 means something is wrong — usually a redirect issue or a content drop we didn’t expect.

Conversions. Form submissions and phone calls should be at parity with the pre-launch baseline within the first 2 weeks. If conversions drop and stay dropped, something is broken in the conversion path — a form, a phone number, a CTA placement.

Coverage. GSC coverage report — pages indexed, pages excluded, pages with errors. We aim for 95%+ of intended pages indexed within 30 days.

Errors. Server logs, console errors, broken images, broken links. We run a Screaming Frog crawl at 7 days, 14 days, and 30 days post-launch.

Not the talent of the team. The checklist. A team that runs the checklist faithfully will launch cleanly more often than a more talented team that improvises. The checklist is the discipline that makes the project predictable.

The Tampa businesses we see lose ranking on launch did not lose ranking because their agency was incompetent. They lost ranking because someone skipped the redirect verification step, or left the staging robots.txt in place, or didn’t notice that the LocalBusiness schema didn’t include the address. Small misses, big consequences.

If you’re considering a redesign and want to know how the launch process is run end-to-end, the staging environment and common pitfalls pages cover the pre- and post-launch context. The redesign service page has pricing and timelines.