PRACTICAL GUIDE
What should be checked before a website launch?
This guide puts the manual checks around an automated report into a useful order. The goal is not a higher tool score; it is a production site that visitors can understand, that behaves consistently, and that can be maintained without guesswork.
1. Review the real production address
Run the review against the domain visitors will use, not a temporary preview. A maintenance screen, blank template, login-only shell, or unfinished menu does not represent a complete public service.
The home page should explain the service in complete sentences. About, methodology, contact, privacy, cookie, and terms pages should be easy to reach from the main navigation or footer.
2. Give the content a reason to exist
For a technical tool, value is more than a working input field. A visitor should understand what the result means, what was checked, what could not be observed, and what to verify next. Product documentation and interpretation examples should match the real behavior of the tool.
Repeating one paragraph for different keyword variations, publishing hundreds of near-identical pages, or treating automated output as the whole publication is not a useful content model. A smaller set of carefully reviewed pages is more useful.
3. Keep the canonical host and HTTPS chain simple
Choose either the bare domain or www as the canonical host. The other host should permanently redirect to it, while internal links, the sitemap, and canonical tags use the same preferred host.
Confirm that HTTP reaches HTTPS, the certificate covers the correct hostname, and the origin connection is protected when a CDN sits in front of the site. Avoid redirect chains that add no user value.
4. Understand security headers before copying them
Content-Security-Policy should reflect the resources the application actually needs. A copied policy can break analytics, CAPTCHA, advertising, or normal assets; an overly broad policy can remove much of the protection it was meant to add.
Review HSTS, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy together with the browser console. A header can be present and still have the wrong value or scope.
5. Make privacy text match the services that run
Privacy and cookie pages should describe the measurement, CAPTCHA, and advertising services that are actually in use. Listing providers that are not used makes the real data-handling behavior harder to understand.
Consent controls should make acceptance and rejection clear, separate essential storage from optional measurement, and apply the saved choice consistently. Google-certified consent management may also be required for advertising in covered regions.
6. Keep publisher content as the focus of ad pages
On a page that carries advertising, the reason for visiting should be the publisher content. Error pages, exit screens, alert-only screens, and technical states with little or no publisher content are not suitable ad inventory.
Ads should not look like navigation, downloads, scan results, or verification controls. If Auto ads are used, low-value utility and error routes should also be reviewed in AdSense page exclusions.
7. Do not confuse discovery files with content quality
Each indexable page needs a descriptive title, one clear subject, the correct canonical URL, and structured data that matches what visitors can see. The sitemap should list only published canonical pages.
robots.txt, llms.txt, and schema markup can improve discovery, but they do not make a page useful by themselves. The value comes from content that actually answers the visitor’s question.
8. Perform a real-user final check
Test desktop and mobile layouts separately. Use keyboard navigation, check visible focus, submit invalid form values, change consent choices, use the Back button, and refresh important pages.
Open ads.txt, robots.txt, sitemap.xml, and the main editorial pages directly. Resolve first-party CSP, JavaScript, or network errors before requesting another external review.