Website fixes: search
Helping Google understand your site.
These checks cover what Google and social apps read when they visit your site: whether a page may be listed at all, the title and description people see in search results, which address counts as the real one, and the preview card that appears when someone shares your link. Most fixes are a setting in your site builder or SEO plugin rather than a rebuild.
The page tells search engines not to list it
What it means. A "noindex" instruction asks search engines to leave a page out of their results. It can sit in the page as a robots meta tag (<meta name="robots" content="noindex">), or the server can send it as an X-Robots-Tag header, which you can't see in the page at all. "none" means the same as noindex plus nofollow.
Why it matters. Google obeys it. While it's there, the page won't appear in Google, however good it is. It's normal on a staging copy of a site, and easy to carry over to the live site at launch.
How to fix it. Remove the instruction from every page you want found. Then use URL Inspection in Google Search Console to ask Google to look at the page again.
- WordPress: in Settings, under Reading, untick "Discourage search engines from indexing this site". SEO plugins also have a per-page option to hide a page from search; check it's off.
- Other platforms: look for a per-page setting that hides the page from search engines. If there isn't one, the theme or an add-on may be writing the tag.
- A header comes from the server or hosting setup (an
.htaccessfile, a Cloudflare rule). Your host or developer can remove it.
How the check spots it: it reads every <meta name="robots"> and <meta name="googlebot"> tag and the X-Robots-Tag header for "noindex" or "none" aimed at Google; instructions for another crawler by name ("bingbot: noindex") are ignored. A header noindex that may only be meant for another crawler is worth fixing rather than fix first. Google's Lighthouse test also reports here, and it counts a robots.txt block too (see robots.txt blocks the page).
robots.txt blocks search engines from the page
What it means. robots.txt is a small text file at the root of your site (yoursite.com.au/robots.txt) that tells search engine crawlers which addresses they may visit. A Disallow rule covers this page, so Google is told not to read it. Disallow: / on its own covers the whole site.
Why it matters. Google won't read a blocked page, so it can't see what's on it. Blocked pages usually drop out of results, or appear with no description when other sites link to them. Blocking also hides any noindex on the page, since Google never reads it; to keep a page out of search, use noindex and let Google crawl it.
How to fix it. Edit robots.txt and remove or narrow the rule. A Disallow: / left over from building the site is the usual cause. Keep rules only for areas crawlers don't need, such as admin pages.
- WordPress serves a built-in robots.txt. SEO plugins usually include an editor, and a real robots.txt file in the site's main folder takes its place.
- Site builders mostly manage robots.txt for you. If it blocks pages, look for a setting that hides the site or a page from search.
- Google explains the file in its introduction to robots.txt.
How the check spots it: it fetches /robots.txt from the site the page ended up on and reads it the way Google does: the rules for Googlebot if there's a group for it, otherwise the rules for all crawlers (User-agent: *). Wildcards count, the longest matching rule wins, and Allow wins a tie. It tests the page's own path. If the home page and an ordinary page like /about-us are both blocked too, it says the whole site is blocked.
The page returns an error
What it means. Every answer from a web server starts with a status code. 200 means OK, 404 means "not found", 410 means "gone", and codes from 500 up mean the server itself failed. After any redirects, this page answered with an error code.
Why it matters. Visitors see an error instead of your page. Google doesn't list pages that answer "not found", and while a short server outage is usually forgiven, one that lasts can see pages dropped from results.
How to fix it. Start with the kind of error.
- 404, 410 or another 400-level code: check the address you entered. If the page has moved, add a permanent (301) redirect from the old address to the new one. If it's your home page, the site may not be published, or the domain may point at the wrong host.
- 500 and up: look at your hosting's error log, or ask your host. On WordPress, a recent plugin or theme update is a common cause; undoing the latest change often brings the page back.
- Google describes how each code affects it in HTTP status codes and Google Search.
How the check spots it: it requests the page as a browser would, following up to six redirects, and reports a final status of 400 or above. 401, 403 and 429, and bot-protection challenges, aren't reported here, because they usually mean the site turned the check away rather than visitors. Google's Lighthouse test reports a failing status code under this entry too. While the page answers with an error, most other page checks can't run.
The page has no title
What it means. A page's title comes from the <title> tag in its head. Browsers show it on the tab and in bookmarks, and Google usually uses it as the clickable headline of your search result.
Why it matters. Without one, Google has to make up a headline from other text on the page, and the browser tab shows only the address. Bookmarks and some shared links look unfinished too.
How to fix it. Give every page its own title that says what the page offers and, for a local business, where: "Plumber in Brunswick | Smith Plumbing". Put the most important words first and keep your business name at the end.
- WordPress: themes normally print the title for you, and SEO plugins let you write one for each page. A missing title often points to an old or broken theme.
- Wix, Squarespace and Shopify: set it in each page's or product's SEO or search listing settings.
- Google's advice is in influencing your title links.
How the check spots it: it looks for a <title> tag with text in it, ignoring titles inside inline SVG images. An empty title counts as missing. Google's Lighthouse test checks the same thing, and the report lists it once.
Links on the page lead to broken pages
What it means. The check followed a few of the links on your page to other pages on your site, and some answered "not found" or a server error instead of loading.
Why it matters. Visitors who click those links hit a dead end, often on something they wanted, like a service, a price list or a booking page. Google follows the same links and finds the same errors.
How to fix it. For each address listed, correct the link, bring the missing page back, or add a permanent (301) redirect from the broken address to the closest live page. Then look for the same link in your menu, footer and other pages: templates repeat links, so one fix can clear many.
- A server error (500 and up) on one page while others load usually points to a plugin, app or template that only that page uses. Your host's error log may name it.
- If a page was renamed, update the link rather than relying on a redirect.
How the check spots it: it picks up to four links from the checked page that stay on the same site, preferring different sections. It skips the home page, addresses with a query string (?), files like PDFs and images, and areas such as login, cart, admin and search, and only fetches what robots.txt allows (nothing at all if robots.txt can't be confirmed). A page that answers 404, 410 or 500 and up, after up to two redirects, counts as broken; any 500-level error makes it fix first. It's a small sample, not a count of every broken link on the site.
robots.txt returns an error
What it means. When asked for your robots.txt file, the server answers with a server error (500 and up) or "too many requests" (429), instead of the file or a plain "not found".
Why it matters. Google can't tell what it's allowed to crawl, so it plays safe. Its documentation says that for these errors it treats the site as blocked for a while and keeps retrying, then falls back on the last copy of the file it saved, for up to 30 days. In the meantime, new pages and changes are slow to show up in search.
How to fix it. Open yoursite.com.au/robots.txt in a browser.
- If it errors for you too, ask your host or developer to check the server's error log.
- If it loads for you but not for automated tools, a firewall or bot-protection setting may be rate-limiting crawlers. Make sure robots.txt is never blocked or challenged.
- A site with nothing to block can serve a short file that allows everything, or none at all (see no robots.txt).
- Google sets out how it handles each answer in how Google interprets robots.txt.
How the check spots it: it requests /robots.txt on the site the page ended up on, following up to three redirects, and reports an answer of 429 or 500 and up.
The address with or without www doesn't lead to your site
What it means. People type your address both ways: yoursite.com.au and www.yoursite.com.au. They're technically two addresses, and each needs its own DNS record (the internet's address book entry), a valid https certificate and a redirect to whichever one you treat as the main address.
Why it matters. If the other version has no DNS record, shows an error or a certificate warning, or leads to another website, people who type it that way never reach you, and may assume you've closed. If both versions show the site without redirecting, Google can find two copies of every page; a canonical tag limits that, a redirect settles it.
How to fix it. Choose one version as the main address. Give the other a DNS record, a certificate and a permanent (301) redirect to the main one.
- Wix, Squarespace and Shopify: connect both versions of the domain and mark one as primary; the platform redirects the other.
- Elsewhere, hosts usually have a "redirect to www" (or "without www") setting. On Cloudflare, add a proxied DNS record for the other name and a redirect rule. A Cloudflare error in the 520s or a 530 usually means a DNS record still points at an old host, or at nothing.
How the check spots it: for yoursite.com.au it tries www.yoursite.com.au, and the other way round (it doesn't add www. to subdomains like shop.), loading it over https and following up to four redirects. No DNS record, a failed connection, a redirect loop, an error status or landing on another website is worth fixing; both versions answering without a redirect is nice to have. If the other version turns the check away (401, 403, 429 or a bot challenge), nothing is reported.
The canonical tag is missing or points somewhere unexpected
What it means. A canonical tag (<link rel="canonical" href="…"> in the page's head) tells Google which address is the main one for a page. The same page can often be reached several ways: with or without www., with or without a trailing slash, or with tracking codes like ?utm_source= on the end. The canonical says which one to list.
Why it matters. Google treats the canonical as a strong hint. One that points at another website, or another page, can lead Google to list that address instead of this page. Several conflicting canonicals, or one that isn't a usable address, are likely to be ignored. A missing one is the mildest case: Google picks the main address itself.
How to fix it. Give each page exactly one canonical tag, with its own full address, unless the page really is a copy of another. Google recommends full addresses (https://www.yoursite.com.au/services/) rather than relative ones.
- WordPress: SEO plugins add a canonical automatically. Two at once usually means two plugins, or a plugin and the theme, are both doing it; switch one off.
- A canonical pointing to another website usually comes from a copied theme, pasted code or a move between domains.
- Google explains the options in how to specify a canonical URL.
How the check spots it: it reads the page's <link rel="canonical"> tags and compares the address with the page that loaded, ignoring www., a trailing slash and anything after ?. More than one tag, an address it can't use (an IP address, a port number, a local name) or another website is worth fixing; another page on your site, or no tag at all, is nice to have. A relative address passes.
Noindex and a canonical to another page give mixed signals
What it means. This page carries two instructions that pull in different directions. Its robots meta tag says "don't list this page" (noindex), while its canonical tag says "the main version of this page is over there".
Why it matters. A canonical says "this is a copy, list the other one", which only makes sense for a page Google may index. Google's guidance is to use a canonical, not noindex, for duplicate pages, because noindex shuts the page out of search completely. With both, Google has to guess what you meant.
How to fix it. Decide what the page is for, then keep the instruction that matches.
- It's a copy of another page (a print version, a filtered list): remove the noindex and keep the canonical.
- It should stay out of search altogether (a thank-you page, a members' page): keep the noindex, and point the canonical at the page itself or remove it.
- In WordPress, both settings usually live in the SEO plugin's panel for that page, so you can change them together.
How the check spots it: it combines the page's <meta name="robots"> and <meta name="googlebot"> tags and reports when they say noindex (or none) while a <link rel="canonical"> points to a different page, ignoring www., a trailing slash and anything after ?. The noindex is also reported on its own (noindex), and the canonical may be too (canonical).
Pages that don't exist don't say so
What it means. When someone asks for an address that doesn't exist on your site, the server should answer 404 ("not found") or 410 ("gone"). Here a made-up address either loaded as a normal page with status 200 ("OK"), or was redirected to your home page.
Why it matters. Google calls these soft 404s and flags them in Search Console. Broken links, old addresses and typos never show up as broken, so they're hard to find. Sending every missing page to the home page also leaves visitors wondering why they're not where they expected.
How to fix it. Set your server or platform to answer 404 for addresses it doesn't know, with a helpful "page not found" page: a short message and links to your main pages. Keep permanent redirects for pages that really moved.
- WordPress answers 404 by itself; a plugin or setting that sends all missing pages to the home page is the usual cause.
- Sites built as a single JavaScript app often answer every address with the same page; the developer needs to add a real 404 response.
How the check spots it: it requests a made-up address (/mattg-check-no-such-page- plus random letters), following up to three redirects. 404 or 410 passes. A 200 reached by redirecting to the home page or the checked page is nice to have; any other 200 is worth fixing. Other answers give no verdict. The business policy check runs its own test (a made-up address loads a normal page).
A made-up address loads a normal page
What it means. This is the same problem as pages that don't exist don't say so, found by a second part of the check: an address that can't exist on your site answered 200 ("OK") with a web page instead of 404 or 410.
Why it matters. Broken links on your site and elsewhere go unnoticed, and Google flags addresses like these as soft 404s in Search Console.
How to fix it. Make the server answer 404 for unknown addresses, with a not-found page that offers a way back into the site. Fixing it once clears both findings.
How the check spots it: the business policy check asks for /mattg-audit-missing-page-8c67b2e9, following up to two redirects within your site, and reports it if the answer is 200 with an HTML page. Unlike the first-hand test, it counts a redirect to the home page the same as a page that loads in place. It only makes the request when robots.txt could be read and allows that address.
The page has no meta description
What it means. The meta description (<meta name="description" content="…">) is a sentence or two in the page's head that sums the page up. Visitors don't see it on the page itself.
Why it matters. Google often shows it as the snippet under your title in search results, when it suits what the person searched for. Without one, Google picks text from the page, which may be a menu, a cookie notice or a sentence cut off part-way. Some social and messaging apps also use it for link previews when there's no og:description.
How to fix it. Write a description for each important page, in plain words, that tells a searcher what they'll find and gives them a reason to click. One or two sentences is enough; see the description is long for length. Make each page's description its own rather than repeating one everywhere.
- WordPress: SEO plugins add a description field to each page and post.
- Wix, Squarespace and Shopify: it's in each page's or product's SEO or search listing settings.
- Google explains how it chooses snippets in control your snippets in search results.
How the check spots it: it looks for a <meta name="description"> tag with text in its content. An empty one counts as missing. Google's Lighthouse test checks the same thing, and the report lists it once.
The page title is just a generic word
What it means. The page's title is something like "Home", "Welcome", "Untitled", "Index" or just your web address. "Just another WordPress site", WordPress's old default tagline, often turns up in titles too.
Why it matters. The title is usually the headline of your Google result and the name on the browser tab. "Home" tells someone scanning results nothing about what you do, and Google's own guidance warns against vague titles like it. Google may write its own headline instead, and you lose your say in what it shows.
How to fix it. Write a title that says what you offer and where, then your business name: "Plumber in Brunswick | Smith Plumbing". For a home page, that's usually your main service and area.
- WordPress: check the Site Title and Tagline in Settings, under General, and your SEO plugin's title setting for the home page.
- Site builders keep the page's SEO title separate from its name in the menu, so "Home" can stay in the menu while the title says something useful.
How the check spots it: it compares the whole title, ignoring capitals, with a list of generic ones such as home, home page, index, untitled, new page, welcome, my website, default, page title, document, landing page and "just another wordpress site", and flags a title that's only the site's address, with or without www. A title that merely contains one of these words isn't flagged. A short generic title may also appear under title length.
The page has no main heading
What it means. The main heading is the <h1> tag: usually the largest words at the top of the content, like "Emergency plumbing in Brunswick". Text that's only been made big and bold doesn't count unless it's marked up as a heading.
Why it matters. Screen reader users often jump straight to the main heading to find where the content starts and what the page is about. Google reads headings to understand a page too, and may use the main heading when it writes the headline for your result.
How to fix it. Give each page one <h1> near the top of its content that says what the page is about. In most editors, set the top heading's style to "Heading 1" (or H1) rather than enlarging normal text.
- WordPress: many themes print the page title as the H1 automatically. If yours doesn't, check the theme's options for hiding the title, or add a heading block set to H1.
- Wix, Squarespace and Shopify: choose the Heading 1 text style for the main heading.
How the check spots it: it counts <h1> tags in the page's HTML as delivered, before any JavaScript runs, and reports when there are none. More than one is a separate finding, under Accessibility.
Linked pages are missing a title, heading or description
What it means. Among the few pages the check followed from yours, at least one has no title, no main heading with text in it, or no meta description.
Why it matters. Each does the same job on every page as on the one you checked. The title (no title) is usually the headline of a Google result, the description (no meta description) is often the snippet under it, and the main heading (no main heading) tells visitors and screen readers what the page is about. Inner pages, like a service page, are often the ones people land on from a search.
How to fix it. Open each page listed and fill in what the example says is missing. In WordPress, SEO plugins put title and description fields in the page editor; on site builders they're in each page's SEO settings. Pages made from a template (blog posts, products, locations) often share the gap, so fix the template if you can.
How the check spots it: it looks at up to four pages linked from the checked page (chosen as described under broken pages), not the checked page itself, and lists any without a title, without an <h1> that has text, or without a meta description with text. It reads each page's HTML as delivered, before JavaScript runs.
Different pages share the same title
What it means. Two or more of the pages the check looked at have exactly the same title, so in a browser tab or a list of search results they look like the same page.
Why it matters. Google's guidance is to give each page a title that describes that page. When several share one, people can't tell from the results which page has what they want, and Google may write its own headlines for them instead. It's often the sign of a template that gives every page one title.
How to fix it. Rewrite each title to say what that page is about, keeping your business name at the end if you like: "Blocked drains | Smith Plumbing" and "Hot water repairs | Smith Plumbing". If a theme or SEO plugin builds every title from one pattern, make sure the pattern includes the page's own name.
How the check spots it: it compares the titles of the checked page and up to four pages linked from it (see broken pages), ignoring capitals and extra spaces. It only compares the pages in this sample, so the site may have other duplicates.
There's very little text on the page
What it means. The page's HTML holds few words. Either the page really is short (a gallery, a single "call us" line), or its words are added by JavaScript after it loads, so the HTML that arrives first is nearly empty.
Why it matters. Words are how visitors and Google learn what you do and where. Google says it has no preferred word count, so this isn't about length for its own sake: it's whether the page answers what someone came for. When the text only arrives through JavaScript, Google can usually still read it once it runs the scripts, but link previews in social and chat apps, and some other search engines, see a nearly blank page.
How to fix it. On a short page, add a few clear paragraphs: what you offer, who it's for, where you work and how to get in touch. Words inside images don't count, so write them as text. On a page built with JavaScript, ask your developer about server-side rendering or pre-rendering, so the HTML arrives with the words already in it. Google's view on length is in creating helpful content.
How the check spots it: it counts the words in the page's HTML outside <head>, leaving out scripts, styles and comments. Under 30 words on a page with at least one script is worth fixing, since the text is probably added by JavaScript; otherwise, under 150 words is nice to have. Menus and footers count towards the total, so the main content may be shorter still.
Links or files point to a staging, local or hosting address
What it means. Some links, images, scripts or stylesheets on the page use an address from when the site was being built: a staging copy (staging. or dev. in front of your domain), the developer's own computer (localhost, a .local or .test name, or a file path like C:\), or a temporary address from a hosting company or site builder.
Why it matters. Visitors who click these links land on a copy of your site that may be out of date, password-protected or gone. Images, scripts and styles loaded from there can stop working the day the copy is switched off, and search engines may find and list the copy's pages.
How to fix it. Change each address listed to the live site's, or better, to a plain path like /services/ that works on any domain. Check menus, widgets and page-builder sections too, as they often store full addresses.
- After a WordPress site moves, a database search-and-replace of the old address fixes most of these at once. Your developer or host can run it safely.
How the check spots it: it looks through the page's links, images, scripts and stylesheets for local addresses (localhost, private network numbers, .local, .test), file paths, temporary hosting and builder domains (such as .netlify.app, .pages.dev or .myshopify.com), and names like staging., dev., test., preview. or old. in front of your own domain. It's skipped when the checked site is itself on one of these addresses.
Shared links are credited to the wrong address
What it means. The og:url tag in the page's head tells Facebook, LinkedIn, WhatsApp and similar apps which address a shared link belongs to. Here it names a different website, a different page on your site, or something that isn't a usable address.
Why it matters. Apps that follow it treat a share of this page as a share of the address it names. Likes and share counts go there, the preview may show that page's details, and some apps open that address instead of this page. Another website is the worst case: shares of your page end up crediting that site.
How to fix it. Set og:url on each page to that page's own full address, the same as its canonical (canonical), or remove the tag so apps use the address that was shared. A wrong one is usually left over from a template, a copied theme or a staging site, or comes from a setting that gives every page the home page's address. On WordPress, SEO plugins set it for you; if it's wrong, look for a second plugin or theme feature adding sharing tags.
How the check spots it: it only runs when the page has an og:url. It compares it with the page that loaded, ignoring www., a trailing slash and anything after ?, and accepts it if it matches the page's canonical. Another website is worth fixing; another page on your site, or an address it can't use, is nice to have.
No sitemap search engines can read
What it means. A sitemap is a file that lists the pages on your site for search engines, usually at yoursite.com.au/sitemap.xml. Its address is normally also given in robots.txt, on a Sitemap: line.
Why it matters. Google finds most pages by following links, but a sitemap helps it find new and changed pages sooner, and pages few links lead to. Google says a small, well-linked site may not need one, so a missing sitemap there is minor. A sitemap that robots.txt names but that doesn't load, or that isn't in a format search engines read, is a broken signpost.
How to fix it. Most platforms make one for you.
- WordPress makes one itself (at /wp-sitemap.xml), and SEO plugins usually replace it with their own. Wix, Squarespace and Shopify publish one at /sitemap.xml automatically.
- Add a
Sitemap:line with its full address to robots.txt, and submit it in Google Search Console. - If robots.txt names an old sitemap address, often after switching SEO plugins, update the line.
- Google explains when a sitemap helps in its sitemaps overview.
How the check spots it: it fetches the sitemap robots.txt names, or /sitemap.xml if it names none, following up to three redirects. An XML sitemap or sitemap index, a gzipped one, or a plain text list of addresses passes. A sitemap named in robots.txt that doesn't load, or a file in another format, is worth fixing. Nothing at /sitemap.xml, or a web page served there, is nice to have.
The sitemap lists addresses Google won't use
What it means. The addresses inside your sitemap are on a different domain from the sitemap itself, often a staging or old address, or the www. version when the sitemap is on the version without it. Or they start with http:// although the site runs on https.
Why it matters. Unless you've set up cross-site submission in Search Console, Google only accepts sitemap addresses on the sitemap's own host, and reports the rest as "URL not allowed", so the sitemap may list nothing Google can use. http:// addresses go against the sitemap rules too, and each is a redirect Google must follow to reach the real page.
How to fix it. Make the sitemap list your live, main addresses. If the site answers both with and without www., settle that first (www) and use the main version.
- WordPress: check the WordPress Address and Site Address in Settings, under General, then regenerate the sitemap in your SEO plugin. After a move, the old address may also need replacing in the database.
- A sitemap made by a separate tool or by hand needs updating to your main https:// address.
How the check spots it: it reads up to 500 addresses from the sitemap it found (see sitemap) and compares each one's host with the host the sitemap loaded from, treating www. as different. Any on another host is worth fixing. If none are, http:// addresses in a sitemap served over https are nice to have. In a sitemap index, it checks the addresses of the sitemaps listed.
The page redirects or reloads with a meta refresh
What it means. A <meta http-equiv="refresh"> tag tells the browser to go to another address, or reload this one, after a set number of seconds. With a url= in it, it's a redirect done by the page instead of the server. Without one, the page reloads itself on a timer.
Why it matters. As a redirect, it's slower than a server redirect, because the browser loads this page first and then the next. Google treats an instant meta refresh as a permanent redirect and a delayed one as temporary, and recommends a server-side redirect wherever possible. As a timed reload, it throws away what people have typed, jumps them back to the top and starts screen readers over; WCAG counts a timed reload, or a delayed redirect people can't control, as failing success criterion 2.2.1 (Level A).
How to fix it. Remove the tag, and do its job another way.
- A redirect: set up a permanent (301) redirect in your hosting, server or platform's redirect settings instead.
- A reload: if part of the page needs to stay current, like a live feed, have a script update just that part.
- Google compares the kinds of redirect in redirects and Google Search.
How the check spots it: it looks for a <meta http-equiv="refresh"> tag anywhere in the page outside scripts and <noscript>. If its content includes url=, it's a redirect, reported under Search as worth fixing. If not, it's a timed reload, reported under Accessibility as nice to have.
Head tags appear in the body of the page
What it means. A page has two parts: the head, which holds information for browsers and search engines (title, description, canonical and robots tags), and the body, which holds what people see. Here some head tags come after the body has started. Either a theme or plugin prints them late, or something that doesn't belong in the head (an image, an iframe, stray text from pasted tracking code) sits above them and makes the browser end the head early.
Why it matters. Google's documentation says that when it meets an element that doesn't belong in the head, it assumes the head has ended and ignores the head elements after it. A noindex, canonical or description below that point may not count, and social apps may miss them too.
How to fix it. Move the title, meta and canonical tags up into <head>, above anything else added there. If tracking code is the culprit, put its body part (often an <iframe> or <img>) straight after the opening <body> tag. On WordPress, look at plugins that add code to the head and at any edits to the theme's header. Google lists what may go in the head in use valid HTML to specify page metadata.
How the check spots it: it works out where the body starts the way a browser does: at <body>, or at the first tag that can't go in the head. After that point it reports any <title>, <base> or <link rel="canonical">, and any <meta> named description, robots, googlebot or viewport, with line numbers so you can find them.
The address doesn't return a web page
What it means. The address you checked sends back something other than a web page: a PDF, an image, a data file, or a file with no stated type. The server says what it's sending in a Content-Type header, and here that isn't HTML.
Why it matters. There's no page for the check to read, so most results are missing. If this address is meant to be a page people visit, browsers may download it or show it as plain text instead of displaying it.
How to fix it. If you meant to check a file, enter the address of a page instead, such as your home page. If the address should be a page, the server is labelling it wrongly: ask your host or developer to send it with Content-Type: text/html. That usually comes down to a server setting or a file saved with the wrong extension.
How the check spots it: it reads the Content-Type header of the final answer, after redirects, and reports anything other than text/html or application/xhtml+xml.
No structured data, or structured data with a syntax error
What it means. Structured data is code in the page, using a vocabulary called schema.org, that spells out facts for search engines: your business name, address, phone number, opening hours, products or events. The usual form is JSON-LD, a <script type="application/ld+json"> block that visitors don't see.
Why it matters. Google uses it to understand the page with less guesswork, and some kinds make a page eligible for richer search results, like product prices or event dates. Google decides whether to show them, so eligibility isn't a guarantee. A block with a syntax error, such as a missing comma or quote mark, can't be read at all.
How to fix it. It depends on which of the two the report found.
- None: add Organization or LocalBusiness structured data to your home page. Many SEO plugins, themes and site builders add it once you fill in your business details.
- Syntax error: test the page in Google's Rich Results Test, which points to the mistake. If you didn't write the code, fix it in the plugin, app or setting that added it.
How the check spots it: it reads up to 20 JSON-LD blocks and tries to parse each one; any that fails is a syntax error, worth fixing. No JSON-LD type and no microdata (itemtype attributes) at all is nice to have. It doesn't judge completeness or rich-result eligibility; for a local business, the business listing checks the main details.
The business listing in the structured data is missing details
What it means. Your page has LocalBusiness structured data, or one of its kinds such as Plumber, Dentist or Restaurant, but it leaves out the address, the phone number or the opening hours.
Why it matters. These are the details people act on: where you are, how to call and when you're open. Google's guide to local business structured data lists the address as required, and the phone number and opening hours as recommended. A listing without them gives Google less to go on.
How to fix it. Add the missing properties: address (a PostalAddress with street, suburb, state and postcode), telephone, and openingHoursSpecification for the hours. Use exactly the same details as the page itself and your Google Business Profile. SEO plugins and site builders usually take these from a business details or local SEO settings page, so fill that in rather than editing code. Google lists every property in its local business structured data guide.
How the check spots it: it looks through the JSON-LD for the first item whose type is LocalBusiness or a kind of it (including types whose names end in Business, Store, Service, Clinic and the like), and checks it has address, telephone, and openingHours or openingHoursSpecification. It checks each is there, not that it's right. It doesn't run if a JSON-LD block has a syntax error (structured data).
Shared links have no preview image
What it means. When someone pastes your link into Facebook, LinkedIn, WhatsApp, iMessage or Slack, the app builds a preview card from tags in your page's head. The picture comes from the og:image tag (Open Graph, the format these apps read). This page has none, or its address can't be fetched.
Why it matters. Without a picture, the preview is a small text box or a bare link, easy to scroll past. Some apps pick an image from the page themselves, which may be a logo or an icon.
How to fix it. Add an og:image to each page, pointing at a picture that represents it, such as your work or your shopfront, at its full https:// address. 1200 × 630 pixels works well everywhere.
- WordPress SEO plugins let you set a default sharing image and one for each page. Wix, Squarespace and Shopify have a social sharing image setting.
- Apps keep old previews for a while. Facebook's Sharing Debugger and LinkedIn's Post Inspector can refresh them.
- The tags are defined at The Open Graph protocol.
How the check spots it: it looks for a <meta property="og:image"> with content. If the address can't be used (it isn't http or https, or uses a local name, an IP address or a port number), it reports an address that won't work. A relative address like /og.jpg passes the check, though a full address is the safe choice.
Shared links have a picture but no title or description
What it means. Your page has an og:image for link previews, but no og:title, no og:description, or neither. These are the words that go with the picture on a Facebook, LinkedIn, WhatsApp or iMessage preview.
Why it matters. Without them, each app falls back in its own way: some use the page's title and meta description, others show only the address. The same link can look different, or bare, depending on where it's shared.
How to fix it. Add og:title and og:description next to the og:image. They can match the page's title and meta description, or be a little more conversational for sharing. If a theme adds the image tag by itself, check whether your SEO plugin's sharing (Open Graph) option is on, as it normally writes the whole set.
How the check spots it: it only runs when the page has an og:image, and reports when og:title or og:description is missing or empty. A page with no og:image is covered by no preview image instead.
The page title is very long or very short
What it means. The title is longer than 60 characters, so it may be cut off with "…" in Google's results, or shorter than 15, so it probably doesn't say much.
Why it matters. Google sets no limit on title length, but it shortens result headlines to fit the screen, often somewhere past 50 to 60 characters. If the important words come last, they're the ones that get cut. A very short title, like a business name alone, misses the chance to say what you do and where.
How to fix it. Put the words that matter first: the service and area, then the business name. "Plumber in Brunswick | Smith Plumbing" is 37 characters. Cut repeated words, slogans and long lists of suburbs. For a short title, add what the page is about.
- SEO plugins often add the site name to every title automatically, so titles end up longer than they look in the editor. Check the plugin's title pattern.
How the check spots it: it counts the characters in the page's first <title>, with runs of spaces squeezed to one. Over 60 or under 15 is reported, as nice to have. A missing title is covered by no title, and a generic one by generic title.
The meta description is long
What it means. Your page's meta description is longer than 160 characters.
Why it matters. Google sets no limit on descriptions either, but it shortens snippets to fit the screen, usually around 155 to 160 characters. Anything past that is cut off with "…", so a closing sentence or call to action may never be seen. Google may also choose other text from the page instead.
How to fix it. Lead with what matters most: what the page offers and why someone should click. Keep it to one or two sentences under 160 characters, and give each page its own.
How the check spots it: it measures the content of the first <meta name="description"> tag, after trimming spaces at the ends. Over 160 characters is reported, as nice to have. There's no lower limit; a missing description is covered by no meta description.
The page has more than one title tag
What it means. The page's HTML contains two or more <title> tags. Browsers use the first and ignore the rest.
Why it matters. Only one counts, and it may not be the one you wrote. It's also a sign that two things, usually the theme and an SEO plugin or two plugins, are both writing the page's head, which can double up other tags too, like canonicals (canonical) and sharing tags.
How to fix it. Find what adds the second title and switch it off. On WordPress, an older theme that writes its own title alongside an SEO plugin is the usual pair; a current theme leaves the title to WordPress and the plugin. On other platforms, look for a title tag pasted into a custom header or code injection setting.
How the check spots it: it counts <title> tags anywhere in the page's HTML, leaving out those inside inline SVG images, which are a different thing. More than one is reported, as nice to have.
The site uses temporary redirects
What it means. On the way to your page, at least one redirect answered 302 or 307, which mean "moved for now", rather than 301 or 308, which mean "moved for good". It often happens on the step from http:// to https://, or between the addresses with and without www.
Why it matters. Google's documentation says that after a temporary redirect it generally keeps showing the original address in its results, since you've said the move won't last. For a move that is permanent, that's the wrong message.
How to fix it. Change permanent redirects to 301 (or 308). Where they're set depends on the setup: your host's control panel, a redirect plugin on WordPress, Cloudflare's redirect rules, or a server file like .htaccess. Most redirect settings let you choose permanent or temporary. Keep 302 or 307 for moves that really are temporary, like a sale page for a week. Google explains the difference in redirects and Google Search.
How the check spots it: it records each hop on the way to the page you entered and reports any 302 or 307 before the final page.
Links to your own pages use http://
What it means. Your site runs on https://, but some links on this page point to your own pages at http:// addresses.
Why it matters. Each click goes to the insecure address first and is then redirected to the https:// one: an extra round trip that phones feel. If the http to https redirect ever goes missing, those links lead to an insecure page. Google follows the links too, and meets the same extra redirect each time.
How to fix it. Change the links to https://, or better, to plain paths like /about/, which work whatever the domain. On WordPress these are usually old links in page content or menus from before the site moved to https; a database search-and-replace of http://yoursite.com.au with https://yoursite.com.au fixes them together, and your developer or host can run it safely.
How the check spots it: on a page served over https, it lists links (<a href>) that start with http:// and go to the same site, with or without www. Links to other websites aren't included.
The page's address could be tidier
What it means. This page's address has one or more habits that make it harder to read and share: WordPress's default ?p= or ?page_id= style, capital letters, spaces (which show as %20), underscores between words, or a file name like index.html or home.php on the end.
Why it matters. A short, readable address like /wedding-dj/ is easier to remember, say out loud and trust in a link. Google advises readable words with hyphens, not underscores, between them, and treats addresses as case-sensitive, so /About and /about can be two pages to it. An address ending in index.html usually reaches the same page as the one without it.
How to fix it. Change the address to lower case with hyphens between words, and add a permanent (301) redirect from the old one so links and bookmarks keep working. A tidier address isn't worth broken links, so always add the redirect.
- WordPress with
?p=addresses: choose "Post name" in Settings, under Permalinks. WordPress normally sends the old addresses on to the new ones itself; test a couple afterwards. - Google's advice is in URL structure best practices.
How the check spots it: it looks only at the address of the checked page. page_id or p in the query string is worth fixing; cat, capital letters, spaces, underscores, or an ending of index, default or home with .html, .htm, .php, .asp or .aspx are nice to have.
Some linked pages have very little text
What it means. One or more of the pages linked from yours has fewer than 65 words in its HTML.
Why it matters. A page with only a heading and a photo or two may not answer what someone came for: what a service includes, who it's for, what it costs. Google says it has no preferred word count, so this is about whether the page is useful, not about reaching a number. Some pages are short for good reason, like a gallery or a booking tool, and interactive pages may load their words later with JavaScript.
How to fix it. Open each page listed and ask whether a visitor would find what they need. If not, add a few plain paragraphs: what it is, who it's for, where you offer it, what it costs and how to get in touch. If a page has nothing to say, consider taking it out of the menu.
How the check spots it: it counts the words in the HTML of up to four pages linked from the checked page (see broken pages), outside <head> and leaving out scripts and styles. Under 65 words is reported, as nice to have. Pages whose address has contact, about, privacy, terms, policy, login, sign, account or search as a part of its own are left out, since those pages are often short. That includes /contact-us/ and /about-us/, but not /design/.
The site has no robots.txt file
What it means. Asking for yoursite.com.au/robots.txt returns "not found". robots.txt is an optional text file that tells search engine crawlers which parts of a site to stay out of, and where the sitemap is.
Why it matters. Not much. With no robots.txt, Google treats the whole site as open to crawling, which is what most small sites want. The main thing you miss is a place to point search engines at your sitemap (sitemap).
How to fix it. It's optional. If you want one, three lines are enough: User-agent: *, then Allow: /, then Sitemap: followed by your sitemap's full address. Save it as robots.txt in the site's main folder. WordPress and most site builders normally provide one, so if yours is missing on those, ask your developer or host why.
How the check spots it: it requests /robots.txt on the site the page ended up on, following up to three redirects, and reports an answer of 404 or 410, as nice to have.
The file at /sitemap.xml doesn't look like a sitemap
What it means. The address yoursite.com.au/sitemap.xml answered, but what came back didn't have the opening and closing tags of a standard XML sitemap (<urlset>) or sitemap index (<sitemapindex>).
Why it matters. /sitemap.xml is the first place many tools look for a sitemap. If something else answers there, often your home page or a "not found" page sent as a normal page, they find the wrong thing. If it is your sitemap, it may be broken or cut short.
How to fix it. Open /sitemap.xml in a browser. If you see a web page, publish a sitemap there or make the address answer 404, and check robots.txt names your real sitemap (sitemap). If you see XML that stops part-way, regenerate the sitemap in your SEO plugin or platform.
How the check spots it: the business policy check requests /sitemap.xml, following one redirect within your site. If it gets a 200 answer, it reads the first 1 MB the same way as the main sitemap check: an XML sitemap or sitemap index, gzipped XML, or a plain-text list of addresses, one per line. Anything else is reported.
The site has no favicon
What it means. A favicon is your site's small icon. It shows in browser tabs, bookmarks and history, and beside your site's name in Google's results.
Why it matters. Without one, browsers show a blank page icon and Google shows a generic one, so your site is harder to pick out among open tabs and results. A favicon that matches your logo makes the site look cared for.
How to fix it. Make a simple square version of your logo, or its first letter, that's readable when tiny. Google requires a square image, recommends larger than 48 × 48 pixels, and must be able to fetch it, so don't block it in robots.txt. Add it with a <link rel="icon"> tag in the head of your home page (ideally every page), or save it as favicon.ico in the site's main folder.
- WordPress has a Site Icon setting, and Wix, Squarespace and Shopify each have a favicon setting.
- Google's requirements are in define a favicon to show in search results.
How the check spots it: if the page has no <link rel="icon"> (or apple-touch-icon) tag, it requests /favicon.ico, where browsers look by default, following up to two redirects, and reports no favicon if that isn't an image. If the page does declare an icon, the check doesn't fetch or test it.
No icon for iPhone home screens
What it means. When someone adds your site to their iPhone or iPad home screen, or Safari shows it among their favourites, iOS looks for an "apple touch icon": a square PNG made for that spot.
Why it matters. Without one, iOS makes do with a stand-in of its own, such as a shrunken screenshot of the page or a plain letter, which can look like a mistake next to app icons. It matters most for customers who come back often, like regulars who book online.
How to fix it. Make a 180 × 180 pixel PNG of your logo on a solid background (iOS rounds the corners itself, so keep the image square). Save it as /apple-touch-icon.png in the site's main folder, or link it with <link rel="apple-touch-icon" href="…"> in the head. WordPress's Site Icon setting creates one from the image you upload.
How the check spots it: if the page has no <link rel="apple-touch-icon"> (or apple-touch-icon-precomposed) tag, it requests /apple-touch-icon.png, where iPhones look by default, following up to two redirects, and reports it missing if no image comes back. A declared icon isn't fetched or tested.