How to Use Google Search Console: Setup and Reports

Learning how to use Google Search Console starts with four tasks: verify your website, submit its sitemap, check whether important pages are indexed, and read the search performance data. This free Google tool helps you understand how your site appears in search and investigate problems that need attention.

This tutorial covers setup and the reports you will use most often. The original screenshots are retained as visual references; some show older menu names. Follow the current instructions in the text when a screenshot differs from your account.

Before starting, have the public website address, your Google account, and a way to verify ownership ready. For a WordPress site, that may mean access to an appropriate verification field; for a Domain property, it normally means access to the authoritative DNS settings. If another person manages those systems, coordinate with them rather than changing unfamiliar records. You can learn the reports without attempting every configuration change yourself.

What Google Search Console can tell you

Search Console reports on your site’s presence in Google Search. It helps you investigate discovery and indexing, understand queries that lead to impressions and clicks, and review reported security or manual action issues. It does not replace an analytics platform for purchases, leads, or behavior after a visitor arrives.

You do not need to register a site in Search Console for Google to find it. Verification gives you access to its data and tools; it is not a ranking boost. If you need the basic concepts before setup, start with the following introduction.

1. Open Search Console and add your website

Sign in to Google Search Console with a Google account. A Gmail address is not required if you already use another email address for your Google account. Open the property selector and choose Add property to connect a website you manage.

If your account offers several kinds of properties, choose the website option for this tutorial. Before creating another entry, check whether the correct property is already available in the selector. A client or employer may already have verified it and can grant suitable access. Keep business access attached to accounts the organization can maintain, rather than relying solely on a temporary contractor’s account.

Choose a Domain or URL-prefix property

A Domain property, such as example.com, covers its subdomains and protocols. A URL-prefix property, such as https://www.example.com/, covers only URLs that begin with that exact prefix. Use the actual live website address; HTTP, HTTPS, www, and non-www versions are not interchangeable in a URL-prefix property.

For example, a property for https://example.com/blog/ is a section view, not a substitute for the whole website. Confirm where the live homepage and an important article actually load before choosing the scope. Save the property name in your setup notes so future comparisons use the same coverage. Changing the selected property can change the totals without any change to the website itself.

For a complete website overview, a Domain property is useful when you control DNS. For a specific section or when an HTML verification method is easier, a URL-prefix property can be appropriate. You can use both when you need different reporting scopes.

If you keep both a Domain property and a matching URL-prefix property, remember that their reporting coverage overlaps. They are not two independent audiences whose totals should be added together. Choose one consistent scope for a recurring report and use another only when it answers a different question. Adding another property organizes access and reporting; it does not create another copy of the website in Google’s index.

Enter the domain name itself in the Domain field, not a DNS record or a full page URL. Google provides the verification instructions after you continue. Its property setup guide explains the scope of each option.

Check the entry before continuing: a Domain field takes a domain, while a URL-prefix field takes a complete prefix. Do not paste a verification token into either field. If you choose the wrong scope, resolve that setup mistake before interpreting an empty report. Keep the website’s address and redirects unchanged; adding a reporting property is not a reason to migrate from one URL version to another.

2. Verify ownership of the website

Verification proves you are authorized to access the property’s data. Choose a method you can maintain over time. No method is permanent if the verification record, tag, or file is later removed.

Verify a Domain property with DNS

Follow the DNS instructions shown by Search Console at your domain’s DNS provider. Copy the record exactly, save it, and return to verify. DNS updates may need time to propagate. Keep the verification record in place after success so ownership can be checked again.

Make sure you are editing the DNS zone that actually serves the domain, which may not be the company that sold the domain registration. Ask the administrator to add the requested verification record without replacing unrelated mail or website records. If verification is not yet successful, check the displayed record and allow for DNS propagation instead of making repeated, unrelated DNS changes.

Verify a WordPress URL-prefix property with Yoast

Choose the HTML tag method in Search Console. In WordPress, open Yoast SEO, then Settings and Site connections. Paste Google’s verification tag or code into the Google field as directed by Yoast, save the setting, and return to Search Console to click Verify. This is a Search Console verification code, not a Google Analytics measurement ID.

Use the verification value generated for your property, not a code copied from a tutorial screenshot. After saving, confirm that the intended tag is present on the public homepage rather than only in a preview or staging site. Avoid entering the same token through several plugins unnecessarily: it makes later maintenance harder. Keep a short record of which integration stores it so a theme or plugin change does not remove it unnoticed.

If verification fails, check that you entered the correct site version, saved the change, and made the homepage publicly accessible. A cached page may still show the previous HTML. Google’s ownership verification help and Yoast’s connection guide provide method-specific troubleshooting.

