How to accept a website
from your developer

How to use this guide

A finished website can look convincing while losing enquiries, remaining blocked from search engines or depending on a former contractor’s account. Accept the working website on your own domain, not just a project presentation. Below is a sequence of checks: which tool to open, what to enter, how to interpret the result and what to ask the developer to fix.

Have the specification, approved designs and list of pages and integrations ready. Record the address, date and version being tested. Create a table with columns for “Address / scenario”, “Expected result”, “Actual result”, “Evidence”, “Owner” and “Status”. Use four statuses: checked, defect found, not checked and not applicable. If you cannot access an account, mark it “not checked”, not “all good”.

Tools you will need

Submit ordinary public URLs to public tools. Test pages containing secret sign-in links, personal data or payment tokens within the agreed environment. Button names may vary with interface language and updates; the instructions below provide the main landmarks.

Make sure the website has really been handed over to you

Check the domain using WHOIS and the registrar account

1. Open WHOIS, enter the domain without a page path, for example example.ru, and run the search.
2. Find the registrar and domain expiry date. For .ru domains, the date may appear in the field paid-till; other extensions may use a different name.
3. Sign in to that registrar using the client’s account. Check that the domain is listed, renewal and DNS management are available, and the recovery contact belongs to the responsible employee.
4. Compare the registrant details with the agreed ownership arrangement. Hidden WHOIS details are normal: the public tool does not replace checking the account and documents.

Expected result: The owner, next payment date, renewal process and person able to recover access are clear. The contractor may remain a technical service provider, but the project must not depend on an unknown personal account.

Create a register of the remaining access rights

Do not put passwords in a publicly shared defect log. A reference to secure storage and the responsible person’s name are enough. If the platform’s terms limit access, record which operations the client can perform independently and which require support.

Check redirects, server responses and the certificate

Four domain variants in httpstatus.io

A website is often accessed over HTTP or HTTPS, with or without www. Choose the primary address, for example https://example.ru/. Then open httpstatus.io and paste these four lines into the field, replacing the example with your domain:

http://example.ru/
http://www.example.ru/
https://example.ru/
https://www.example.ru/

Click Check status. Expand the results and examine the sequence of status codes and final address. The primary URL should return 200. When permanently consolidated, alternative addresses usually redirect with 301 or 308 to the primary HTTPS address, which returns 200. Repeat the check for an inner page: its path must be preserved.

Save the report and send the developer the starting URL, the full chain and the expected final address. A temporary 302 is not always an error: clarify its purpose. A mismatch with the requirement, a loop or a lost page is the problem.

Does the 404 page return a real 404?

Append a path you know does not exist to your domain, for example /proverka-priemki-ne-sushchestvuet-8472/. Open it in a browser and check it with the same tool. You should see a clear page with navigation and the status code 404. If the page says “Page not found” but the server returns 200, it falsely reports success. A deliberately removed resource may also legitimately use 410.

Checking HTTPS with SSL Labs

1. Open SSL Server Test. In the field Hostname enter the domain without https:// or a path.
2. If necessary, select Do not show the results on the boards, start the test and wait for completion.
3. Check the certificate expiry date, domain match and certificate-chain trust messages. Send protocol warnings to the server administrator with the report link.

The site should open in a normal browser without invalid-certificate warnings. Also check images, fonts and scripts: HTTPS on the page does not fix resources still linked over HTTP. The SSL Labs grade describes TLS configuration, not the website’s overall security.

Check that search engines are not blocked

Step 1. Open robots.txt

Enter in your browser https://example.com/robots.txt. Find the group for User-agent: * and any separate Googlebot and Yandex rules. This pair of lines blocks all crawling by the relevant bot:

User-agent: *
Disallow: /

On a public website after launch, this is a reason to review the settings. Do not remove every restriction indiscriminately: accounts, baskets and technical URLs may be intentionally blocked. The outcome depends on the combination of groups, rules and the specific URL.

Open Yandex Webmaster → Tools → Robots.txt analysis and enter the website address. Once the file loads, check access for the homepage, a service page, an article and other important URLs. If a required page is blocked, save its URL and the rule responsible. The procedure is explained in the tool’s help page.

Step 2. Look for noindex in the page and headers

Open the page source using your browser’s “View page source” command. Search for name="robots", name="googlebot" and noindex. What matters is an actual meta tag inside <head>, for example:

<meta name="robots" content="noindex, nofollow">

