How to Add Your Website to Google Search Console: A Step-by-Step Guide

What Search Console Is (and Isn't)

Google Search Console is a free tool from Google that shows you how Google sees your website: which pages it has found, which ones it has indexed (stored so they can appear in results), which ones it skipped and why, and which searches people used before clicking through to you.

Two things it is not:

It's not a ranking button. Adding your site doesn't push it higher in results. Google says plainly that adding a property doesn't change how your site appears in Search. What it gives you is visibility into problems that stop pages from showing up at all, and a way to tell Google about new pages faster.
It's not Google Analytics. Analytics tells you what visitors do once they're on your site. Search Console tells you what happens before they arrive: impressions, clicks, and the search terms that brought them. Most businesses benefit from both.

If you've just launched a new website in Kuwait and wonder why searching your business name doesn't bring it up yet, Search Console is the first place to look.

Before You Start

The site must be live on its real domain, not a staging or preview address.
Use HTTPS. Decide whether your main address is https://www.yoursite.com or https://yoursite.com, and make sure the other one redirects to it.
Check that nothing blocks Google. A noindex tag left over from development, or a robots.txt file that disallows the whole site, will stop indexing no matter what you do in Search Console. This is one of the most common reasons a new site doesn't appear.
Use a Google account the business controls. Ideally a company account, not a developer's or agency's personal email. You can add your developer as a user later, but the business should be the owner.
Know who manages your domain's DNS. You'll likely need to add one record there. That's usually your domain registrar or hosting provider.

Step 1: Choose a Property Type

Go to search.google.com/search-console, sign in, and click Add property. Google offers two kinds of website property:

Domain property (for example, yoursite.com). This covers everything under the domain: www and non-www, http and https, and every subdomain. It's the most complete view, and it's what we recommend for most businesses. The only catch is that it must be verified through DNS.
URL-prefix property (for example, https://www.yoursite.com/). This covers only addresses that start with that exact prefix, including the protocol. http:// or a different subdomain would each need their own property. It's useful when you can't edit DNS, or when you only want to track one section of a site.

You can have both. Some teams add a Domain property for the full picture and a URL-prefix property for a specific section, such as /ar/, to filter reports more easily.

Step 2: Verify You Own the Site

Google needs proof you control the site before it shows you any data.

For a Domain property: DNS TXT record. Search Console gives you a line of text that starts with google-site-verification=. Copy it, log in to wherever your domain's DNS is managed, and add a new TXT record containing that value. For the host or name field, use @ or leave it blank, depending on the provider. Then return to Search Console and click Verify. Some providers support an automatic connection that adds the record for you.

DNS changes can take time to spread. If verification fails right away, wait a while and try again before assuming something is wrong. You can also click "Verify later" and finish from the property list.

For a URL-prefix property, you have more options:

HTML file upload: download a small file from Google and place it in your site's root folder.
HTML meta tag: add a <meta name="google-site-verification"> tag to your homepage's <head>.
Google Analytics or Google Tag Manager: if either is already installed on the site under the same Google account, verification can be almost instant.

Leave the verification in place. Don't delete the TXT record, file, or tag after verifying. Google checks again from time to time, and removing it can cost you access.

Step 3: Submit Your Sitemap

A sitemap is a file, usually at yoursite.com/sitemap.xml, that lists the pages you want Google to know about. Google calls it one of the main ways it discovers URLs on a site. Most modern websites and platforms generate one automatically. If yours doesn't, ask your developer.

To submit it, open Sitemaps in the left menu of Search Console, enter the sitemap's address, and click Submit. The report then shows when Google last read the file, how many URLs it found, and any errors.

A few things worth knowing:

Also list it in robots.txt. Adding a line such as Sitemap: https://yoursite.com/sitemap.xml to your robots.txt file helps Google and other search engines find it without being told.
Only list real, final pages. Leave out redirects, error pages, and anything marked noindex. A sitemap full of dead links makes the whole file less trustworthy.
Keep lastmod honest. Google ignores the priority and changefreq fields. It uses the lastmod date only when it's consistently accurate, meaning it changes when the page's content actually changes, not on every deployment.
Size limits: one sitemap can hold up to 50,000 URLs or 50 MB uncompressed. Larger sites split it into several files with a sitemap index.

Submitting a sitemap is a hint, not a command. Google doesn't promise to crawl every URL in it. For most small and medium business sites, though, it's the single most useful thing you can do on day one.

Step 4: Request Indexing for Key Pages

For a handful of important pages, such as your homepage, main service pages, or a new article, you can ask Google directly to crawl them:

Paste the full page address into the search bar at the top of Search Console. That opens the URL Inspection tool.
It tells you whether the page is already on Google. If not, click Test live URL to check that Google can actually reach and render the page right now.
If the test passes, click Request indexing.

Set your expectations:

Crawling can take anywhere from a few days to a few weeks.
There's a daily limit on individual requests, so save it for pages that matter. Use the sitemap for everything else.
Requesting the same page again and again doesn't speed anything up.
A crawl isn't a guarantee. Google still decides whether a page is worth showing in results.

Arabic + English Sites: Make Sure Google Sees Both

This is where many Kuwait websites lose half their search traffic without knowing it. If your site switches between Arabic and English using a button that sets a cookie, while the address stays the same, Google will usually only ever see one language. Googlebot doesn't click your language switcher. It just loads each address.

For both languages to show up in search:

Give each language its own URL, for example /services and /ar/services.
Connect the two versions with hreflang, either in each page's <head> or in the sitemap. This tells Google they are translations of each other, so Arabic searchers get the Arabic page and English searchers get the English one.
Include both versions in your sitemap.
Then check in Search Console that Arabic pages actually appear as indexed. Inspect one with URL Inspection to confirm.

Getting the design side right matters too. Our guide on designing for Arabic + English covers layout and direction. For a large share of Kuwait search users, though, an Arabic page Google can't find might as well not exist.

What to Check in the First Few Weeks

Google starts collecting data as soon as the property is added, and it usually appears within a few days. These are the reports worth opening:

Page indexing. Shows how many pages are indexed and, more usefully, why others aren't. Common reasons include "Excluded by 'noindex' tag", "Page with redirect", "Not found (404)", "Discovered - currently not indexed" (Google knows about the page but hasn't crawled it yet), and "Crawled - currently not indexed" (Google looked and chose not to include it yet, which is often a sign the page is thin or too similar to another).
Performance. Shows the searches you appeared for, along with impressions, clicks, click-through rate, and average position. This is where you find out what people actually type to find you, which is often different from what you assumed.
Core Web Vitals and HTTPS. These flag pages that load slowly, shift around while loading, or aren't served securely. Our post on website performance and security explains what affects these.
Email alerts. Search Console emails the owner when it spots serious problems, which is another reason the account should belong to someone at the business who actually reads that inbox.

Once you're set up, adding your site to Bing Webmaster Tools only takes a few minutes, because it can import your verified sites directly from Search Console.

Common Mistakes We See

Wrong version of the address. A URL-prefix property for http:// when the site runs on https://, or for non-www when the site uses www, shows almost no data. A Domain property avoids this entirely.
A noindex left over from development. Fine on a staging site, a disaster on launch day. URL Inspection will tell you if a page is excluded by noindex.
The developer owns the account. When the relationship ends, the business loses its search history. Keep the business as owner, and give agencies and developers "Full" user access instead.
Sitemaps full of redirects or 404s, often from old pages after a redesign.
Treating it as a one-time task. The real value comes from checking it monthly: new indexing problems, which pages are gaining clicks, and which searches you're close to ranking for.

Where to Start

If your site is already live, you can do steps 1 to 4 yourself in under an hour: add a Domain property, verify it through DNS, submit your sitemap, and request indexing for your homepage and main service pages. Then come back in a week and look at the Page indexing report.

If the reports turn up problems you can't easily fix, such as pages excluded for unclear reasons, Arabic pages that never get indexed, or a sitemap your platform can't generate properly, the cause is usually in how the site itself is built. That's something we handle as part of every website we deliver. See our website and web application services, or read what a good maintenance plan should include.