Troubleshoot the specific failure message. An HTML tag not found calls for checking the published homepage and cache; a DNS verification failure calls for checking the requested record at the correct provider. Trying a different method is reasonable when your access requires it, but it should be a deliberate choice. Successful verification and successful indexing are separate milestones.

3. Learn the reporting workflow

Start with the Overview for a broad status check, then open the report that answers your current question. Use Performance for search visibility, URL Inspection for a specific page, and Page indexing for groups of URLs. Available reports differ by property and the data Google has collected.

Give each session in the tool one question: ‘Can Google access this page?’, ‘Which searches show it?’, or ‘Is a shared indexing problem increasing?’ Note the property, page, period, and report before drawing a conclusion. This prevents a common beginner mistake: comparing numbers from different scopes or treating a sitewide summary as evidence about one URL.

Use Overview to spot changes

The Overview summarizes selected performance and site health information. Look for unexpected changes and open the relevant detail report rather than trying to diagnose everything from a headline total. New properties may need time before useful data appears, so an empty chart immediately after setup does not by itself prove a fault.

If the view is empty, confirm the property and any active filters first. A newly added property needs time to accumulate useful reporting, while a narrow prefix may simply exclude the pages you expected to see. An indexed page can also have little search visibility. Do not repeatedly change verification settings to solve a performance-data question; establish which stage of the workflow is actually incomplete.

Understand the main performance metrics

In the Search results Performance report, clicks measure interactions that send users to your site, impressions reflect appearances in results, CTR is clicks divided by impressions, and average position summarizes result placement. Position is an aggregate, not a fixed ranking that every searcher sees.

Choose the date range and search type before comparing results. Then use a page or query filter to make the question specific. For example, select one tutorial page and inspect the queries associated with it. This is more informative than comparing a single page’s CTR with the whole site’s average.

Save a baseline before editing a page: the exact URL, selected dates, search type, and relevant query group. Compare equivalent periods and check that your filters have not changed. If the newest data is marked preliminary, avoid treating a partial day as a completed-day decline. An aggregate CTR change may reflect a different mix of queries rather than a worse title.

The dimensions beneath the chart let you explore queries, pages, countries, devices, search appearance, and dates. Not every query is shown, and the newest data may be incomplete. Treat small movements cautiously and compare equivalent periods with consistent filters. See Google’s Performance report documentation for definitions.

Do not expect Search Console clicks to equal GA4 sessions. They describe different stages of the journey and use different collection and reporting rules. Start with compatible dates and landing pages, then investigate attribution or tracking separately. Google’s data-discrepancy guidance also explains why visible query rows may not add up to the chart total. Do not fill those gaps with invented searches.

4. Inspect an individual URL

Paste the complete page URL into the inspection bar. Review the indexing status, crawl information, and canonical details. The initial report describes Google’s known version, which may differ from the page you have just edited.

Check the inspected URL carefully, including its final path. Record the last crawl information and the declared and Google-selected canonical when available. A mismatch can explain why you are looking at the wrong version, but it does not justify changing canonical settings automatically. Use Google’s URL Inspection documentation to interpret the specific result.

Test the live page after fixing a problem

Use Test live URL to check the current page when you have resolved an access or indexing issue. If appropriate, request indexing. This asks Google to revisit the URL; it does not force immediate indexing or guarantee search visibility. Repeating the request is not a substitute for fixing the underlying problem.

A successful live test answers a narrower question than ‘Will this page appear in search?’ It checks the current page for supported accessibility and indexability conditions. It does not predict Google’s eventual canonical choice or guarantee selection for the index. Keep the original report and live-test result distinct when documenting a fix.

5. Read Page indexing and submit a sitemap

The Page indexing report shows indexed and non-indexed URLs, with reasons to investigate. The older Coverage screenshot below uses historical labels. In the current report, focus on whether important canonical pages are indexed and whether unexpected exclusions are increasing.

Start with a small set of important pages rather than trying to eliminate every non-indexed URL. Compare the reported reason with what you intend for each page. A redirected old address and a current service page need different treatment. The report’s URL examples are not an exhaustive inventory; inspect the particular page when its status matters to your next decision.

Decide which indexing issues need a fix

A duplicate URL, a redirected page, or an intentionally noindexed page may be excluded correctly. Investigate unintended exclusions on pages that should appear in search. Google’s Page indexing guidance explains the reasons; avoid treating a 100% indexing rate as the goal.

Submit the actual sitemap URL

