What our free website checker tests

Our free checker tests five signals in the public homepage. The result is a starting point for repairs, and a pass on all five does not mean every part of the site works.

Use the result to ask your provider for a specific change. If you need help with the page itself, our web design service covers design and development with mobile layouts and search foundations.

The phone viewport tag

The checker looks for a meta tag named viewport. It checks whether the tag exists; it does not judge its settings or open the layout on a phone.

The tag tells a browser how to size and scale the page. web.dev's responsive design guidance explains why omitting it can leave a phone displaying a shrunken desktop layout. That can make a menu or service description difficult to read.

If this check fails, ask your developer to add the appropriate viewport settings in the page head. The usual starting values are width=device-width, initial-scale=1. Keep zoom available. Then open the page on an actual phone and check that its content fits.

On the phone, check whether buttons are easy to tap and the booking form fits the screen.

The final connection uses HTTPS

The connection check passes when the final homepage address uses HTTPS and the fetch completes without a TLS error. TLS is the technology behind that encrypted connection.

web.dev explains that HTTPS protects data in transit from interception and modification. That matters when a customer opens your site on a shared network.

Ask your hosting provider to enable and maintain the security certificate, make the intended homepage available over HTTPS, and redirect the old HTTP address appropriately. Have them confirm that the final destination is the correct site.

A broken connection may produce an unreachable result rather than a simple failed HTTPS check. Give the provider the address and the error so they can investigate the cause.

The homepage fetch finishes under two seconds

This check times the server's retrieval of the homepage, including its DNS lookups, redirects and HTML response. It passes below two seconds.

It does not download and render the full page as a visitor's phone would. It is also not the same measurement as Time to First Byte. web.dev defines that metric around the arrival of the first response byte; this checker waits for the homepage body too.

A slow response is worth investigating before a visitor can use the page. Google's page-experience guidance treats performance as part of the broader experience. The checker's two-second cutoff is our tool's threshold, not a Google ranking requirement.

If this check fails, ask the host or developer to inspect the response path. They can check unnecessary redirects, slow server work and whether suitable caching is in place. Retest after the cause is addressed.

A pass does not mean the page loads in two seconds on a phone, which still has to download and draw everything after the HTML arrives. If a customer reports a slow page despite a pass, that complaint still needs attention.

The copyright year

The checker looks for years near copyright wording or a copyright symbol in the returned page text. It uses the highest year it finds. The check passes if the current UTC year minus that year is less than three. If it finds no year, it deducts no points.

An old footer is a prompt to review the page, not proof that the business is inactive. Ask whether the information a customer relies on is still correct.

Google's helpful-content guidance warns against changing page dates merely to make unchanged content appear fresh. Updating a footer alone does not demonstrate that the service information has been reviewed.

If the year is wrong, ask the site maintainer to correct the notice appropriately and review the content with you. The checker cannot verify when the page was last edited.

The homepage has basic search elements

This combined check passes when the returned HTML contains a non-empty title, a description meta tag, and exactly one h1 heading.

Check the wording of each element. Google recommends descriptive, concise page titles. Ask for text that identifies the business and what the homepage covers, rather than a generic "Home."

For the description, Google sometimes uses this text for a search snippet. Write a useful summary.

W3C explains how headings organize page content. Ask your developer to make the main page heading clear and the section headings logical. One h1 is our tool's convention.

The checker examines the HTML it receives without running the site's JavaScript. If the page relies on scripts to add these elements, have the developer inspect what the server actually sends.

Turn the result into a repair request

Each passing check contributes 20 points to the total. Read the explanations alongside the score.

Send your provider the failed check and ask what change addresses it. Request a plain-language explanation if they believe the result is misleading. For an unreachable result, confirm the address and try again before drawing conclusions about the site.

Run the free website checker on your public homepage. Pick a failed check, follow the explanation above, and keep the result with the repair request so you can compare it after the work.