In an article like this one, the word noindex may appear in a teaching example rather than an active restriction. Also inspect the response headers in httpstatus.io: the directive may be sent as X-Robots-Tag: noindex. In WordPress, also check Settings → Reading and the option that asks search engines not to index the site; SEO plugin settings can add restrictions too.

Expected result: pages intended for search have no accidental indexing restriction. Google must be able to access the page to read noindex; blocking crawling in robots.txt does not replace that directive. This distinction is explained in Google’s documentation.

Step 3. Check the XML sitemap

Find the sitemap address in the line Sitemap: in robots.txt or ask the developer. It may be named sitemap.xml, sitemap_index.xml or something else. Open it; if it lists other sitemaps, open the maps for pages, products and articles. Check that URLs use the live domain and primary HTTPS version, not a staging site.

Open URLs from each section. The sitemap should not accidentally include redirects, deleted pages or noindex pages. Compare the entire list with the agreed site inventory: one accessible sitemap does not prove completeness. In Yandex Webmaster, use Tools → Sitemap validator, paste the link and review the errors; an official guide is available.

Step 4. Inspect a page in Google Search Console

1. In Search Console select your website’s verified property.
2. Paste the full URL of an important page into the URL inspection field at the top.
3. Distinguish stored index information from a check of the current page. Click Test Live URL to check the current response.
4. Expand the crawling and indexing details. If crawling is blocked or fetching fails, send the developer the specific reason. Repeat the live test after the fix.

A successful live test indicates technical eligibility for search, not immediate indexing or a high ranking. These modes are distinguished in Google’s help documentation. For Yandex, also use the server response check in Webmaster and its indexing reports.

Find broken links, duplicates and markup errors

How to run a crawl in Screaming Frog

1. Install SEO Spider from the official website. Paste the homepage URL into the field Enter URL to spider and click Start.
2. Wait for the crawl to finish. If it reaches the free version’s 500-URL limit, do not treat the report as complete: a larger project needs a tool without that restriction.
3. Open the tab Response Codes and find 4xx and 5xx responses. Select an affected URL and inspect Inlinks to see which pages link to it.
4. Export the results and send the contractor pairs of “linking page → broken link”.

A link-based crawl does not necessarily find every page: an orphan with no incoming links may go unnoticed. Compare the export with the sitemap, CMS inventory and agreed structure. If scripts generate the site’s content, check the rendering mode. Settings and limitations are covered in the getting-started crawl guide.

What to review in the results

Tab names and purposes are described in the SEO Spider reference guide. An automated flag is a reason to inspect the page. The same title on an intentional duplicate and the same title on ten different service pages call for different decisions.

How to check structured data

Open Rich Results Test, choose the URL test, paste the address and start the check. Expand the detected type and errors. This tool checks Google-supported rich results: the absence of an eligible result does not mean all Schema.org markup is invalid.

Also open Schema Markup Validator and test the same URL. Compare the values with the content: title, author, organisation, image, URL and dates. An article needs a relevant illustration; a service needs current information. A green validator cannot spot a fictitious author or an unrelated photograph if the code is syntactically valid.

Separately inspect the link preview in a messaging app and the metadata og:title, og:description, og:image. If every article shows the same old banner, configure page-specific images. Remember that messaging apps cache previews and may still show the old card after a fix.

What to check manually in text and images

Compare prices, company details, phone, email, names, captions and buttons with the company’s actual information. Open pages for different industries: reused templates easily retain an unrelated heading or the wrong screen in a mockup. A car service’s phone interface should not offer massages. Follow document and download links: a correct button label does not prove that the file is correct.

To find HTML errors, you can use Nu Html Checker: submit the URL and examine the structural error messages. The developer should assess their impact; a warning count is not a substitute for testing the website. A comprehensive review of search settings is part of a technical SEO audit.

Check the interface on different screens

Compare the site with the approved designs: block order, fonts, colours, images and button text. Then test states a polished mockup may omit: a long heading, no search results, an open menu, a form error and the phone keyboard on screen.

A quick width check in Chrome

1. Open the page, then open developer tools from the browser menu or with F12.
2. Enable the device toolbar using the phone-and-tablet button. In Responsive mode, set the width manually.
3. For an initial pass, check 320, 390, 768 and 1440 pixels. These are practical test widths, not a universal list of every device.
4. At each width, scroll through the entire page and open menus, tables, tabs and forms. Record the URL, width and a screenshot of the problem.

