Pre-launch audit: the checklist before your site goes live

It is 6:20 p.m. on a Thursday. The marketing team is about to publish the dealer application page they have been building for three weeks: hero image in place, application form submitting, service list correct. Someone clicks publish, the page goes live, everyone goes home. At 9:10 the next morning the regional manager calls. Two sections of the English version are still in the source language, the browser tab reads "New page" instead of a title, and none of the applications submitted overnight reached the CRM — the form sends, the thank-you message shows, the record lands nowhere. All three failures were catchable in the fifteen minutes before launch.

This article walks through that pre-launch audit in the order you actually run it: what an automated check catches, how to separate blocking findings from warnings, how to do the content read-through, how to prove the form mapping works, domain and search-engine readiness, who approves and when you publish, the first 48 hours after launch, and the rollback plan for when something goes wrong. The most common questions are answered at the end.

What does an automated pre-launch check actually catch?

The errors a human catches and the errors a machine catches are not the same set. Your eye catches tone and whether a sentence earns the click. The machine catches the fields you forgot existed: an empty page title, a description never filled in, a section started in one language and never finished in another. In Rocketly, the Pre-launch Audit runs that scan before a version can be prepared and lists what it finds; findings marked as blocking must be cleared before the version exists at all. A half-finished page cannot go live by accident, because the exit is closed rather than merely discouraged.

On launch day, anything deferred with "we'll fix it after" tends never to get fixed. An automated gate moves that decision out of one person's attention span and into the system. The same logic applies on the sales side: a pipeline hygiene checklist exists for exactly this reason — recurring checks belong in a routine, not in someone's memory.

How do you separate a blocking finding from a warning?

Not every finding should stop a launch. If everything blocks, the team stops taking the audit seriously and starts routing around it. A workable threshold rests on one question: does this break what the visitor sees, or merely leave something that can be improved later? The first blocks. The second is a warning, closed in the week after launch.

Finding	Concrete example	Blocks launch?	What you do
Empty page title	Tab shows "New page"	Yes	Write it before publishing
Unfinished text in one language	Two sections untranslated	Yes	Finish it, or disable that language
Form mapping never tested	No dry run on record	Yes	Run a test submission
Domain not verified	DNS TXT record not added	Yes	Add the record, wait for verification
Empty page description	No snippet in search results	No, warning	Write it within the first week
Missing image alt text	Hero image has no alt	No, warning	Close it in the next version

Treat that table as a starting point and write your own thresholds. An empty pricing block might block a campaign page and be irrelevant on a corporate profile page. What matters is that the threshold is written down and is not being argued about on the morning of the launch.

The read-through: is the content genuinely finished?

An automated check sees an empty field, not a bad sentence. So after the scan, someone reads the page end to end the way a visitor would, in three passes. First, headings only: does the page make sense from headings alone? Second, click every link — does each go where it claims? Third, look at it on a phone, because that is where most visitors will meet it first.

The thing most often skipped here is repeating content: branch lists, team cards, service tiles. Typed into the page by hand, one will go stale and nobody will notice. Defined as a CMS collection, the list fills from a single source and updating it does not mean redesigning the page. Make the read-through a named step in your schedule; when you build a content calendar and publishing plan, put the audit on the calendar as its own task rather than squeezing it into the last half hour before launch.

If the page carries pricing or a plan comparison, that gets its own line in the pass: where do the figures come from, and is that source current? When different segments get different terms, check that the public table does not contradict how your customer-specific price lists actually work; a contradiction that surfaces in a sales call costs far more than a stale table nobody clicked.

Do the forms really land where you think they do?

This is the quietest failure after launch. The form appears to work, the visitor sees the confirmation, and the record reaches nothing. Nobody complains — the visitor believes they are done, and you read the missing enquiries as weak demand.

In Rocketly, submissions from a published page do not write straight into the CRM. Under Forms Connect to the CRM, a submission first lands in a submission inbox belonging to that site, then maps into a workflow, and the record is created there. That intermediate step exists precisely so it can be audited: before publishing, you run a dry submission and watch which field lands where. If the phone number arrives empty, the problem is the mapping rather than the form — and you learn it in the test, not from a customer.

The dry-run habit applies to anything on the page that behaves on its own, not just forms. If you have attached a chat assistant or an automatic reply, exercise it in a controlled setting first; the scenario list you use for testing AI agents before launch works here too — ask the three most common questions, then send one deliberately nonsensical message and watch where the answer goes.

Four things to verify: are the required fields genuinely required, what does the visitor see after submitting, which list and which owner does the record land under, and does a second submission create a duplicate. If the form exists to collect subscribers, that last point decides everything downstream — when you are building an email list, duplicates inflate the list and wreck your engagement rate on the very first send.

Are the domain, redirects and links ready?

The page may already work on its default public address, but if the campaign is announced on your own domain, launch day is the worst time to be waiting on DNS. Under Custom Domain and Verification, the system issues a single-use DNS TXT record, you add it to your domain settings, and verification proves ownership; the routing record is then checked separately. Finish this a day ahead — DNS propagation does not respect your schedule.

