To test a website before launch, go through six rounds in this order: first, customer journeys end to end (sign-up, search, purchase or booking); second, forms and error messages with wrong input; third, layout on a phone; fourth, content, language and right-to-left direction; fifth, payment in test mode plus emails and notifications; sixth, search visibility, speed and legal pages. Test on a staging copy with a test account, write down every bug with steps to reproduce it, and do not launch with a critical bug in a core journey.
- how to test a website before launch
- website pre-launch checklist
- website testing checklist
- how do I know my website is ready to launch
- what to check before publishing a website
- how to QA a website without a tester
What is the complete pre-launch pass, in short?
Testing a website before launch is not browsing it and saying 'looks fine'. It is playing six people in turn: a customer in a hurry, one who mistypes, one on a small phone, a careful reader, one who pays, and a search engine. Each sees what the others miss.
Illustration- Where to test
- A staging copy that matches live
- On what
- A real phone and a computer
- Which account
- A new test account, not the admin's
- Payments
- The payment gateway's test mode
- Notes
- A table: bug, steps, severity
For a shorter printable version, use the website testing checklist. Here we explain why each item is there. Always start with a new account: as an admin you see things a customer does not, and the reverse.
Round 1: do the customer journeys work end to end?
Write down the three journeys your business earns from, then walk each one in full without stopping, like a customer who does not know the site. Do not test pages in isolation; failures live in the moves between them.
Round 2: what happens when the visitor gets it wrong?
The happy path works on most sites. A solid site differs from a fragile one when a visitor types something you did not expect. In every form, try:
| What you enter | What should happen | The common failure |
|---|---|---|
| Required fields left empty | A message beside each missing field | Nothing happens, or one vague message |
| Email with no @, a mobile number one digit short | Refusal that shows the right format | The wrong data is accepted |
| A mobile number in different formats: leading zero, country code | All common formats accepted | A valid format is refused |
| Arabic-Indic digits in a number field | Accepted or converted | 'Invalid number' |
| Very long text, symbols, emoji | Sensible acceptance or a clear limit | An error page |
| The submit button pressed twice quickly | One order only | Two identical orders |
| A past date, a quantity of zero or below | Refusal with a message | A booking for yesterday |
| The same slot booked from two accounts | The second is refused | A double-booked slot |
Round 3: does the site look right on a phone?
In our region most visits come from phones, yet sites get reviewed on a wide screen. Start with the phone: narrow the browser window to phone width first, then open the site on a real phone.
Round 4: are the content and language right?
Read each page as a careful customer would, not as its author. An Arabic interface also has faults of its own that never show in English:
For detail, read common Arabic interface mistakes and a bilingual Arabic and English website.
Round 5: do payment, emails and notifications work?
This round touches money, so do not shorten it. Every payment gateway offers a test mode with test cards; use it.
Round 6: is the site findable, fast and legally complete?
Two things sit outside this pass: load testing with thousands of simultaneous visitors, and a security audit. For a big campaign or sensitive data, bring in a specialist and start from the security checklist. For legal requirements, check the official source in your country; this is a general reminder, not legal advice.
How do you finish this pass faster with a QA agent?
The first three rounds and most of the fourth are repetitive work, which suits a QA agent. Fanann's QA Engineer takes your site address, whether built in Fanann or elsewhere, explores it and proposes test cases you review and approve, then runs them in a real browser, reports with screenshots and a severity per bug, and re-tests after the fix. It is part of the paid plans.
- Full customer journeys
- Forms, wrong data and double booking
- Sign-in and permissions
- Cut-offs and sideways scroll at phone size
- Repeating all of it after each fix
- The real phone in your hand
- Real payment and wallets
- Messages reaching your phone and inbox
- Wording and design taste
- Load and security, with a specialist
I am launching this site in three days. Do a full review at phone size first, then desktop. Try everything a customer does from the home page to the order confirmation page, without completing a real payment. In every form try empty fields, a wrong email, an incomplete mobile number and pressing submit twice. Confirm there is no error message in the wrong language, no sideways scroll and no broken link. You are on the staging copy and may create test data, but do not delete anything. Give me a verdict: ready or not, with bugs ordered by severity.
Try it in FanannWhat do you check on launch day and the week after?
- 3 days beforeThe complete pass
All six rounds on staging. Write down and classify every bug.
- 1 day beforeRe-check after fixes
Repeat all core journeys, not only what was fixed; a fix can break something else.
- Launch hourSmoke test on live
Open the site from your phone on mobile data. Sign up, order, pay a small amount, then refund it.
- First 48 hoursWatch closely
Follow incoming orders and messages. Every customer complaint is a bug the pass missed; add it to the list.
- First weekMake it a habit
Save the cases and rerun them after every change, or schedule them to run by themselves.
To keep going after launch, read how to find bugs before your customers do and running an AI QA agent every night.
Key takeaways
- Order the pass by money: the journey where the customer pays comes first, the footer last.
- Make mistakes on purpose: most failures appear when a visitor types something you did not expect.
- Test at phone size before desktop, then on a real phone in your hand.
- Test payment in test mode first, then with a small real amount you refund.
- A QA agent carries the repeated rounds; taste, real devices and real payment stay with you.
Frequently asked questions
How long does it take to test a website before launch?
What should I test first if I am short on time?
Should I test on the live site or a staging copy?
Can I test my website without technical skills?
Is a QA agent enough on its own before launch?
How do I write up a bug so the developer fixes it fast?
Ask your AI assistant about this
Copy this prompt into the AI assistant you use, then add the details of your own case.
I am reading this guide: “How to test a website before launch: the complete pass in six rounds” https://fanann.com/en/blog/how-to-test-a-website-before-launch/ My question: how to test a website before launch Use that page as a source and explain the answer step by step for my situation, tell me what to check before I start, and cite the page link.