The Website Launch Checklist I Use for Belizean Businesses

Most websites in Belize do not fail at launch. They fail quietly in the two weeks after launch, when the old site is still the one Google shows, the contact form is dropping enquiries into nothing, and nobody can log in to see the traffic numbers. A website launch checklist exists to stop exactly that. Below is the one I work through for every site I put live from my own servers in Belmopan, written so a non-programmer can read it and ask the right questions of whoever is building their site.

I have been running Mark Logic Development since 2008, and I build and operate the platforms behind real-estate agency sites, hotel booking sites, a school system and a vehicle rental business. Launch day is the part clients remember, so it is the part I have made the most boring and repeatable.

What does "launching" a website actually involve?

Launching is not pressing publish. It is moving an audience, a search engine index and a set of business processes from one address to another without losing anything along the way.

There are four things that must survive the move: your search rankings, your enquiries, your measurement, and your ability to get back into everything later without calling the developer. Everything on the list below serves one of those four.

Redirects: the part that protects your rankings

A 301 redirect is a permanent instruction that tells a browser and a search engine "this page moved here". Before a new site goes live, I build a redirect map, which is a line-by-line list of every address on the old site and the matching address on the new one.

Not a catch-all that dumps everyone on the home page. That is the most common shortcut and it is the one that costs the most. If your old /rooms/sea-view-suite page had years of accumulated standing in Google, a redirect to the home page throws most of that away.

Alongside the redirect map I publish two small files:

• A sitemap, an XML file listing every page you want indexed, so Google does not have to guess.
• A robots.txt file, which tells crawlers what to look at and what to leave alone. On a staging site it blocks everything. On launch day it must be changed. A forgotten staging robots.txt is a silent way to disappear.

I wrote about this in more depth in my notes on moving a WordPress site to Next.js without losing rankings, which covers how to build the map from the old site's own data rather than from memory.

What happens if you skip the redirects?

For a few weeks you have two sites competing in Google: the old one, still indexed, and the new one, unknown. Customers click the old links from directories, Facebook posts and WhatsApp messages. If the old host is switched off, they get an error page. If it is still running, you are paying for two sites and splitting your traffic between them.

Search Console and Google Business Profile

Google Search Console is a free tool that shows which searches bring people to your site and tells you when Google cannot read a page. On launch I verify the new domain, submit the sitemap, and check the coverage report over the following days to see that the new addresses are being picked up and the old ones are being retired.

Google Business Profile is the panel that appears on the right of a search for your business name, and the pin on Google Maps. For a Belizean business this is often worth more than the website itself, because a visitor in San Pedro or a customer in Belmopan is searching on a phone and tapping the call button. I make sure the profile is claimed by you, linked to the site, and consistent with the address and opening hours published on the site.

Who should own the Google accounts?

You. Always you.

This is the third of the three misses I see most often, after the old site still being indexed and forms failing silently. A previous developer sets up Analytics and Search Console under their own personal Gmail, the relationship ends, and the business loses years of history and the ability to prove ownership. I set these up under an account you control and add myself as a user. If we stop working together, you remove me and keep everything.

Will my contact form actually reach me?

Only if someone tested it after launch, and only if the sending address is authenticated.

I do two things here. First, the form delivers to a real mailbox that a person checks, and it also writes a logged copy into an admin inbox inside the site. If mail delivery ever breaks, the enquiry is still recorded and visible, so you are not relying on a single channel.

Second, I configure SPF and DKIM for the sending address. These are DNS records that let receiving mail servers confirm your messages are genuinely from your domain. Without them, form notifications and booking confirmations land in spam, and you conclude the website is not generating enquiries when in fact it is.

Analytics that record from day one

I install Google Analytics 4, and I check it against the site's content security policy, a browser rule that lists which outside scripts are allowed to run. A strict policy with no exception for Analytics means the tag loads nothing and your reports stay empty. It is a five-minute fix that is easy to miss for a month.

I also add structured data, which is machine-readable description embedded in the page: Organisation and LocalBusiness on every site, plus Product or Vehicle for rental and sales listings and Article for posts. That is what lets Google show your opening hours, location and stock details directly in results. The Cayo Auto Rentals site is a straightforward example of vehicle markup doing that job. Open Graph images are set too, so a link shared to Facebook or WhatsApp shows a proper picture and title rather than a blank box.

The quiet infrastructure

None of this is visible to a visitor, which is why it gets skipped.

• TLS certificate with automatic renewal, so the padlock in the browser never lapses and nobody sees a security warning.
• Uptime monitoring, so I find out the site is down before you do.
• Backups, taken and tested, not merely configured.
• A mobile audit at 360 pixels wide, the narrow end of the phones people in Belize actually carry. If the booking button is off-screen at that width, the site does not work.

Done versus commonly missed

| Item | What I deliver | What usually gets missed | | --- | --- | --- | | Redirects | Page-by-page 301 map | Catch-all to home page, or none | | Indexing | Sitemap submitted, robots corrected | Staging robots.txt left blocking | | Forms | Real mailbox plus logged admin copy | No test after launch | | Email | SPF and DKIM configured | Notifications sent to spam | | Analytics | GA4 verified against the content policy | Tag blocked, empty reports | | Access | Accounts owned by the client | Owned by the developer | | Handover | Written document, source code, in-app help | A verbal explanation |

The handover document matters more than it sounds. It lists where everything lives, how to log in, who to contact for the domain, and what to do if something breaks on a Sunday. You keep the source code and the documentation either way.

Where to start

If you are planning a new site, or you suspect an existing one launched badly, you can check most of this yourself before speaking to anyone.

1. Search Google for your business name and see which site comes up. If it is the old one, the redirects are wrong.
2. Fill in your own contact form from a phone, using an address you can check. Wait ten minutes.
3. Log in to Google Analytics and Search Console. If you cannot, find out whose account they are under.
4. Open the site on the narrowest phone in the office and try to complete the main action, whether that is calling, booking or enquiring.
5. Ask whoever built it for the redirect map and the handover document in writing.

If any of those turn up something you do not like, or you would rather someone worked through the whole list with you before you commit, you are welcome to get in touch and describe what you have.