Find the sitemap generated by your website or SEO plugin and check that it opens correctly. In Search Console’s Sitemaps report, submit that URL and review its processing status. Keep the sitemap focused on preferred, indexable pages. Submitting it helps discovery but does not guarantee indexing.

Do not guess the sitemap filename or enable several generators just to create one. Open the actual sitemap or index published by your site and check that it lists the intended URL versions. Google’s Sitemaps report guide distinguishes a file that was fetched successfully from one that could not be fetched or contained errors. Open the status details before deciding what to repair.

When many pages change, an accurate sitemap is more practical than repeatedly requesting indexing one URL at a time. Use individual inspection to diagnose a specific page, then fix shared template problems at their source where necessary.

‘Success’ means Google fetched and read the submitted sitemap, not that every listed page entered the index. If one important page remains excluded, inspect that page’s reason rather than repeatedly resubmitting a healthy file. If the file itself cannot be fetched, investigate its availability, format, and selected property. Diagnose the file and the pages as separate parts of the process.

6. Check experience, security, and supported enhancements

Use the reports available for your property to investigate reported problems. Core Web Vitals can highlight groups of URLs with performance issues, while supported enhancement reports describe detected structured data. A clean report does not prove that every aspect of a website is optimized.

Recognize retired reports in older tutorials

The Mobile Usability report and Mobile-Friendly Test were retired in 2023, and the International Targeting report is also retired. Do not search for these old menu items or interpret a Countries filter as a targeting setting. Review mobile layouts directly and use current performance testing tools when diagnosing user experience. Google’s retirement notice confirms the mobile tool change.

Review Security issues and Manual actions separately

Security issues may flag problems such as hacked content or harmful downloads. Manual actions report actions taken after Google’s human review. Read the details and resolve the stated cause; an ordinary traffic decline does not automatically mean your site received a manual action.

7. Review links and manage access

The Links report helps you inspect reported internal and external linking patterns. It is not an exhaustive, real-time backlink database, and a large link total does not by itself demonstrate quality. Use it to investigate context and identify important pages that may need better internal navigation.

For a practical first review, choose an important page and ask whether relevant pages on your own site help readers find it. Examine reported links in context instead of trying to maximize the count. An unfamiliar external link is not, by itself, evidence of a penalty. Keep backlink-risk investigations separate from this initial setup routine.

Keep property access appropriate

In Settings, review ownership and user permissions when team responsibilities change. Grant the access required for the work and keep verification records secure. Removing your access to a property does not remove the website from Google’s search index.

Record who can manage the property and who maintains its verification method. Review access when a contractor leaves, but do not casually remove the only valid ownership token. Ask an authorized administrator to handle ownership and permission changes. Export or share only the reporting information colleagues need, with the property and filters stated so they understand the scope.

Use Search Console alongside a measurable acquisition plan

Once you understand the reports, connect each content or technical change to an intended outcome. If you also run a purchased traffic campaign, define its landing page and success metric separately. Search Console is an SEO diagnostic tool, not a guarantee that a campaign will improve rankings.

If your marketing plan includes a keyword-based visit campaign, keep its budget, destination, and delivery records separate from organic-search evaluation. A campaign’s selected terms are not proof of natural demand or a ranking change. Use the service below for that independent campaign need, not to resolve an ownership, sitemap, or indexing error.

Buy Organic Traffic

If you want to buy organic traffic for a specific page, SEOVisitor’s keyword traffic service lets you select the search terms and destination for your campaign.

Buy Organic Traffic

A practical routine for using Google Search Console

Each week, review meaningful search performance changes and investigate important pages that lost visibility. After publishing or changing a critical page, inspect it when needed. Each month, review indexing patterns, sitemap status, and unresolved issues. Keep notes so the next review starts with evidence instead of guesswork.

For a broader acquisition strategy, combine those findings with useful content distribution, relevant referrals, and retention work. Your next action should follow the problem you have diagnosed, not the desire to improve every number at once.

A hypothetical first-page review

Imagine a small business publishes a service guide and wants to check the setup. This is a hypothetical workflow, not a traffic-growth case study. The owner confirms the correct property, verifies that the guide appears in the actual sitemap, and inspects the complete URL. If an older inspection result differs from the edited page, the owner records both states rather than calling the live test proof of indexing.

Once useful performance data is available, the owner filters to that guide and reviews relevant queries over a consistent period. If a question is missing from the content, it becomes a specific editorial task. If an access problem appears instead, it goes to the site administrator. The output is an assigned action and a planned recheck, not a promise that every metric will rise.

Start with one important page and one report today. A repeatable process is easier to maintain than an occasional audit of every menu.