Device Mode helps test responsiveness but does not fully reproduce a physical phone. Repeat the main journey on a real Android phone and iPhone if these devices are part of your audience.

What counts as a defect

• The entire page shifts sideways, a heading is clipped or a button extends beyond the screen. A wide table may have its own horizontal scrolling without widening the whole page.
• An important illustration or text disappears on mobile without prior agreement.
• An open menu cannot be closed, its long list cannot be scrolled or the user cannot return to the page.
• The keyboard hides a field and button with no way to reach them.
• A phone link dials the wrong number, an email link has an error or the success message is unreadable.

Also move through the controls using Tab. Focus should be visible, buttons and fields reachable, and errors explained in text. Zoom the browser to 200% and confirm that the content and main action remain usable. Test any agreed accessibility requirements against a separate checklist.

Make sure the enquiry reaches its recipient

A “Thank you” message only proves that a message was displayed. Form acceptance ends where an employee starts handling the enquiry: email, CRM or the order system. Notify the responsible person before testing so the test is not mistaken for a real customer.

Test every form step by step

1. List the different forms: page-footer enquiry, callback, popup, brief and file upload. Forms that look identical may use different handlers.
2. Open the relevant page. To test attribution, you can add agreed test parameters: ?utm_source=acceptance&utm_medium=test&utm_campaign=site_handover.
3. Use an identifiable label, such as “ACCEPTANCE TEST — service form — 14:35”, and your own approved contact details. Enter a distinct value in each field so missing data is easy to spot.
4. Submit the form once. Record the time and the on-screen result.
5. Find the email in the inbox and check spam. If CMS storage is expected, find the record there. In the CRM, check the enquiry record, pipeline, owner, phone, comment and source.
6. Compare the received data with what you submitted. Attachments must open, links must lead to the right content and campaign parameters must reach their intended fields.

Expected result: The enquiry is stored and delivered through the agreed chain, no fields are lost and the employee can identify its source. If the CMS has a record but the email is missing, these are separate results: storage succeeded, notification delivery is unconfirmed.

Test errors and resubmission

Shop, payments and account area

For a shop, check price, quantity, discount, delivery, total and stock. Agree on the payment provider’s test mode: successful payment, failure and cancellation, return to the site and order status changes. Do not test real charges with an arbitrary card. The order and payment system must agree on ID, amount and status.

Create two test accounts with different roles for the account area. Check sign-in, sign-out, recovery and permitted actions. Users must not see another person’s order or document by opening its URL. Use only agreed test data. Investigate field-transfer and enquiry-routing errors with a specialist in CRM integration.

Check Metrica goals after a real action

First, sign in to Yandex Metrica using the client’s account. Verify the domain and tag ID and make sure settings and required reports are accessible. Request the goal list: what counts as an enquiry, phone click, download or purchase.

How to enable the debugger

1. Open the page with the parameter ?_ym_debug=2. If the URL already has a question mark, append &_ym_debug=2.
2. Perform the target action and open the debug panel at the bottom of the page.
3. In the tabs Events and Console check the tag ID and event. Compare them with the agreed goal.
4. Then find the conversion in the report, allowing for processing delay and filters excluding your own visits.

The mode _ym_debug=2 is intended for the new tag code. If the panel does not appear, use Yandex’s documented alternative with _ym_debug=1 and the browser console. Exact steps and reasons for missing events are in the official goal-checking instructions.

How to recognise an incorrectly configured goal

Compare three actions: opening the form, clicking submit with empty fields and successfully submitting a completed form. If all three increment “Enquiry received”, reporting overstates results. A separate “Button click” goal may legitimately record clicks; name it correctly and do not present it as a received enquiry.

Save the test time, goal name, event screenshot and the received enquiry. Refresh after a successful submission: the event should not repeat without a new enquiry unless that behaviour is explicitly intended. With Google Analytics 4, similarly compare an event in debugging or real-time reports with the actual action; the account and permissions must also be handed over to the client.

How to run PageSpeed and understand what to fix

Test each URL separately

1. Open PageSpeed Insights, paste the full URL and start the analysis.
2. Wait for the report. Check both tabs: mobile and desktop. Their scores and test conditions differ.
3. Save the report link, date, URL and device. When retesting, record the changes made between runs.
4. Start with real-user data if available, then review lab diagnostics. Check whether the real-user section applies to this URL or the whole origin.
5. Expand the recommendations and identify specific resources: images, scripts, fonts or requests. Send their URLs and the problem description to the developer with the report.