Three related decisions belong in the same step. First, the subdomain: does the campaign live under the main domain or on its own? Second, if this page replaces an older one, where the old address should point. Third, the exact link going into the ad or the email, tracking parameters included, opened once and confirmed. A link broken by one wrong character is the most expensive launch bug there is, because it reveals itself only while traffic is arriving.

Will search engines read the page correctly on day one?

When public pages are rendered on the server, the title, description, canonical address, language alternates and structured data arrive inside the HTML, readable before the browser runs any JavaScript, and every published site gets its own sitemap.xml and robots.txt. What you check is not whether that plumbing exists but the values you supplied: does every page have its own title and description, are two pages sharing one title, and is a thank-you page that should be excluded still open to indexing?

On a bilingual site, the most common mistake is failing to declare each language version as the alternate of the other, leaving the two to compete. The audit lists unfinished text as a finding, which gives you a cleaner option than shipping it half-done: turn that language off until it is ready. A half-translated version is worse than a missing one, because visitors will find it.

Who approves, and who presses publish?

If everyone who can build can also publish, the audit becomes a suggestion. With the Review and Approval Policy you define which roles must approve a release and assign people to them; the version does not go live until the approvals are complete, and while an open review record exists, publishing is held. You can also lock critical sections so only reviewers may edit them — for legal copy or campaign terms, that ends the argument before it starts.

Whoever approves needs to see the page, but they do not need an account to do it: a time-limited, revocable preview link lets you show the page and collect comments without publishing anything. And when someone later asks who changed what, you read the answer from a record rather than from memory; the same reasoning behind a CRM audit log applies here, since scope and permission changes are written down and the publishing decision leaves a trail.

How do you choose the publish time?

The publish time is a risk decision, not a preference. A page shipped at 5:30 on a Friday leaves its bugs live all weekend. The good hour is the one where the team is at their desks and traffic has not arrived yet: Tuesday or Wednesday morning, before the first meeting. If the campaign depends on an announcement, the page must be live first, never the other way round.

With Scheduled Publishing you give a prepared version a time; the page stays hidden until then, and a background job takes it live at the appointed hour. If a new review has been opened in the meantime, or an approval has been withdrawn, the schedule is deliberately cancelled and the call comes back to you — scheduling does not override the approval policy. When the announcement, the ads and the sales team's readiness all hang on one hour, put them on a single countdown; teams running a pre-launch sales campaign commonly publish the page quietly a day early and keep access limited to the link until the announcement lands.

What do you watch in the first 48 hours?

Publishing is where measurement starts. The first two days do not tell you whether the page works; they tell you where it stalls. Daily Site Metrics accumulate page views, form starts, submissions, abandonment, call-button clicks and scroll depth, broken out by device and traffic source. A high form-start count with low submissions is not a traffic problem but a form problem, and it usually means you asked for too many fields.

Three ratios matter in that window: how many arrivals start the form, how many starters finish it, and how many of the resulting records are genuinely workable. The third one belongs to sales and is the one nobody measures. If you plan a second touch for the people who left mid-form, build the retargeting setup in the same week as the launch, not a month later.

Then make that reading a recurring job instead of a one-off. Ten minutes on published-page performance inside your monthly sales close routine is what stops a page that stopped working from sitting there quietly for a quarter.

What is your rollback plan if something breaks?

A good launch plan does not assume nothing will break; it knows how many minutes a rollback takes. What gets published is not your draft but a frozen copy of that moment: it takes a version number and never changes again. You keep working in the draft, and visitors keep seeing the previous version until you press publish. That separation is what makes going back simple — the place you are returning to is still intact.

With One-click Rollback you return to any previously published version in a single action; the snapshot is preserved, so nothing is rebuilt. A pending scheduled publish is cleared during the rollback, so two decisions cannot overwrite each other. Write three things into the plan: who decides to roll back, at what threshold, and who tells everyone afterwards.

If the page is fed by data that arrived from another system, the plan does not end at the page. Launching on a freshly moved customer base means the gaps created during a CRM data migration will also send incoming records to the wrong place; run both checks in the same week.

If you want your own audit list enforced, with approvals and versions behind every release, you can create a free Rocketly account and run your first page through the pre-launch check.

FAQ

Does every finding block the launch?

No. Blocking findings must be cleared before a version can be prepared; warnings are listed but do not hold the release. An empty page title or text left unfinished in one language sits on the blocking side, while improvements such as alt text can be closed after you go live.

Can I show the page to someone outside the team before publishing?

Yes. You generate a time-limited preview link that you can revoke whenever you like, and the recipient does not need an account. Revoking it closes access, and the page itself was never published.

I published the wrong version — how long does it take to undo?

One action. Because every release is a frozen snapshot of that moment, you select the earlier version and roll back to it without rebuilding anything. If a scheduled publish is pending, the rollback clears it too.

Do I need to rewrite the audit list for every launch?

No — the more stable it is, the more it is worth. The fields the automated check looks at stay the same across versions, and the manual items you add are written once and folded into your publishing plan. What changes each time is not the list but the answers.