You open the website again. The headline still needs work, someone wants a different photo, and the contact form might not be working. Everything feels unfinished, so everything stays unfinished.
Start by separating the decisions. A broken way to contact you needs a different response from a photo you might replace later.
This guide will help you make a launch list someone can act on. You need the current website or preview, a phone, and a place to write down what you find.
1. Write the one thing a visitor needs to do
Finish this sentence:
“Someone visiting this website should be able to ______.”
Choose the main action for this release: understand a service and contact you, request an appointment, read an event's details, or buy a specific item. If your website serves several audiences, choose the most important path first and check the others afterward.
For a fictional repair business, the sentence might be: “A homeowner should be able to see what we repair, confirm that we serve their area, and request a quote.”
Keep that sentence beside you. It gives you a way to judge each unfinished item.
2. Make three lists
Label them “Blocks launch,” “Needed for this release,” and “Later.”
Put an item in “Blocks launch” when it prevents the main action, presents incorrect essential information, exposes private material, or creates a serious barrier. Examples include a broken inquiry form, an incorrect phone number, or a checkout that cannot complete its intended test.
“Needed for this release” is the work you have agreed must ship, even if the rest of the site functions. It could be a missing service explanation or an approved photo that has not been added.
“Later” holds improvements that can wait without misleading visitors or breaking their task. A second case study or an extra animation might belong here.
For the fictional repair site:
- Blocks launch: the quote button goes to an old address.
- Needed for this release: the service-area paragraph is missing.
- Later: add an animated before-and-after gallery.
If you cannot classify something, write the consequence of leaving it unchanged. That is more useful than another priority label.
3. Walk through the customer path
Open the site on your phone, beginning at the page a visitor would land on. Read the offer, find the next step, and follow it.
Check every link on that path. Confirm that phone and email links use the right details. If you own the form and are authorized to test it, send one clearly labeled test using your own details. Verify both what the visitor sees and where the submission arrives. A success message alone does not confirm delivery.
Avoid test purchases on a live store unless you understand the charges, fulfillment and refunds involved. Ask the person responsible for the store to use its supported test process.
Record each issue as: page, action taken, expected result, actual result. Add a screenshot if it helps, without exposing private information.
4. Check whether the page is usable
On a computer, try the main path using Tab, Shift+Tab and Enter. Can you see where keyboard focus is? Can you reach the navigation and controls? Zoom in and check whether essential content remains readable and usable. Make sure form fields have clear labels.
These are starting checks, not an accessibility certification. W3C's Easy Checks explains these tests and their limits.
5. Name the decision and the owner
For every launch blocker, write who will resolve it and how you will know it is fixed. “Fix form” becomes “Alex will send one labeled test, confirm it arrives in the agreed inbox, and record the result.”
Before launch, ask the person managing the website to confirm what is changing, what is staying unchanged, and how they would recover from a failed change. Do not change domain or business-email settings just to get past an unfamiliar warning.
Have that person check the intended search visibility too. Google's noindex guidance explains a setting that can keep a page out of Google. It does not make a page private, and changing it does not guarantee indexing or rankings. Private previews need appropriate access protection.
Your next move
Use the Website Path section of the Finish This Project checklist. Pick the first unresolved blocker and give it an owner and a test. Keep the later list, but stop letting it hide the release decision.
Want help deciding what to tackle? Open Finish Finder, or explore Finish the Stuff with your short list in hand.