If acceptance covers every page, keep a register of all URLs with two reports per URL. Testing the homepage, one service and one article can reveal template-wide issues, but does not verify all other pages.

Core Web Vitals thresholds apply to the 75th percentile of real visits, split by device type. A new or low-traffic site may have no such data. That means neither zero speed nor an automatic failure. Definitions and conditions are in the Web Vitals documentation.

Example report analysis

Another example: CLS is high and an image pushes text down as it loads. Ask for its space to be reserved using dimensions or an aspect ratio, then retest. If the page takes a long time to respond, the developer must investigate the server, cache and application. A single timing metric cannot automatically blame the database or hosting.

Must you insist on exactly 100?

A Lighthouse score is the result of a particular lab run. Measurement conditions affect it; Google explains the calculation and variability in its performance-scoring documentation. If the requirements specify 100, record the metric, device and conditions, then verify the actual result. You cannot claim “100 across the whole site” from one screenshot.

After speed improvements, retest enquiries, menus, analytics and mobile viewing. Removing an illustration or disabling a required tracker for a better score changes functionality and needs a separate decision. Accessibility, SEO and best-practice scores are useful too, but automated tests do not cover every acceptance requirement.

Verify a backup by restoring it

Ask for the latest backup date, contents, storage location, frequency and retention period. For a database-backed site, an archive of one folder is usually insufficient: you need the database, files, uploads and required settings. For a website builder, establish the platform’s restoration method and limitations.

A controlled restoration test

1. Choose a specific backup and record its date. Agree exactly what it should restore.
2. Ask the developer to restore it in an isolated test environment. Do not replace the live site for an experiment.
3. Before starting the restored copy, disable real payments, mailouts, notifications and other external actions. Restrict access to the test environment by outsiders and search crawlers using appropriate controls.
4. Open pages, sign in to the CMS and check images, data and the main journey using test recipients.
5. Record restoration time, missing parts and instructions. Ensure the responsible person can access the backup even if the primary server is lost.

Expected result: You know which version can be restored and how long it takes; the restoration has actually been performed. “The hosting provider backs everything up” leaves the item unverified without a test.

Basic security checks at handover

Match CMS users to responsible people, review unnecessary test accounts and contractor permissions, and clarify CMS and extension update procedures. Check that backup archives and configuration files are not publicly linked and test data has not reached production. WordPress provides official hardening guidance.

These steps do not replace a full security audit. Complex account areas, payments or sensitive-data processing require a separately agreed set of tests. Backups and regular updates need a designated owner within technical maintenance.

Check that you can update the site yourself

Request instructions and perform a routine task without developer guidance: draft an article, add an image and alt text, set a search title, insert an internal link and preview it. Then change a price in a test record and restore the old value. Do not train on the public homepage.

If an important action requires manual code changes, that must be a known project limitation, not a surprise after handover. Instructions must match the actual admin interface, editor role and current site version.

• Receive the agreed set of source code, designs, licences and materials.
• Document publication, rollback and dependency-update procedures.
• Assign responsibility for the domain, hosting, backups and incident alerts.
• Record the support channel, agreed response times and maintenance scope.
• Check the handover against the contract: a technical checklist alone does not define payment terms, warranties or the legal consequences of signing documents.

How to report defects and verify fixes

Each report should describe one reproducible problem. Instead of “the site is slow”, provide the URL, device, time and report link. Instead of “the form is broken”, list the steps and the final destination where the enquiry is missing. This lets the developer reproduce the failure and the client verify the result.

Fix priorities

Blocks launch: The main journey fails, orders are lost, agreed access is missing, other users’ data is exposed or important pages are unavailable. Fix before acceptance is completed: Incorrect search settings, widespread broken links and critical mobile defects. Scheduled improvement: A minor visual difference with no loss of content or functionality. Agree the actual priority based on business impact and project requirements.

When told “fixed”, repeat the original steps on the updated version. Save new evidence, date and result. For a shared template defect, automatically check all affected URLs and manually test different states. Fixing one card does not prove the whole catalogue is fixed.

Record the acceptance outcome: what was checked, fixed or remains open, who owns each item and its deadline. Complete handover documents according to your contract.

Checklist before completing acceptance

Tick an item only after checking it. These checkboxes are temporary and reset on reload: copy the results and evidence links into your own log.

Frequently asked questions about website acceptance