# QueryWatch — full text > The complete text of https://querywatch.app: what the app is, what it costs, the questions people ask, and every article on the blog. A shorter index is at https://querywatch.app/llms.txt. ## Key facts - QueryWatch (store name "QueryWatch: Search Console App") is an independent, native Google Search Console app for iPhone and Android, made by Melih Toksari. - QueryWatch is available on the App Store and Google Play. App Store: https://apps.apple.com/app/querywatch-search-console-app/id6811357323. Google Play: https://play.google.com/store/apps/details?id=com.empath.querywatch. - It requires iOS 26 or later on iPhone, or Android 12 or later on Android. The iPhone app is written in Swift and SwiftUI; the Android app in Kotlin and Jetpack Compose. - Google has never released an official Search Console app for iPhone or Android; every Search Console app in the stores is a third-party client of Google’s public Search Console API. - The free tier lists every Search Console property the signed-in Google account can access, with no site limit, and shows real data on each: clicks, impressions, CTR and average position, top 100 queries and pages, country and device splits, a striking-distance view (positions 8–20), change investigation (top 3 contributors), a 5-item watchlist, widgets, 5 URL inspections a day, the sitemap list, CSV export and Demo Mode. - QueryWatch Pro costs $4.99 a month or $14.99 a year. New subscribers can start the yearly plan with a first month for $0.99, and it renews at $14.99 a year after that. There is no free trial, no weekly plan and no lifetime purchase, and the price never depends on the number of sites. - Pro adds push alerts (traffic drops and spikes, a new query entering the top 10, watched-URL indexing changes, sitemap errors), a Monday weekly digest, 16 months of history with custom ranges and period comparison, the top 20 contributors to any change, an unlimited watchlist, multiple Google accounts, unlimited URL inspections, Core Web Vitals per page, sitemap submit and delete, comparison CSV, branded or white-label PDF reports, and a cannibalisation detector. - Alerts are computed by the developer’s own relay server in Germany every six hours. The anomaly rule compares the latest complete day with the same weekday over the previous four weeks and fires at a 30 percent change or two standard deviations, both adjustable per property, with at most one notification per property per day. Each alert stores an evidence snapshot of what it saw. - Sign-in uses Google’s own sign-in sheet with read-only scopes (openid, userinfo.email, webmasters.readonly); the write scope is requested only when a Pro user submits or deletes a sitemap. On iPhone the refresh token stays in the Keychain; on Android, Google Play services hold the grant and the app never receives a refresh token. A credential leaves the phone only if push alerts are turned on. - QueryWatch is not a rank tracker and never scrapes search results; positions are the averages Google reports in Search Console. It does not show Google Analytics 4 or Bing Webmaster Tools data; Bing Webmaster Tools is on the roadmap. - Demo Mode runs the whole app, including Pro screens, on four sample properties without signing in. - Support: hello@querywatch.app. QueryWatch is not affiliated with, endorsed by, or sponsored by Google LLC. ## Free and Pro | Feature | Free | Pro | |---|---|---| | Properties | All of them, no cap | All of them, no cap | | Performance data | 7, 28 and 90-day presets with deltas | 16 months, custom ranges, period comparison | | Queries, pages, countries, devices | Top 100 rows | Top 100 rows | | Striking distance (positions 8–20) | Included | Included | | Change investigation | Top 3 contributors | Top 20 contributors, kept as history | | Push alerts on traffic change | Not included | Anomaly, new top-10 query, indexing change, sitemap error | | Weekly digest | Not included | Every Monday, per property | | Watchlist | 5 saves | Unlimited | | Client tags and colours | Included | Included | | Widgets | Home Screen and Lock Screen on iPhone, home screen on Android | Home Screen and Lock Screen on iPhone, home screen on Android | | URL inspection | 5 per day | Unlimited | | Sitemaps | View | View, submit and delete | | Core Web Vitals / PageSpeed | Not included | Per page | | Exports | CSV of the current view | Comparison CSV and branded or white-label PDF | | Cannibalization detector | Not included | Included | | Multiple Google accounts | Not included | Included | | Offline cache and Demo Mode | Included | Included | ## Questions and answers ### About the app **Where can I download QueryWatch?** QueryWatch is on the App Store for iPhone (iOS 26 or later) and on Google Play for Android (Android 12 or later), listed as “QueryWatch: Search Console App”. It is free to download, and every Search Console property you have is free to view. **Is there an official Google Search Console app?** No. Google has never released a Search Console mobile app for iPhone or Android. It tested an Android progressive web app with a small group of SEOs in March 2024 and never shipped it. The mobile web interface at search.google.com works on a phone, but it is a desktop tool in a small window: no push notifications, no home-screen widgets, and slow switching between properties. **Do I have to pay to see all of my properties?** No. Every property you have access to in Search Console is listed on the free tier, with no cap on the number of sites, and the free tier shows real data rather than a teaser. We charge for depth, not for the number of sites: 16 months of history, push alerts, unlimited watchlist saves, exports and a few other things sit in Pro. **What does Pro cost?** Pro is $4.99 per month or $14.99 per year. New subscribers can start the yearly plan with a first month for $0.99, and it renews at $14.99 a year after that. There is no weekly plan and no free trial. Payment is handled by Apple or Google Play through your store account, and you can cancel any time from your phone’s subscription settings. **Does QueryWatch store my Google account token?** Not by default. On iPhone your refresh token is kept in the Keychain; on Android, Google Play services hold the grant and the app never receives a refresh token. Either way the app talks to Google directly from your device. Push alerts are the one exception, because something has to check Search Console while your phone is asleep. Turning alerts on gives our relay a credential of its own — our own server in Germany, not a third-party backend service — encrypted at rest, and turning them off deletes it immediately. The app says this before you enable anything. **Is QueryWatch made by Google?** No. QueryWatch is an independent app and is not affiliated with, endorsed by, or sponsored by Google LLC. It uses Google’s public Search Console API with your permission, and Google Search Console is a trademark of Google LLC. **Does it track my keyword rankings?** No, and it never will. QueryWatch shows the average position Google itself reports in Search Console for queries your site actually appeared for. Scraping search results to build a rank tracker breaks Google’s terms of service, so it is a permanent non-goal for this app. If you need daily SERP positions for keywords you do not yet rank for, you need a rank tracker, not this. **Why is my data two or three days behind?** That is Google’s delay, not ours. Search Console performance data is finalised a couple of days after the fact, for everyone, in the API and in Google’s own interface alike. QueryWatch always labels the last complete day it is showing you rather than quietly presenting a partial day as a full one. **Can I try it without connecting my Google account?** Yes. Demo Mode runs the whole app on a bundled sample dataset for four example properties, including the Pro screens, with no sign-in and a permanent banner so you always know the numbers are not yours. ### Alerts **How often does QueryWatch check my properties?** Every six hours. Search Console data is finalised two to three days after the fact, so checking more often would only produce noise from partial days — the relay compares the latest complete day, not today. **What counts as a big enough change to notify me?** By default, a day whose clicks or impressions are at least 30 percent away from the same weekday over the previous four weeks, or at least two standard deviations from it. Both thresholds are adjustable per property, so a volatile site and a steady one can have different rules. **Will it wake me up every time a number wobbles?** No. There is a hard cap of one notification per property per day, and each day is compared with the same weekday in the previous four weeks rather than with yesterday, so ordinary weekday-to-weekend movement does not trigger anything. **Does Search Console not already email me?** It emails you about critical issues — manual actions, security problems, big coverage changes. It does not email you because Tuesday’s clicks fell 40 percent, which is the thing that usually matters first commercially. **Why does enabling alerts send my token to a server?** Because a notification has to be computed while your phone is closed, and a phone cannot reliably run a background job every six hours. The check has to happen somewhere else, which means something else needs permission to read your data. The token is encrypted at rest, decrypted only inside the scheduled function, and deleted the moment you turn alerts off. With alerts off it never leaves your device at all. ### For agencies **Do I pay more for more client properties?** No. Pricing is per person, not per property — $4.99 a month or $14.99 a year covers every property you have access to, whether that is three or thirty. This is deliberate. Every other app in the category either charges by site count or hides properties behind the paywall, and that is the wrong shape for agency work. **Can my client log in and see their own data?** Not yet. Read-only client sharing is on the roadmap but is not in the app today. What exists now is the export: a branded or white-label PDF, and CSV of any view. **Can I put my own branding on a report?** Yes, on Pro. A report carries the client name, your logo and your colour, and the white-label option removes QueryWatch branding entirely so what lands in the client’s inbox is yours. **Does it support more than one Google account?** Yes, on Pro. Agencies routinely have properties split across a personal account and one or more client-granted accounts, so multi-account switching is a Pro feature rather than an edge case. ### Support **Where do I download it?** Search the App Store or Google Play for “QueryWatch: Search Console App”, or use the store links at the top of querywatch.app. It is free to download on both. **Which devices does it run on?** iPhone running iOS 26 or later, and Android phones running Android 12 or later. Both are native apps — Swift and SwiftUI on iPhone, Kotlin and Jetpack Compose on Android — rather than a website in a wrapper. There is no iPad or Mac layout yet. **How do the alerts decide something is worth a notification?** The relay checks your properties every six hours and compares the latest complete day with the same weekday over the previous four weeks. An alert fires when the change is at least 30 percent, or at least two standard deviations from that baseline — both thresholds are adjustable per property. You get at most one notification per property per day, and each alert carries the numbers that triggered it so it still makes sense when you read it later. **I signed in and no properties appeared.** QueryWatch can only see properties that are verified in Search Console under the Google account you signed in with. If a client added you to a property, check you signed in with the same account they invited. If the list is genuinely empty in Search Console on the web too, there is nothing to show yet — verify a property there first. **Can I connect more than one Google account?** Yes, with Pro. Multi-account switching is a Pro feature; the free tier signs in with one Google account at a time. **How do I delete everything?** In the app: Settings, then Privacy and data, then Delete all my data. Without the app: revoke access at myaccount.google.com/permissions and email us to remove any relay row. Full instructions, including what exists in the first place, are on the delete-my-data page. **How do I cancel or get a refund?** On iPhone: Settings, your name, Subscriptions, QueryWatch, Cancel subscription. On Android: Google Play, your profile, Payments & subscriptions, Subscriptions. Refunds are issued by Apple at reportaproblem.apple.com or by Google through Google Play, because the store takes the payment and we never see it. Email us anyway if something went wrong — we can usually help you make the case. **Something is broken or a number looks wrong.** Email us with the property, the date range and the screen you were on, and a screenshot if you have one. Please do not send tokens or passwords — we never need them. ## Articles ### How much does a Google Search Console app cost? URL: https://querywatch.app/blog/how-much-does-a-google-search-console-app-cost/ Published: 26 October 2026 Summary: QueryWatch is free for every property with no site limit. Pro is $4.99 a month or a yearly plan, and the price never depends on how many sites you add. QueryWatch, an independent Google Search Console app for iPhone and Android, is free for every property with no site limit. QueryWatch Pro costs $4.99 a month or a yearly plan, and the price never depends on the number of sites. Google itself has never released an official Search Console app, so every app in the stores is a third-party client. ## What do you get for nothing? The free tier lists every Search Console property the signed-in Google account can access and shows real data on each: clicks, impressions, CTR and average position, the top 100 queries and pages, country and device splits, a striking-distance view (positions 8 to 20), change investigation, a 5-item watchlist, widgets, 5 URL inspections a day, the sitemap list, CSV export and Demo Mode. ## What does Pro add? | Feature | Free | Pro | |---|---|---| | Every property, no site limit | Yes | Yes | | Push alerts (drops, spikes, new top-10 queries, sitemap errors) | No | Yes | | Monday weekly digest | No | Yes | | History | Standard range | 16 months, custom ranges, period comparison | | URL inspections | 5 a day | Unlimited | | Watchlist | 5 items | Unlimited | | Branded or white-label PDF reports | No | Yes | ## How is Pro billed? $4.99 a month, or a yearly plan. New subscribers can start the yearly plan with a first month at an introductory price, and it renews at the yearly price after that. There is no free trial, no weekly plan and no lifetime purchase. Our post on [why we never cap properties](/blog/free-vs-pro-why-we-never-cap-properties/) explains the reasoning. ## Can I look before I pay? Yes. Demo Mode runs the whole app, including Pro screens, on four sample properties without signing in. See [try a Search Console app without connecting Google](/blog/try-a-search-console-app-without-connecting-google/). Prices of other apps change often, so check the store listings; our [comparison pages](/vs/) show the date each was last checked. For the full feature list, see the [product page](/google-search-console-app/). QueryWatch is independent and not affiliated with Google. Questions: **Is there a free Google Search Console app?** Yes. QueryWatch's free tier lists every property your Google account can access, with no site limit, and shows real data on each. **How much is QueryWatch Pro?** $4.99 a month or the yearly price shown in the store. New subscribers can start the yearly plan with an introductory first month, then it renews yearly. **Does the price change with the number of sites?** No. The price never depends on the number of sites, on either tier. **Is there a free trial or lifetime purchase?** No. There is no free trial, no weekly plan and no lifetime purchase. The free tier stays free and Demo Mode needs no sign-in. --- ### Is it safe to connect Search Console to a mobile app? URL: https://querywatch.app/blog/is-it-safe-to-connect-google-search-console-to-a-mobile-app/ Published: 26 October 2026 Summary: QueryWatch signs in with Google's own sheet and read-only scopes. Here is what it can access, where the token lives, and what leaves your phone. Connecting a Search Console app means granting it access to your Google account's Search Console data. QueryWatch uses Google's own sign-in sheet with read-only scopes, so it can read your reports but not change your properties. On iPhone the refresh token stays in the Keychain, and a credential leaves the phone only if you turn on push alerts. ## What can QueryWatch access? | Scope | What it allows | When it is asked for | |---|---|---| | openid, userinfo.email | Identify which Google account signed in | At sign-in | | webmasters.readonly | Read Search Console data | At sign-in | | Write scope | Submit or delete a sitemap | Only when a Pro user does that | ## Where does the token live? On iPhone the refresh token stays in the Keychain. On Android, Google Play services hold the grant and the app never receives a refresh token. For more detail, read [where your Google token goes](/blog/where-does-your-google-token-go/). ## What changes if I turn on alerts? Alerts are computed by the developer's own relay server in Germany every six hours. For that to work a credential leaves the phone, which is why alerts are opt-in. The rule compares the latest complete day with the same weekday over the previous four weeks, fires at a 30 percent change or two standard deviations, and sends at most one notification per property per day. Each alert stores an evidence snapshot of what it saw. ## How can I check before signing in? Demo Mode runs the whole app, including Pro screens, on four sample properties without signing in. You can also remove access at any time from your Google account's connected-apps page, and the [delete my data](/delete-my-data/) page explains how to ask for stored data to be removed. Support is at the address listed on the [support page](/support/). For the full feature list, see the [product page](/google-search-console-app/). QueryWatch is independent and not affiliated with Google. Questions: **What permissions does QueryWatch ask for?** Read-only scopes: openid, userinfo.email and webmasters.readonly. The write scope is requested only when a Pro user submits or deletes a sitemap. **Where is my Google token stored?** On iPhone the refresh token stays in the Keychain. On Android, Google Play services hold the grant and the app never receives a refresh token. **Does anything leave my phone?** A credential leaves the phone only if push alerts are turned on. Alerts are computed by the developer's own relay server in Germany. **Can I try it without signing in?** Yes. Demo Mode runs the whole app on four sample properties without signing in. --- ### Can ChatGPT or Claude alert me when my Search Console traffic drops? URL: https://querywatch.app/blog/can-chatgpt-or-claude-alert-me-when-search-console-traffic-drops/ Published: 25 October 2026 Summary: A chat assistant answers when you ask; it does not watch a site between questions. QueryWatch Pro pushes an alert to your phone when clicks move 30 percent. If you want a phone notification when Search Console traffic drops, an AI chat assistant is the wrong tool on its own: it answers when you ask and does not watch your site between questions. QueryWatch Pro does the watching. Its relay server checks every six hours and sends at most one push per property per day when clicks or impressions move by 30 percent or two standard deviations. ## What is the difference between asking and being told? | | Chat assistant | QueryWatch Pro alert | |---|---|---| | Starts when | You send a message | A rule fires on its own | | Data it looks at | What you paste or export | Your Search Console properties, read through Google's API | | Reaches your phone | Only inside the chat | As a push notification | | Comparison used | Whatever you ask for | Latest complete day against the same weekday over the previous four weeks | ## What is an assistant still good for? Once an alert tells you something moved, an assistant is a useful second pair of eyes. Export the queries or pages from Search Console, paste them in, and ask what changed. Our posts on [what ChatGPT or Claude can read from Search Console](/blog/can-chatgpt-or-claude-read-search-console-data/) and [prompts for Search Console exports](/blog/chatgpt-prompts-for-search-console-exports/) cover that workflow. ## How does a QueryWatch alert decide to fire? The rule compares the latest complete day with the same weekday over the previous four weeks. It fires at a 30 percent change or two standard deviations, and you can adjust both per property. Each alert stores an evidence snapshot of what the server saw, and the app shows the top contributors to the change. Because Search Console data arrives days late, read [why Search Console data is days behind](/blog/why-search-console-data-is-days-behind/) before reacting to a single day. ## What does it cost? Alerts are in QueryWatch Pro at $4.99 a month or $14.99 a year. The free tier lists every property your Google account can access, with no site limit. Credentials leave the phone only if you turn push alerts on. For the setup steps, see [get an alert when Google traffic drops](/blog/get-an-alert-when-google-traffic-drops/). QueryWatch is independent and not affiliated with Google. Questions: **Can ChatGPT or Claude notify me when my traffic drops?** A chat assistant replies when you send it a message. It has no way to check your Search Console data on a schedule and push a notification to your phone on its own. **What does QueryWatch use to decide that traffic dropped?** It compares the latest complete day with the same weekday over the previous four weeks and fires at a 30 percent change or two standard deviations, both adjustable per property. **How often are alerts checked?** The developer's relay server in Germany computes alerts every six hours, with at most one notification per property per day. **Are push alerts free?** No. Push alerts are part of QueryWatch Pro, which costs $4.99 a month or $14.99 a year. The free tier lists every property with real data. --- ### Does a Search Console app show Google Analytics 4 data? URL: https://querywatch.app/blog/does-a-search-console-app-show-google-analytics-data/ Published: 25 October 2026 Summary: QueryWatch shows Search Console data only: clicks, impressions, CTR and position. It does not show GA4 sessions or Bing data. Here is what to use for each. No. QueryWatch is a Google Search Console app, so it shows Search Console data only: clicks, impressions, CTR and average position. It does not show Google Analytics 4 sessions, conversions or Bing Webmaster Tools data. Bing Webmaster Tools is on the roadmap. If you need on-site behaviour, keep GA4 open alongside it. ## Which tool answers which question? | Question | Where to look | |---|---| | How many people clicked my result in Google Search? | Search Console, and so QueryWatch | | Which queries and pages earn impressions? | Search Console, and so QueryWatch | | What did visitors do after landing? | Google Analytics 4 | | Where do I rank for one fixed keyword each day? | A dedicated rank tracker; QueryWatch is not one | ## What does QueryWatch show on the free tier? Every property your Google account can access, with no site limit: clicks, impressions, CTR and average position, top 100 queries and pages, country and device splits, a striking-distance view (positions 8 to 20), change investigation, widgets, 5 URL inspections a day, the sitemap list, CSV export and Demo Mode. Pro adds alerts, 16 months of history and PDF reports. ## Why will the numbers never match GA4? Search Console counts clicks on Google Search results; GA4 counts sessions recorded by a tag on your pages. Consent banners, blocked scripts and other traffic sources all push the two apart. Our post on [Search Console vs Google Analytics 4](/blog/search-console-vs-google-analytics-4/) explains the differences in detail. ## Can I try it without connecting Google? Yes. Demo Mode runs the whole app, including Pro screens, on four sample properties without signing in. Read [try a Search Console app without connecting Google](/blog/try-a-search-console-app-without-connecting-google/) for what it shows. For the full tier list, see the [product page](/google-search-console-app/). QueryWatch is independent and not affiliated with Google. Questions: **Does QueryWatch show Google Analytics 4 data?** No. QueryWatch reads Google Search Console only. It does not show Google Analytics 4 or Bing Webmaster Tools data; Bing Webmaster Tools is on the roadmap. **What data does QueryWatch show?** Clicks, impressions, CTR and average position, the top 100 queries and pages, country and device splits, a striking-distance view and change investigation. **Why do Search Console clicks differ from GA4 sessions?** They measure different things: clicks are counted by Google Search on its results pages, while sessions are counted by the analytics tag on your site. **Is QueryWatch a rank tracker?** No. It never scrapes search results. Positions are the averages Google reports in Search Console. --- ### Will a Search Console alert app send too many notifications? URL: https://querywatch.app/blog/will-a-search-console-alert-app-send-too-many-notifications/ Published: 24 October 2026 Summary: How often QueryWatch can notify you: one push per property per day at most, checks every six hours, adjustable thresholds, and evidence saved with each alert. An alert app is only useful if you keep notifications switched on, so frequency matters. QueryWatch sends at most one push notification per property per day, checks every six hours, and fires only when the latest complete day moves by 30 percent or two standard deviations against the same weekday over the previous four weeks. Both limits can be adjusted per property. ## What decides whether an alert fires? | Setting | How QueryWatch handles it | |---|---| | Comparison | Latest complete day against the same weekday over the previous four weeks | | Default trigger | A 30 percent change or two standard deviations | | Adjustable | Yes, per property | | Check frequency | Every six hours, on the developer's relay server in Germany | | Daily cap | At most one notification per property per day | | Evidence | Each alert stores a snapshot of what it saw | Comparing a Sunday with other Sundays is deliberate: weekly rhythm is the most common reason a daily number looks like a drop when it is not. The longer reasoning is in [anatomy of a traffic alert](/blog/anatomy-of-a-traffic-alert/). ## Which events can send a push? Pro alerts cover traffic drops and spikes, a new query entering the top 10, watched-URL indexing changes and sitemap errors. All of them share the same daily cap per property, so a busy day on one site produces one notification rather than a stack of them. ## What if I manage many sites? The cap applies per property, not per account. Someone watching 20 client sites can receive up to one push for each of them in a day, and only for the sites whose numbers moved. If that is still too many, raise the thresholds on the quieter properties. For that workflow, see [managing client properties](/blog/managing-client-properties-search-console/). ## How do I judge an alert once it arrives? Open it and read the saved evidence rather than the headline number. The app can then break the change down into its top contributing pages and queries. If the cause is a Google update rather than your site, [did a core update hit my site](/blog/did-a-google-core-update-hit-my-site/) walks through the check. ## What does it cost? Alerts are a Pro feature at $4.99 a month or $14.99 a year, and the price never depends on how many sites you watch. The free tier lists every property with real data, so you can judge the data before deciding. Details are on the [alerts page](/search-console-alerts/). QueryWatch is independent and not affiliated with Google. Questions: **How many notifications can QueryWatch send per site?** At most one per property per day. If several things move on the same property, they are not sent as separate pushes. **How often does QueryWatch check for changes?** The developer's relay server in Germany computes alerts every six hours. **Can I change when an alert fires?** Yes. The default rule fires at a 30 percent change or two standard deviations, and both values are adjustable per property. **Are alerts free?** No. Push alerts are part of QueryWatch Pro, which costs $4.99 a month or $14.99 a year. The free tier shows every property without an alert feature. --- ### Can I try a Search Console app without connecting my Google account? URL: https://querywatch.app/blog/try-a-search-console-app-without-connecting-google/ Published: 24 October 2026 Summary: QueryWatch has a Demo Mode that runs the whole app, Pro screens included, on four sample properties with no sign-in. What it shows and what it cannot. Yes. QueryWatch has a Demo Mode that runs the whole app, including the Pro screens, on four sample properties without signing in to Google. It is the quickest way to look at the layout, the change investigation and the alert screens before deciding whether to connect a real account. ## What does Demo Mode include? | Part of the app | In Demo Mode | |---|---| | Properties | Four sample properties | | Google sign-in | Not required | | Pro screens | Visible, so you can see what they do | | Your own data | Not shown | Any figures you see in the demo, such as a sample site's drop or a page's share of a change, are demo numbers, not results from a real property. ## What changes when I connect a real account? Sign-in uses Google's own sign-in sheet with read-only scopes: openid, userinfo.email and webmasters.readonly. The free tier then lists every property your account can access, with no site limit, and shows clicks, impressions, CTR and average position, top queries and pages, and a striking-distance view. The write scope is asked for only if a Pro user submits or deletes a sitemap. ## Where does the credential live? On iPhone the refresh token stays in the Keychain. On Android, Google Play services hold the grant and the app never receives a refresh token. A credential leaves the phone only if you turn on push alerts, which are a Pro feature. The full explanation is in [where does your Google token go](/blog/where-does-your-google-token-go/), and [how Search Console apps get your data](/blog/how-do-search-console-apps-get-your-data/) covers the permissions. ## Who is it useful for? Anyone who wants to check an app before granting access to client sites, such as freelancers and agencies, can open the demo first and read the privacy notes second. If you then connect, you can compare it with the alternatives in [Search Console apps compared](/blog/search-console-apps-compared/). ## Where do I get it? Both store links are on the [product page](/google-search-console-app/). QueryWatch requires iOS 26 or later on iPhone, or Android 12 or later on Android, and is not affiliated with Google. Questions: **Can I use QueryWatch without signing in to Google?** Yes, in Demo Mode. It runs the whole app, including Pro screens, on four sample properties without signing in. **Is the data in Demo Mode real?** No. It is sample data for four made-up properties, so you can see every screen but not your own numbers. **What permissions does real sign-in request?** Google's own sign-in sheet with read-only scopes: openid, userinfo.email and webmasters.readonly. The write scope is requested only when a Pro user submits or deletes a sitemap. **Where does my Google credential go after I sign in?** On iPhone the refresh token stays in the Keychain. On Android, Google Play services hold the grant and the app never receives a refresh token. A credential leaves the phone only if you turn on push alerts. --- ### How do Search Console apps get your data? URL: https://querywatch.app/blog/how-do-search-console-apps-get-your-data/ Published: 23 October 2026 Summary: Search Console apps read your data through Google's public API after you sign in with Google. What they can read, what stays on the phone, and what to check. A Search Console app signs you in with Google, then asks Google's public Search Console API for the same numbers you see in the website: clicks, impressions, CTR and average position. It can only read properties your Google account already has access to. Google has never released an official Search Console app, so every app in the stores works this way. ## What happens when you sign in? You see Google's own sign-in sheet and approve a list of permissions. After that, the app can request reports for the properties your account can open. The app does not get your Google password. | Step | What happens | |---|---| | Sign in | Google's sign-in sheet shows the permissions requested | | Approve | You grant read-only access to Search Console data | | Fetch | The app calls the Search Console API for each property | | Show | Numbers appear in the app, with the same delay as the website | ## Which permissions should you expect? Read-only scopes are enough to show performance data. QueryWatch requests openid, userinfo.email and webmasters.readonly. The write scope is requested only when a Pro user submits or deletes a sitemap. If any app asks for more than it needs to display reports, ask why before approving. ## Where does the credential live? It depends on the platform. In QueryWatch on iPhone the refresh token stays in the Keychain. On Android, Google Play services hold the grant and the app never receives a refresh token. A credential leaves the phone only if push alerts are turned on, because alerts are computed on the developer's own relay server in Germany every six hours. For the longer explanation see [where does your Google token go](/blog/where-does-your-google-token-go/). ## Does an app show different numbers from the website? It should not, because both read Search Console data. The data still lags by a couple of days; read [why Search Console data is days behind](/blog/why-search-console-data-is-days-behind/). Exports and API calls are also limited in rows, covered in [row limits and anonymised queries](/blog/search-console-row-limits-and-anonymized-queries/). ## How can you check an app before signing in? Read the store listing for the permissions and price, find a privacy page that names where data goes, and use a demo mode if one exists. QueryWatch, which publishes this page, has a Demo Mode that runs the whole app on four sample properties without signing in. Store links are on the [product page](/google-search-console-app/). QueryWatch is independent and not affiliated with Google. Questions: **Is there an official Google Search Console app?** No. Google has never released an official Search Console app for iPhone or Android. Every Search Console app in the stores is a third-party client of Google's public Search Console API. **What permission does a Search Console app need?** Read-only access to Search Console data. QueryWatch asks for openid, userinfo.email and webmasters.readonly, and requests the write scope only when a Pro user submits or deletes a sitemap. **Can an app see data for sites I do not own?** Only properties your signed-in Google account can already access. An app cannot add access that your account does not have in Search Console. **Where does QueryWatch keep my Google credential?** On iPhone the refresh token stays in the Keychain. On Android, Google Play services hold the grant and the app never receives a refresh token. A credential leaves the phone only if push alerts are turned on. --- ### Is the Search Console app the same on iPhone and Android? URL: https://querywatch.app/blog/search-console-app-iphone-vs-android-differences/ Published: 23 October 2026 Summary: How QueryWatch differs on iPhone and Android: requirements, how each app is built, where the Google credential is kept, and which widgets each platform has. QueryWatch is one product with two native apps. The tiers, prices and alert rules are the same on iPhone and Android; the differences are the minimum operating system, how each app is built, where the Google credential is held, and the widgets. The free tier lists every property your Google account can access on either platform. ## What differs between the two apps? | Item | iPhone | Android | |---|---|---| | Minimum version | iOS 26 | Android 12 | | Built with | Swift and SwiftUI | Kotlin and Jetpack Compose | | Google credential | Refresh token in the Keychain | Google Play services hold the grant; the app never receives a refresh token | | Widgets | Home Screen and Lock Screen | Home screen | | Tiers and prices | Free and Pro | Free and Pro, same prices | ## What is identical? The free tier shows clicks, impressions, CTR and average position, top 100 queries and pages, country and device splits, a striking-distance view, change investigation, a watchlist, 5 URL inspections a day, the sitemap list, CSV export and Demo Mode. Pro adds push alerts, a Monday digest, 16 months of history, PDF reports and more. Alerts use the same rule on both: the latest complete day against the same weekday over the previous four weeks, firing at a 30 percent change or two standard deviations, with at most one notification per property per day. ## Which one suits which person? Choose by the phone you carry. A freelancer on Android and a client on iPhone can each look at the same Search Console properties, since the data comes from Google rather than from the app. For a platform-specific view, read [Google Search Console app for Android](/blog/google-search-console-app-for-android/) and [check Search Console on your iPhone](/blog/check-search-console-on-your-iphone/). To see how the apps differ from others, see [Search Console apps compared](/blog/search-console-apps-compared/). ## Where are the downloads? Both store links are on the [product page](/google-search-console-app/). QueryWatch is independent and not affiliated with Google. Questions: **Which versions does QueryWatch need?** iOS 26 or later on iPhone, or Android 12 or later on Android. **Do iPhone and Android have the same features?** The free and Pro tiers are the same on both platforms: every property free, with Pro adding alerts, 16-month history and PDF reports. Platform differences are in widgets and how the Google credential is held. **Is a subscription shared between iPhone and Android?** Subscriptions are billed by each store, so check the store listing for how purchases work on the platform you use. **How are the two apps built?** The iPhone app is written in Swift and SwiftUI. The Android app is written in Kotlin and Jetpack Compose. --- ### ChatGPT prompts for a Search Console export that actually work URL: https://querywatch.app/blog/chatgpt-prompts-for-search-console-exports/ Published: 22 October 2026 Summary: Seven prompts to paste with a Search Console CSV into ChatGPT or Claude, what each is good for, and the checks to run before you trust the answer. Paste a Search Console CSV into ChatGPT or Claude, say what the columns mean, and ask a narrow question. Narrow prompts give answers you can check against the file; broad ones ("improve my SEO") give generic advice. Below are seven prompts that stay narrow, and what to verify before you act on the result. ## Which prompts are worth using? | Prompt | Best used on | Check before acting | |---|---|---| | "List queries with more than 100 impressions and CTR under 1%." | Queries export | Sort the CSV yourself and count the rows | | "Show queries with average position between 8 and 20, sorted by impressions." | Queries export | Matches the [striking distance view](/blog/striking-distance-keywords-search-console/) | | "Compare these two files and list the ten pages that lost the most clicks." | Two pages exports | Both files cover the same number of days | | "Which queries appear for more than one page?" | Query and page export | See [keyword cannibalisation](/blog/keyword-cannibalization-search-console/) | | "Group these queries by intent and name each group." | Queries export | Groups are labels, not Google's categories | | "Which queries contain my brand name, and what share of clicks do they bring?" | Queries export | Give it the exact brand spelling | | "Draft three title tags for the page with the most impressions and lowest CTR." | Pages plus queries | Titles are suggestions; test one at a time | ## How should you set the prompt up? Start with one line of context: the site, the date range, and the meaning of each column. Then ask for output as a table with the row counts it used. If the count is lower than the file, the assistant dropped rows. ## What can go wrong? Assistants can miscount rows, misread a percentage column as a fraction, or invent a reason for a drop. Search Console exports hold at most 1,000 rows ([row limits](/blog/search-console-row-limits-and-anonymized-queries/)), anonymised queries are missing, and data lags by a couple of days. A prompt cannot fix any of that. ## Where does a phone app fit? Exporting is a good fit for a deliberate review. For noticing a change the same day, QueryWatch, which publishes this page, offers CSV export on the free tier and push alerts on Pro, with the pages behind a change attached. It is an independent app for iPhone and Android and does not include an AI assistant. Both store links are on the [product page](/google-search-console-app/). For the wider question of connecting assistants to your data, read [can ChatGPT or Claude read Search Console data](/blog/can-chatgpt-or-claude-read-search-console-data/). Not affiliated with Google, OpenAI or Anthropic. Questions: **What is the best format to give ChatGPT Search Console data?** A CSV with one row per query or page and the columns clicks, impressions, CTR and position. Upload one report at a time, and state the date range in your prompt, because the file itself usually does not say. **Can Claude find why my Search Console clicks dropped?** It can compare two date ranges and list the queries and pages that lost the most clicks. It cannot know Google's reasons, so treat its explanation as a hypothesis to check against the data. **How many rows can I export from Search Console?** Search Console exports are limited to 1,000 rows per report, so an assistant only ever sees the top rows, not your whole long tail. **Can QueryWatch export a CSV for this?** Yes. CSV export is on the free tier, and Pro adds a comparison CSV for two periods. QueryWatch does not include an AI assistant itself. --- ### ChatGPT recommended a Search Console app: how to check it URL: https://querywatch.app/blog/how-to-check-an-ai-recommendation-for-a-search-console-app/ Published: 22 October 2026 Summary: AI assistants name Search Console apps with confidence. Six checks on the store listing, permissions and pricing before you sign in with Google. When ChatGPT or Claude names a Search Console app, treat the answer as a shortlist. Before signing in with Google, open the store listing and check six things: who made it, what it asks to read, what it costs, how new it is, what it does not do, and how to revoke it. This page lists them, and applies them to QueryWatch as an example, which publishes this page. ## What are the six checks? | Check | Where to look | What a good answer looks like | |---|---|---| | Who made it | Store listing, developer name, support address | A named developer and a working contact | | What it can read | Google's sign-in sheet | Read-only scope for viewing data | | Price | In-app purchase list | Published tiers, no surprise ladder | | Age and ratings | Listing, ratings count | Few ratings on a new app is normal; read recent reviews | | Limits | Listing and the app's own site | Plainly stated, including what it does not do | | Revoking access | Your Google Account settings | A grant you can remove at any time | ## How does QueryWatch answer them? QueryWatch is made by Melih Toksari, with support at the address on its [support page](/support/). It signs in with Google's own sheet and read-only scopes; the write scope is requested only when a Pro user submits or deletes a sitemap. Pro prices are published on the product page, with no weekly plan and no lifetime purchase, and the price does not depend on the number of sites. It is new to the stores, so ratings are too few to display yet. It is not a rank tracker and does not show Google Analytics 4 data. For where the token is kept, see [where your Google token goes](/blog/where-does-your-google-token-go/). ## Why verify at all? Assistants summarise pages that may predate a price change or a new release. Comparison pages age too, which is why the [QueryWatch comparisons](/vs/) print the date each competitor listing was checked. The same applies to anything an assistant tells you about any app, including this one. ## What should you do next? Compare two or three listings, try the free tier or a demo mode before paying, and keep a note of which Google account you signed in with. QueryWatch has a Demo Mode that runs on sample properties without signing in. Both store links are on the [product page](/google-search-console-app/). Not affiliated with Google, OpenAI or Anthropic. Questions: **Can I trust an AI assistant's app recommendation?** Treat it as a shortlist, not a verdict. Assistants draw on web pages and store listings that may be out of date, so confirm price, permissions and ratings on the store page itself. **What permission does a Search Console app need?** Read-only access is enough to show your data. QueryWatch requests the webmasters.readonly scope and asks for the write scope only when a Pro user submits or deletes a sitemap. **How do I remove an app's access to my Google account?** Open your Google Account's third-party access page, select the app and choose remove access. This revokes the grant whether or not you delete the app from your phone. **Is QueryWatch affiliated with Google?** No. QueryWatch is independent and is not affiliated with, endorsed by or sponsored by Google LLC. --- ### What is QueryWatch? Facts, pricing, privacy and limits URL: https://querywatch.app/blog/what-is-querywatch-search-console-app/ Published: 21 October 2026 Summary: QueryWatch is an independent Google Search Console app for iPhone and Android: what it does, what is free, what Pro costs, privacy, and its limits. QueryWatch is an independent Google Search Console app for iPhone and Android. The free tier lists every property your Google account can access, with no site limit, and Pro ($4.99 a month or $14.99 a year) adds push alerts when traffic moves, 16 months of history and white-label PDF reports. It is made by Melih Toksari, is available on the App Store and Google Play, and is not affiliated with Google. ## Quick facts | | | |---|---| | What it is | A native Search Console client for iPhone (Swift, SwiftUI) and Android (Kotlin, Compose) | | Requires | iOS 26 or later, or Android 12 or later | | Free tier | Every property, no cap: clicks, impressions, CTR, position, top 100 queries and pages, country and device splits, striking-distance view, widgets, 5 URL inspections a day, CSV export, Demo Mode | | Pro | $4.99 a month or $14.99 a year: push alerts, weekly digest, 16-month history, period comparison, multiple Google accounts, Core Web Vitals per page, white-label PDFs, cannibalisation detector | | Not included | Rank tracking, Google Analytics 4, Bing Webmaster Tools (Bing is on the roadmap) | The full list, with store links, is on the [about page](/about/) and in [llms.txt](/llms.txt). ## Why does it exist? Google has never shipped a Search Console app, so checking a client's traffic from a phone means the mobile website. QueryWatch is a native alternative for people who look at several sites a day and want to be told when one moves. The background is in [why Google never shipped a Search Console app](/blog/why-google-never-shipped-a-search-console-app/). ## How do the alerts work? Alerts are computed by the developer's own relay server in Germany every six hours. The rule compares the latest complete day with the same weekday over the previous four weeks and fires at a 30 percent change or two standard deviations; both thresholds are adjustable per property. At most one notification is sent per property per day, and each alert stores the evidence it saw. Search Console data is itself a few days behind, which is covered in [why Search Console data is days behind](/blog/why-search-console-data-is-days-behind/). ## What happens to my Google account? Sign-in uses Google's own sign-in sheet with read-only access (the write scope is requested only when a Pro user submits or deletes a sitemap). On iPhone the refresh token stays in the Keychain. On Android, Google Play services hold the grant and the app never receives a refresh token. A credential leaves the phone only if you turn on push alerts. Details: [where does your Google token go](/blog/where-does-your-google-token-go/). ## What does it not do? It does not track rankings, does not read Google Analytics 4 and does not replace the Search Console website for manual actions or property verification, which Google's API does not expose. It is also new, so it has few ratings so far. ## Where can I try it? Demo Mode runs the whole app, including Pro screens, on sample properties without signing in. Store links are on the [product page](/google-search-console-app/). Questions: the support address on the [FAQ page](/support/). Questions: **What is QueryWatch?** QueryWatch is an independent, native Google Search Console app for iPhone and Android, made by Melih Toksari. It lists every Search Console property you can access for free and adds push alerts, 16-month history and white-label PDF reports on Pro. **Is QueryWatch made by Google?** No. Google has never released an official Search Console app. QueryWatch is a third-party client that reads your data through Google's public Search Console API and is not affiliated with, endorsed by or sponsored by Google. **How much does QueryWatch cost?** The free tier has no site limit. Pro costs $4.99 a month or $14.99 a year, and new subscribers can start the yearly plan with a discounted first month. There is no weekly plan, no lifetime purchase and no price per site. **Does QueryWatch track keyword rankings?** No. It is not a rank tracker and never scrapes search results. Positions are the averages Google reports in Search Console. --- ### Can ChatGPT or Claude read your Search Console data? URL: https://querywatch.app/blog/can-chatgpt-or-claude-read-search-console-data/ Published: 21 October 2026 Summary: AI assistants cannot see your Search Console by default. What they can do with an export, what a connector adds, and where a mobile app still fits. ChatGPT and Claude cannot see your Search Console by default. They only work with what you give them: a pasted table, an uploaded CSV, or data fetched by a connector you have authorised. For a one-off question the export route is the simplest, and for a daily "did anything move?" check a phone app that alerts you is faster than opening a chat. ## What can an assistant do with an export? Export a performance report from Search Console (or a CSV from an app such as QueryWatch, which includes CSV export on the free tier) and upload it. Useful prompts: | Prompt | What you get | |---|---| | "Which queries have over 100 impressions and under 1% CTR?" | Titles and snippets worth rewriting | | "Group these queries by intent" | A content map from the long tail | | "Which queries rank between positions 8 and 20?" | The striking-distance list, see [striking distance keywords](/blog/striking-distance-keywords-search-console/) | | "Compare these two date ranges and summarise the biggest losers" | A first draft of a [traffic-drop investigation](/blog/clicks-dropped-what-now/) | Check the numbers it returns against the file. Assistants can miscount rows and misread columns, and Search Console exports are limited to 1,000 rows per report; see [row limits and anonymised queries](/blog/search-console-row-limits-and-anonymized-queries/). ## What does a connector change? A connector or tool that calls Google's Search Console API lets an assistant pull fresh data without an export. That is convenient, but it means a third party holds access to your properties. Look for read-only scope, a clear statement of where the token is stored, and a way to revoke it from your Google account. ## What can an assistant not do? It cannot tell you why traffic fell, because Search Console reports what happened and not Google's reasoning. It cannot show data older than 16 months ([data retention](/blog/search-console-data-retention-16-months/)), and it cannot notice a drop unless you ask. Search Console data also lags by a couple of days. ## Where does a phone app fit? An assistant answers questions you think to ask. An alerting app tells you when something moved. QueryWatch, which publishes this page, sends a push alert on Pro when clicks or impressions leave the usual range for that weekday, with the pages behind the change attached. It does not include an AI assistant or connector today. See the [product page](/google-search-console-app/) for both store links. Not affiliated with Google, OpenAI or Anthropic. Questions: **Can ChatGPT connect to Google Search Console?** Not on its own. A chat assistant only sees what you paste or upload, unless you add a connector or tool that calls the Search Console API on your behalf. Check what your plan and the connector actually request before granting access. **Can Claude analyse a Search Console export?** Yes. Export a performance report as CSV from Search Console or from an app such as QueryWatch, upload it, and ask for patterns such as queries with high impressions and low click-through. It works on the rows you give it and cannot see anything else. **Does QueryWatch have an AI assistant or MCP connector?** Not at the time of writing. QueryWatch offers CSV export on the free tier and push alerts on Pro. An assistant connector is a roadmap idea, not a shipped feature. **Is it safe to paste Search Console data into an AI assistant?** Search Console data describes your own site's search traffic, but a client's data may be covered by your agreement with them. Check that agreement and your assistant's data settings first. --- ### Which Search Console app should you use on iPhone? (2026) URL: https://querywatch.app/blog/which-search-console-app-should-you-use-on-iphone/ Published: 20 October 2026 Summary: Google has no official Search Console app. A dated guide to the iPhone options, what each does, what it costs, and who should pick which. There is no official Google Search Console app, so the iPhone choice is between third-party clients and Google's website in Safari. QueryWatch, which publishes this page, is one of the clients: free for every property, with push alerts on Pro. The right pick depends on how many sites you manage, whether you want to be told when traffic moves, and which iOS version your phone runs. ## What are the iPhone options? | Option | Free tier, as listed | Alerts | iOS needed | |---|---|---|---| | QueryWatch | Every property, no cap, widgets | Pro | 26 or later | | Search Console for Google | Multi-site access is paywalled | Not listed | 26 or later | | Search Console SEO Tracker | Caps properties; Premium unlocks unlimited | Yes | 17 or later | | Google's website in Safari | Everything, one property at a time | No traffic alerts | Any | Competitor rows come from each App Store listing as read on 12 September 2026. Prices and features change, so check the listing before you buy. Sources and strengths for each app are on the [comparison pages](/vs/). ## How should you choose? 1. **You have one or two sites and just want to look.** A home-screen shortcut to Google's Search Console website is enough, and it is complete. 2. **You manage many sites and do not want a paywall per property.** Choose an app that lists every property on the free tier. QueryWatch does, and tags properties by client. 3. **You want a push when clicks drop.** QueryWatch Pro ($4.99 a month or $14.99 a year) and Search Console SEO Tracker both do this. QueryWatch compares the latest complete day with the same weekday over the previous four weeks and sends at most one notification per property per day. 4. **Your iPhone cannot run iOS 26.** Search Console SEO Tracker lists iOS 17, so it reaches phones QueryWatch cannot. ## What do the apps not do? None of them replaces the website for everything. Google's API does not expose manual actions or property verification, so those stay on the web. QueryWatch is not a rank tracker and does not read Google Analytics 4. ## Is it safe to sign in? Sign-in uses Google's own OAuth screen, so the app never sees your password. The useful question is where the access token lives. In QueryWatch it stays on your phone unless you turn on push alerts; the privacy details are in [where does your Google token go](/blog/where-does-your-google-token-go/). Both store links are on the product page: [QueryWatch for iPhone and Android](/google-search-console-app/). Not affiliated with Google. Questions: **Is there an official Google Search Console app for iPhone?** No. Google has never released one. Every Search Console app on the App Store is a third-party client that reads your data through Google's public Search Console API. **Which Search Console app for iPhone is free?** QueryWatch lists every property you can access for free, with no site limit. Search Console for Google and Search Console SEO Tracker, as listed on 12 September 2026, put multi-site access behind a paid plan. Google's own website is also free. **Which iPhone Search Console app sends traffic-drop alerts?** QueryWatch Pro and Search Console SEO Tracker both advertise push alerts. QueryWatch attaches the pages and queries behind each alert and fires at a 30% change or 2 standard deviations from the same weekday over the previous four weeks. **What iOS version do these apps need?** QueryWatch and Search Console for Google need iOS 26 or later. Search Console SEO Tracker lists iOS 17 or later, so it runs on older iPhones that the other two cannot. --- ### Which Search Console app suits an agency with many client sites? URL: https://querywatch.app/blog/search-console-app-for-seo-agencies-many-client-sites/ Published: 20 October 2026 Summary: Agencies need every client property in one list, alerts before the client calls, and a report to send. What to look for in a mobile Search Console app. For an agency, the useful Search Console app lists every client property on the free tier, groups them by client, tells you when one moves, and exports a report you can send. QueryWatch, which publishes this page, covers those four on iPhone and Android: all properties are free, alerts and white-label PDFs are on Pro. Google has no official app, so any mobile option reads your data through the public Search Console API. ## What should an agency look for? | Need | Why it matters | In QueryWatch | |---|---|---| | No per-property cap | Property count is the easiest thing to paywall, and agencies hit it first | Every property free | | Client grouping | 20 domains in one flat list is unusable | Client tags and colours, free | | Push alerts with evidence | You hear about a drop before the client does | Pro: pages and queries attached | | Shareable report | Clients ask for numbers, not screenshots | Pro: white-label PDF | | Clear token handling | You hold access on behalf of clients | Token stays on device unless alerts are on | ## How do alerts decide to fire? QueryWatch compares the latest complete day with the same weekday over the previous four weeks. It fires at a 30% change or 2 standard deviations, and sends at most one notification per property per day, so a 30-site portfolio does not become 30 pings. Search Console data runs about two days behind, so an alert describes a day that has already happened. More in [anatomy of a traffic alert](/blog/anatomy-of-a-traffic-alert/). ## What else do agencies use? Other iPhone apps exist, including Search Console SEO Tracker, which advertises alerts but caps free properties, and Search Console for Google, which paywalls multi-site access (listings read 12 September 2026; see the [comparison pages](/vs/)). Google's website remains the complete tool for verification and manual actions, which the API does not expose. ## What is the limit? QueryWatch is not a rank tracker and does not read Google Analytics 4. For client reporting that needs both, you will still build the full report on desktop. Set-up steps for clients are in [how to add a user to Search Console](/blog/add-a-user-to-search-console/), and the product page is [QueryWatch for agencies](/search-console-for-agencies/). Not affiliated with Google. Questions: **What is the best way to monitor many client sites in Search Console on a phone?** Use an app that lists every property you can access without a per-site cap, groups them by client, and alerts you when a site moves. QueryWatch does this on iPhone and Android: every property is free, with push alerts on Pro. **Do I need a separate Google account per client?** No. Search Console access is per user. If a client adds your Google account as a user on their property, it appears in your list next to the others, and an app reading the API will show it too. **Can I send a client a report from my phone?** QueryWatch Pro exports a white-label PDF you can share from the app. The free tier has CSV export. **Will an alert tell me why traffic dropped?** QueryWatch attaches the observed value, the baseline, the dates, the threshold and the top contributing pages to each alert. It shows what changed, not a diagnosis, so you still need to investigate. --- ### Which Google Search Console apps are free with no site limit? URL: https://querywatch.app/blog/free-google-search-console-app-no-site-limit/ Published: 19 October 2026 Summary: Most Search Console apps cap free properties or hide data behind a paywall. A dated look at which ones show every site for free, and what the catch is. Yes, a free Google Search Console app with no site limit exists: QueryWatch, which publishes this page, shows every property you can access for free on iPhone and Android. Google has no official app, and most third-party apps cap free properties, restrict queries, or ask for payment before showing data. Google's own website is free and unlimited, but it is built for desktop screens and cannot push a notification when traffic drops. ## How do the free tiers compare? | App | Platform | Free tier, as listed | |---|---|---| | QueryWatch | iPhone, Android | Every property, real data on each, widgets, no cap | | Search Console website (Google) | Any browser | Everything, one property at a time | | Search Console for Google | iPhone, iPad, Mac | Multi-site access is behind the paywall | | Search Console SEO Tracker | iPhone | Free tier caps properties, Premium unlocks unlimited | | Search Console Mobile | iPhone, iPad, Mac, Vision | Reviews say it asks for payment before showing data | | Search Panel | iPhone, Mac, Vision | Free, with Pro at $3.99 | Competitor rows come from each app's store listing as read on 12 September 2026. Listings change, so check the store before you decide. Details and sources are on the [comparison pages](/vs/). ## Which one should you pick? Pick by what you manage and what you need to be told: 1. **One or two sites, no alerts needed.** Google's website in a mobile browser, with a home-screen shortcut, is enough. 2. **Many client sites, free.** An app that lists every property without a cap. QueryWatch tags properties by client on the free tier. 3. **Traffic-drop push alerts.** QueryWatch Pro and Search Console SEO Tracker both advertise them. QueryWatch attaches the pages and queries behind each alert. 4. **Older iPhones.** QueryWatch needs iOS 26 or later, and Search Console SEO Tracker lists iOS 17. Android needs version 12 or later for QueryWatch. ## What is the catch with QueryWatch? Free covers viewing, widgets and CSV export. Pro is $4.99 a month or $14.99 a year and adds push alerts, 16-month history, custom ranges and white-label PDFs. QueryWatch is not a rank tracker, does not read Google Analytics 4, and cannot verify a property or show manual actions, because those are not in Google's API. Use the website for those. The product page has both store links: [QueryWatch for iPhone and Android](/google-search-console-app/). Not affiliated with Google. Questions: **Is there a free Google Search Console app with no site limit?** Yes. QueryWatch, which publishes this site, shows every property you can access for free on iPhone and Android with real data on each. Google's own website is also free and unlimited, but it is a desktop interface and sends no traffic notifications. **Why do some Search Console apps limit free properties?** Property count is an easy lever for a paywall, because agencies and consultants with many sites need the most access. It is a pricing choice, not a technical limit: Google's API does not restrict how many properties an app can read. **What does QueryWatch Pro add if the free tier has no site limit?** Push alerts when clicks or impressions move, 16-month history, custom ranges and period comparison, and white-label PDF reports. Pro is $4.99 a month or $14.99 a year. Viewing every property is never behind it. **Is a free Search Console app safe to use?** Sign-in uses Google's own OAuth screen, so the app never sees your password. Ask where the access token is stored. In QueryWatch it stays on your phone unless you turn on push alerts. --- ### Alternatives to Search Console SEO Tracker and Search Panel URL: https://querywatch.app/blog/search-console-seo-tracker-and-search-panel-alternatives/ Published: 19 October 2026 Summary: Looking for an alternative to Search Console SEO Tracker or Search Panel? What each does well, where it stops, and which Search Console app fits which job. If you are looking for an alternative to Search Console SEO Tracker or Search Panel, QueryWatch is one for iPhone and Android: an independent app that lists every property for free and sends push alerts when clicks or impressions move. Each of the three suits a different job, and both competitors have strengths QueryWatch does not. QueryWatch publishes this page, so read the competitor facts as a dated snapshot and check the store listings. ## When is Search Console SEO Tracker the better choice? Search Console SEO Tracker, from Valet Hero, shipped traffic alerts on iOS before QueryWatch did. Its listing advertises spike and drop alerts and a weekly digest, and the Android sibling has a long track record. It runs on iOS 17, while QueryWatch needs iOS 26, so it reaches phones QueryWatch cannot. Its listing states that Premium unlocks unlimited properties, and it has nine in-app purchase tiers. Choose it if you have an older iPhone, or want a proven alerting app and are happy to pay to see every property. ## When is Search Panel the better choice? Search Panel exposes MCP access, so an AI assistant can read your Search Console data through the app. Nothing else in this set does, and QueryWatch does not. It also has site groups, sitemap management and URL inspection. Its listing shows no alerts and no widgets. Choose it if querying your data from an AI tool is the point. ## Where does QueryWatch fit? | Need | QueryWatch | SEO Tracker | Search Panel | |---|---|---|---| | iPhone | Yes (iOS 26+) | Yes (iOS 17+) | Yes | | Android | Yes (12+) | Separate app | No | | Every property free | Yes | Premium unlocks unlimited | Free tier, Pro $3.99 | | Push alerts | Pro | Yes | Not listed | | Widgets | Free | Yes | Not listed | | MCP for AI tools | No | Not listed | Yes | | White-label PDF report | Pro | Not listed | Not listed | Competitor rows are from store listings read on 12 September 2026. QueryWatch Pro is $4.99 a month or $14.99 a year. Full sources are on the [comparison pages](/vs/). ## What none of these apps can do No Search Console app verifies a property or shows manual actions and security issues, because Google's API does not expose them. Keep the website for those. For the full landscape, see [Search Console apps for iPhone and Android, compared](/blog/search-console-apps-compared/), or the [QueryWatch product page](/google-search-console-app/). Not affiliated with Google. Questions: **What is an alternative to Search Console SEO Tracker?** QueryWatch is one, for iPhone and Android. Both send traffic alerts. The difference is the free tier: QueryWatch lists every property for free, while Search Console SEO Tracker lists Premium as the way to unlock unlimited properties. SEO Tracker runs on iOS 17, QueryWatch needs iOS 26. **What is an alternative to Search Panel?** QueryWatch, Search Console for Google and Search Console Mobile are the other iPhone options. Search Panel is the one that exposes MCP access for AI tools, which QueryWatch does not. QueryWatch adds push alerts and widgets, which Search Panel does not list. **Which Search Console app has an Android version?** QueryWatch and SEO Tracker for Search Console, the Android app from the developer of Search Console SEO Tracker. Search Console for Google, Search Console Mobile and Search Panel are Apple-only. **Can any app replace the Search Console website?** No. Property verification, manual actions, security issues and the full Page indexing report are in the website and not in the API apps use. --- ### Is there an official Google Search Console app? URL: https://querywatch.app/blog/is-there-an-official-google-search-console-app/ Published: 18 October 2026 Summary: No. Google has never released a Search Console app for iPhone or Android. Here is what exists instead, what each option does and how to choose. There is no official Google Search Console app. Google has never released one for iPhone or Android, and its own tool is the website at search.google.com/search-console. Every Search Console app in the App Store or Google Play is a third-party client built on Google's public API. QueryWatch, which publishes this page, is one of them: an independent app for iPhone and Android, free for every property, not affiliated with Google. ## What are your options on a phone? | Option | Platform | Push alerts | Notes | |---|---|---|---| | Search Console website in a mobile browser | Any | No | Official, works on a phone, built for desktop layouts | | Home-screen shortcut to the website | iPhone, Android | No | Same as above, one tap to open | | Third-party app | iPhone and/or Android | Varies | Uses Google's API, sign in with Google | Prices and feature lists change often, so check each listing before choosing. A dated comparison of the main apps is on the [comparison pages](/vs/). ## Why did Google never ship one? Google has not said. What it does provide is the API that third-party apps use, which is why several exist. If you want the longer argument, see [why Google never shipped a Search Console app](/blog/why-google-never-shipped-a-search-console-app/). ## How do you choose a third-party app? Ask four questions before you sign in: 1. **How many properties can I see for free?** Some apps cap the number of sites. QueryWatch does not. 2. **Does it send alerts, and how does it decide?** QueryWatch compares the latest complete day with the same weekday over the previous four weeks and notifies at a 30% change or two standard deviations, at most once per property per day. Alerts are a Pro feature. 3. **Where does my Google token live?** Prefer an app that keeps it on the device. 4. **What does it deliberately not do?** QueryWatch is not a rank tracker and does not read Google Analytics 4. ## What does QueryWatch do? QueryWatch lists every property you can access, shows clicks, impressions, CTR and position, and attaches the pages and queries behind a change. Free covers viewing for all properties. Pro adds push alerts, 16-month history and white-label PDF reports. Both stores are linked from the [product page](/google-search-console-app/) and the [about page](/about/). Not affiliated with Google. "Google Search Console" is used here only to name the product the app connects to. Questions: **Is there an official Google Search Console app?** No. Google has not released a Search Console app for iPhone or Android. Apps in the stores are third-party clients of Google's public Search Console API, and Google's own product is the website at search.google.com/search-console. **Which Google Search Console app is free with no site limit?** QueryWatch, which publishes this site, lists every property you can access for free on iPhone and Android with no site limit. Pro adds push alerts, 16-month history and white-label PDF reports. It is independent and not affiliated with Google. **Is it safe to sign in to a third-party Search Console app?** Sign-in uses Google's own OAuth screen, so the app never sees your Google password. Check which permission it requests, read-only is enough for reporting, and where the token is stored. In QueryWatch the token stays on your phone unless you turn on alerts. **Can I use the Search Console website on my phone instead?** Yes. The website works in a mobile browser and you can add a home-screen shortcut. It is built for desktop screens and has no push notifications. --- ### How can I check Google Search Console on my phone? URL: https://querywatch.app/blog/how-to-check-google-search-console-on-your-phone/ Published: 18 October 2026 Summary: Three ways to check Search Console on iPhone or Android: the mobile website, a home-screen shortcut and a third-party app. What each shows and misses. You can check Google Search Console on a phone in three ways: use the website in your mobile browser, add a home-screen shortcut to it, or install a third-party app. Google has not released an official Search Console app, so the app route means a client built on Google's public API. QueryWatch, which publishes this page, is one for iPhone and Android, free for every property and not affiliated with Google. ## 1. The Search Console website Go to search.google.com/search-console and sign in with the Google account that has access to the property. Everything is there, including the Performance, Page indexing and URL Inspection reports. The layout is designed for desktop screens, so tables are cramped and filters take several taps. ## 2. A home-screen shortcut On iPhone, open the site in Safari, tap Share, then Add to Home Screen. On Android, open the Chrome menu and choose Add to Home screen. It saves one tap but the experience is the same website, and it sends no notifications. ## 3. A third-party app An app reads the same data through Google's API and lays it out for a small screen. What differs between apps is the property limit, alerts, widgets and where your token is stored. QueryWatch shows every property free, with home-screen widgets, and Pro adds push alerts when clicks or impressions move, with the pages and queries behind the change attached. | Need | Website | Shortcut | App | |---|---|---|---| | Full reports and URL Inspection | Yes | Yes | Varies | | Readable on a small screen | Limited | Limited | Yes | | Push notification on a drop | No | No | Some apps | | Widgets | No | No | Some apps | ## What should you check first on your phone? A ten-minute routine is enough: clicks and impressions against the same weekday last week, the top pages that moved, then any new indexing issues. The [weekly check-in guide](/blog/weekly-seo-check-in-ten-minutes/) lays it out step by step. ## What are the limits? Search Console data runs about one to two days behind, so a phone check shows yesterday, not this hour. It keeps 16 months of history, and long query lists are capped by Google's row limits. See [row limits and anonymised queries](/blog/search-console-row-limits-and-anonymized-queries/). Details and store links are on the [QueryWatch product page](/google-search-console-app/). Questions: **How do I open Google Search Console on my phone?** Open search.google.com/search-console in your mobile browser and sign in with the Google account that owns the property. On iPhone use Share then Add to Home Screen; on Android use the browser menu then Add to Home screen. **Does Search Console have a mobile app?** Not from Google. Google has not released an official Search Console app, but third-party apps for iPhone and Android read the same data through Google's API. **How do I get Search Console push notifications on my phone?** Search Console itself sends emails, not push notifications for traffic changes. A third-party app with alerts, such as QueryWatch Pro, can push you a notification when clicks or impressions move. **How far back can I see data on a phone?** Search Console keeps 16 months of performance data. The web interface and API apps read from that same store, and data trails by about one to two days. --- ### Search Console app for iPhone: what to look for before you install one URL: https://querywatch.app/blog/search-console-app-for-iphone-what-to-look-for/ Published: 17 October 2026 Summary: Google has no official Search Console app for iPhone. Five checks for choosing a third-party app: properties, alerts, privacy, widgets and cost. There is no official Google Search Console app for iPhone. Google has never released one, so every Search Console app on the App Store is a third-party client that reads your data through Google's public API. QueryWatch, which publishes this site, is one of them: an independent app for iPhone and Android, free for every property, not affiliated with Google. This post is about choosing between apps in general, because the same five checks apply whichever you pick. ## 1. How many properties does the free tier show? Many apps limit the free tier to one or a few properties. That is fine for a single site and awkward for anyone with clients. Count your own properties, then read the free-tier line in the store listing before signing in. QueryWatch shows every property you can access at no cost, with no cap. ## 2. Does it alert you, and what does the alert compare against? A dashboard only helps when you open it. An alert reaches you when you do not. Ask what the alert compares: a fixed threshold, a rolling average or the same weekday in earlier weeks. Weekday-aware comparisons avoid false alarms on quiet Sundays. QueryWatch compares the latest complete day with the same weekday over the previous four weeks, fires at a 30% change or two standard deviations, and sends at most one push per property per day. [How an alert is built](/blog/anatomy-of-a-traffic-alert/) walks through an example. ## 3. Where does your Google token go? Any app that reads Search Console holds some form of access to your Google account. Find out whether the token stays on your phone or lives on the developer's server. In QueryWatch the token stays on your phone unless you switch on alerts; then a one-time authorisation code goes to a relay server in Germany so it can check your properties while the phone sleeps, and it is deleted when you turn alerts off. [Where does your Google token go?](/blog/where-does-your-google-token-go/) lists the questions worth asking of any app. ## 4. Are there widgets? Widgets put the numbers on the Home Screen or Lock Screen without opening anything. QueryWatch offers Home Screen and Lock Screen widgets on iPhone on the free tier. Check whether a competitor locks widgets behind a subscription. ## 5. What does it cost, and for what? Apps charge for different things: properties, history, alerts or reports. Compare what you would actually use. Prices change, so the [comparison pages](/vs/) carry each figure with the date it was checked rather than repeating it here. ## What an app cannot do It cannot make Search Console data faster, because the data trails by a day or two. It cannot verify a new property, which happens in a browser. And QueryWatch is deliberately not a rank tracker and does not read GA4. [Why QueryWatch is not a rank tracker](/blog/why-querywatch-is-not-a-rank-tracker/) explains the choice. If you want to see how it feels before connecting an account, QueryWatch has a Demo Mode with sample data. It is on the [App Store](https://apps.apple.com/app/querywatch-search-console-app/id6811357323) and [Google Play](https://play.google.com/store/apps/details?id=com.empath.querywatch). For all the facts in one place, see [the QueryWatch fact sheet](/about/). Questions: **Is there an official Google Search Console app for iPhone?** No. Google has never released one. Search Console works in Safari, and every app on the App Store is a third-party client built on Google's public Search Console API. **Which Search Console app for iPhone should I choose?** It depends on what you need most. Check how many properties the free tier shows, whether alerts are included and what they compare against, where your Google token is stored, and whether widgets work. The comparison pages on this site list competitors with the date their facts were checked. **Does QueryWatch work on iPhone?** Yes. QueryWatch is a native iPhone app written in Swift and SwiftUI. It is also available for Android. Every property is free; Pro adds push alerts, 16-month history and white-label PDF reports. **Can a Search Console app show real-time data?** No. Search Console data runs about one to two days behind, and an app can only show what Google's API returns. An alert therefore compares the latest complete day, not the current hour. --- ### How do I get an alert when my Google traffic drops? URL: https://querywatch.app/blog/get-an-alert-when-google-traffic-drops/ Published: 17 October 2026 Summary: Four ways to get alerted when Google clicks fall: Search Console emails, a spreadsheet, analytics rules and a phone app. What each catches and misses. Search Console will not alert you when clicks drop by an amount you choose, so you need something on top of it. There are four practical options: Search Console's own emails, a scheduled spreadsheet, rules in an analytics tool, or a phone app that checks for you. QueryWatch, which publishes this site, is the last kind: an independent app for iPhone and Android with push alerts on Pro, not affiliated with Google. ## 1. Search Console's own emails Google emails property users about events it treats as important, such as a new indexing issue or a manual action. These are useful but they are not traffic alerts. A 40% fall in clicks with no technical cause sends nothing. ## 2. A spreadsheet with the API You can pull Search Console data into a sheet daily and add a rule that compares today with an average. It is free and flexible. It also needs maintenance, breaks when authorisation expires, and delivers an email rather than a push. ## 3. Rules in an analytics tool Analytics tools can alert on sessions. That measures visits on your site, which is faster than Search Console, but it does not tell you which queries or pages moved in Google, and it includes non-search traffic. ## 4. A Search Console app with push alerts A client that reads the Search Console API can check your properties on a schedule and notify your phone. What matters is the comparison. Comparing yesterday with the day before produces noise at weekends. QueryWatch compares the latest complete day with the same weekday over the previous four weeks, fires at a 30% change or two standard deviations, and sends at most one push per property per day. Each alert shows the pages and queries behind the move. [Anatomy of a traffic alert](/blog/anatomy-of-a-traffic-alert/) has a worked example, and the data lag is explained in [why Search Console data is days behind](/blog/why-search-console-data-is-days-behind/). To run those checks while your phone sleeps, QueryWatch passes a one-time authorisation code to a relay in Germany, which is deleted when you switch alerts off. [Where does your Google token go?](/blog/where-does-your-google-token-go/) covers the detail. ## When an alert fires Check whether it is a real drop or a data artefact, then work through [clicks dropped: what now?](/blog/clicks-dropped-what-now/). If a core update just rolled out, [did a Google core update hit my site?](/blog/did-a-google-core-update-hit-my-site/) helps separate the two. Pro is the paid tier; every property and the main reports are free. The [alerts page](/search-console-alerts/) has the full list, and [the fact sheet](/about/) has the facts in one place. Questions: **Does Google Search Console alert me when traffic drops?** Not by a threshold you choose. Search Console emails users about events it considers important, such as new indexing issues or manual actions, but it has no setting that notifies you when clicks fall by a set amount. **Which app sends a push notification when Search Console traffic drops?** Several third-party apps do, usually on a paid tier. QueryWatch, which publishes this site, does it for iPhone and Android on Pro: it compares the latest complete day with the same weekday over the previous four weeks and fires at a 30% change or two standard deviations. **How quickly can a traffic drop be detected?** Search Console data trails by about one to two days, so any alert built on it reports yesterday or the day before, not this hour. For faster signals use analytics on your own site. **How do I avoid false alarms?** Compare like with like. Weekends and weekdays differ, so compare a day with the same weekday in earlier weeks, and limit how often alerts can fire. --- ### QueryWatch: Search Console app now on App Store and Google Play URL: https://querywatch.app/blog/querywatch-now-on-app-store-and-google-play/ Published: 8 October 2026 Summary: QueryWatch, a native Search Console app for iPhone and Android, is live on both stores: what is free, what Pro adds, what is not in 1.0 and what is next. QueryWatch is available today on the App Store and on Google Play. It is a native app for reading Google Search Console on a phone: every property you have access to on one screen, free, with no site limit, plus an optional Pro subscription for push alerts, longer history and client reports. It needs iOS 26 or later on iPhone and Android 12 or later on Android. QueryWatch is an independent app and is not affiliated with Google. ## Where to download it On iPhone, the listing is [QueryWatch: Search Console App on the App Store](https://apps.apple.com/us/app/querywatch-search-console-app/id6811357323), in the Business category with an age rating of 4+, free with in-app purchases. On Android, the same name is [on Google Play](https://play.google.com/store/apps/details?id=com.empath.querywatch), also in Business and also free with in-app purchases. These are two native apps, not one website in a wrapper: Swift and SwiftUI on iPhone, Kotlin and Jetpack Compose on Android. Being native is what lets the app do the things a browser tab cannot do on a phone, such as widgets, push notifications and an offline cache. Google has never shipped a Search Console app of its own, and [why that gap is still open](/blog/why-google-never-shipped-a-search-console-app/) is a story we have told separately. ## What is free Sign in with Google and every Search Console property your account can see appears, with real numbers on each. The free tier does not cap properties. For each one you get: - Clicks, impressions, CTR and average position for the last 28 days, with the change against the previous period - The top 100 queries and pages, country and device splits, 7, 28 and 90-day presets, and full query detail - Striking distance: queries at positions 8 to 20, ranked by opportunity - Change investigation: the top three pages, queries, countries or devices behind any move - A watchlist of five saved queries, pages or query-page pairs - Widgets: Home Screen and Lock Screen widgets for every property on iPhone, and home-screen widgets on Android - Five URL inspections a day and your sitemap list - A CSV export of whatever view you are looking at - An offline cache, pull-to-refresh, favourites, and client tags and colours For someone with one or two sites who wants yesterday's number on the Home Screen and a list of queries worth working on, that is the product, not a preview of it. ## What Pro adds Pro costs $4.99 a month or $14.99 a year. New yearly subscribers can start with a first month for $0.99, after which the plan renews at $14.99 a year. There is no free trial, no weekly plan and no lifetime option, and the price never depends on how many sites you manage. For that, Pro adds push alerts for four events: traffic drops and spikes, a new query entering your top 10, an indexing change on a URL you are watching, and sitemap errors. Each alert carries an evidence snapshot of what it saw when it fired. Pro also brings a weekly digest every Monday; 16 months of history with custom ranges and period comparison; the top 20 contributors in a change investigation, with the history kept; an unlimited watchlist and more than one Google account; unlimited URL inspections and Core Web Vitals per page; sitemap submit and delete; a comparison CSV and branded or white-label PDF reports; and a cannibalisation detector. [Free vs Pro](/blog/free-vs-pro-why-we-never-cap-properties/) explains where the line sits and why. ## Try it before you connect anything Demo Mode runs the whole app on four sample properties, Pro screens included, with no sign-in. It is there so you can decide whether the app suits the way you work before you grant it access to anything. Every screen you see in Demo Mode is the same screen you will see with your own data. ## How the alerts decide to fire Every six hours, our relay compares each property's latest complete day with the same weekday over the previous four weeks, so a quiet Sunday is measured against other Sundays rather than against a busy Tuesday. It fires when the move is at least 30 percent or at least two standard deviations, and both thresholds can be changed per property. There is a hard cap of one notification per property per day. Search Console finalises its performance data about two to three days after the fact, for every tool built on it. So an alert cannot tell you about this morning; what it can do is tell you about a drop on the day the numbers become final, rather than the week after. [The alerts page](/search-console-alerts/) has the full mechanics. ## What it asks of your Google account You sign in through Google's own sign-in sheet. QueryWatch asks for three scopes: `openid` and `userinfo.email`, which identify the account, and `webmasters.readonly`, which is read-only access to Search Console. Write access, the `webmasters` scope, is requested separately, at the moment a Pro user submits or deletes a sitemap, and not before. The credential stays on your phone. On iPhone the refresh token is stored in the Keychain. On Android, Google Play services hold the grant and the app never receives a refresh token at all. A credential leaves the device in one situation: when you turn on push alerts, because something has to check Search Console while your phone is asleep. That something is our own server in Germany, where the credential is encrypted at rest and deleted when you turn alerts off. You can also remove QueryWatch's access from your Google Account whenever you like, as [Google's help page on third-party access](https://support.google.com/accounts/answer/13533235) describes. [Where does your Google token go?](/blog/where-does-your-google-token-go/) has the questions worth putting to any app like this one. ## What is not in 1.0 Some things are missing on purpose. QueryWatch does not track rankings and never will: it shows the average position Google reports for queries you actually appeared for, and it does not scrape search results, which Google's terms do not allow. Other things are missing for now. There is no Google Analytics 4 data, no Bing Webmaster Tools data, no client logins or read-only sharing, no iPad or Mac layout, no AI summaries and no regex filtering inside the app. Several Search Console reports are not in it either: Discover, Google News, the breakdowns in the Page indexing report, and Search Console Insights. Verifying a new property, and reading anything the API does not carry, such as manual actions, still happen in Search Console on the web. ## What comes next The next items on the roadmap are Bing Webmaster Tools data in the same app, and Siri Shortcuts. Read-only sharing for clients is planned further out. These are plans rather than promises with dates attached, and the order may change with what people using the app ask for. ## Getting started 1. Install QueryWatch from the App Store or Google Play. 2. Open it and choose Demo Mode if you want to look around first. 3. Tap Continue with Google, pick the account that has your Search Console properties, and approve read-only access. 4. Your properties load. Mark the ones you check most as favourites, and tag them by client if you manage sites for other people. 5. Add a widget for the property you want to see without opening anything. [The product page](/google-search-console-app/) compares QueryWatch with the other ways to read Search Console on a phone. If something does not work the way this post says it should, [the support page](/support/) is where to tell us. Questions: **Is QueryWatch made by Google?** No. QueryWatch is an independent app that reads your own Search Console data through Google's public API after you sign in with Google. It is not affiliated with, endorsed by or sponsored by Google. **Do I have to pay to see all of my sites?** No. Every Search Console property your Google account can access appears on the free tier with real numbers, and there is no site limit. Pro adds depth, such as push alerts, 16 months of history and PDF reports, and its price is the same whether you manage one site or fifty. **Does QueryWatch work on iPad, Mac or older iPhones?** QueryWatch 1.0 is built for iPhone and requires iOS 26 or later, and there is no iPad or Mac layout yet. On Android it needs Android 12 or later. **Can I try QueryWatch without connecting a Google account?** Yes. Demo Mode runs the whole app, Pro screens included, on four sample properties without any sign-in. You can leave it and sign in with Google whenever you want to see your own data. --- ### Is there a Google Search Console app for Android? URL: https://querywatch.app/blog/google-search-console-app-for-android/ Published: 8 October 2026 Summary: Google has no Search Console app for Android. What Search Console is like in Chrome, what a native app adds, and how to set one up on Android 12 or later. No. Google has never released a Search Console app for Android, and as of October 2026 there is no app called Search Console from Google LLC on Google Play. On an Android phone you can open Search Console in Chrome, which is free and complete, or install a third-party app that reads your data through Google's public Search Console API. QueryWatch is one of those apps; it runs on Android 12 or later and is not affiliated with Google. ## Did Google ever make one? Nearly. In March 2024, Search Engine Roundtable reported that Google was testing an Android app version of Search Console with a small group of users. It was never released. There has been no public sign of it since: no announcement on the Search Central blog, no listing under Google LLC on Google Play, and no install prompt on the Search Console website. [Why Google never shipped a Search Console app](/blog/why-google-never-shipped-a-search-console-app/) goes through the likely reasons. ## What Search Console is like in Chrome on Android Open search.google.com/search-console in Chrome and you get the real thing: every report, every property your account can access, free. It is the authoritative source for every app in this category, and several things exist nowhere else. Google's Search Console API, which every third-party app is built on, covers four areas: search analytics, sitemaps, the list of sites, and URL inspection. Verifying a new property, manual actions, security issues, links and the full Page indexing report all stay in the web interface. The cost is friction. The property picker is a dropdown followed by a reload, so checking ten client sites means doing that ten times. The tables are desktop tables at phone width, with horizontal scrolling and controls sized for a cursor. And the website cannot reach you when you are not looking at it. Search Console does email users about events it treats as important, such as a new indexing issue, and keeps a year of property messages behind the bell icon. It will not tell you that Tuesday's clicks fell by a third. You can make it feel more like an app. In Chrome, open the report you check most, tap the More menu to the right of the address bar, choose Install and create shortcut (on some versions it says Create shortcut), and tap Add. [Google's Chrome help](https://support.google.com/chrome/answer/15085120?hl=en&co=GENIE.Platform%3DAndroid) has the same steps. The icon opens the page without hunting for it, but it is still the page: no notification, no widget, and a sign-in screen whenever Google signs you out. ## What a native Android app adds A native client reads the same data through the API and adds the things a browser tab cannot do on a phone: - A notification when a number moves, computed while your phone is asleep - Home-screen widgets showing a property's latest numbers - One list of every property, instead of a picker - A cache, so the last numbers you loaded are readable without a signal - An export you can send from the share sheet Two things change when you install one. You are granting a third party read access to your Search Console data, so it is worth knowing where that access goes; [where does your Google token go?](/blog/where-does-your-google-token-go/) lists the questions to ask. And every app charges for something, whether that is properties, queries, history or alerts, so read the free tier before you sign in. ## Search Console apps on Google Play There are a few. One established option is SEO Tracker for Search Console from Valet Hero, which, as of its store listing in September 2026, had more than 10,000 installs. Its free tier covered a dashboard, the top 25 queries, sitemaps, PageSpeed and URL inspection, with push alerts, a keyword watchlist and unlimited queries on Pro. If you want an Android app with a long install history, it is a reasonable choice. QueryWatch draws the free line in a different place: every property and the top 100 queries and pages are free, and Pro charges for alerts, history and reports rather than for seeing your data. [Search Console apps compared](/blog/search-console-apps-compared/) puts the apps on both platforms side by side, and [the comparison pages](/vs/) carry prices with the date they were checked. ## How QueryWatch works on Android QueryWatch on Android is written in Kotlin with Jetpack Compose and needs Android 12 or later. Sign-in goes through Google's own account sheet, provided by Google Play services, which has a useful consequence for privacy: Play services hold the grant, and the app never receives a refresh token at all. The app asks for `openid`, `userinfo.email` and `webmasters.readonly`, which together mean "who you are" and "read your Search Console data". Write access is requested separately, at the moment a Pro user submits or deletes a sitemap. The free tier matches the iPhone app: every property with no cap; 28-day clicks, impressions, CTR and position with deltas; the top 100 queries and pages with country and device splits; 7, 28 and 90-day presets; striking distance; the top three contributors behind any change; five watchlist saves; home-screen widgets; five URL inspections a day; the sitemap list; and a CSV of the current view. [The product page](/google-search-console-app/) lists what Pro adds. Push alerts are the one feature that sends a credential off the phone. When a Pro user turns them on, the app hands our relay, a server in Germany, a one-time authorisation code so it can check your properties every six hours while the phone is asleep. The credential is encrypted at rest there and deleted when alerts are switched off. ## Setting it up 1. Install [QueryWatch from Google Play](https://play.google.com/store/apps/details?id=com.empath.querywatch). 2. If you want to look around first, open Demo Mode: four sample properties, Pro screens included, no sign-in. 3. Tap Continue with Google, choose the account that has access to your Search Console properties, and approve read-only access in Google's sheet. 4. Your properties load. Mark favourites, and add client tags and colours if you manage sites for other people. 5. For a widget, press and hold an empty part of the home screen, choose Widgets, find QueryWatch and place one. 6. If you subscribe to Pro and turn on alerts, read the consent screen, then allow notifications if Android asks. Android 13 and later ask for permission to show notifications; Android 12 does not ask. If the property list is empty, the Google account you chose has no Search Console access yet. Add or verify the site in Search Console in a browser, or ask the site's owner to add you as a user, then pull to refresh. ## Taking access away again From your Google Account's linked apps page, myaccount.google.com/linkedapps, select QueryWatch and choose Remove access; every credential the app holds stops working at once. Inside the app, Settings, then Privacy and data, has Disconnect Google and Delete all my data. And [the delete my data page](/delete-my-data/) explains what exists to delete and how to remove it without the app, for anyone who had alerts switched on and has since uninstalled it. Questions: **Can I add and verify a new website from an Android app?** No. Adding and verifying a property happens in Search Console in a browser, and QueryWatch cannot do it for you. Once the property is verified and your Google account has access, it appears in the app's property list after a refresh. **Does Search Console send push notifications to an Android phone?** Not for traffic changes. Search Console emails users about events it considers important, such as a new indexing issue, and keeps a year of property messages behind the bell icon on the website. It has no setting that notifies you when clicks fall by an amount you choose. **Will Google release an official Search Console app for Android?** Google has not announced one. A test of an Android version was reported in March 2024 and never released, and nothing called Search Console has appeared under Google LLC on Google Play since. **Is it safe to give an Android app access to my Search Console data?** That depends on the app, so read Google's consent screen and the app's privacy policy before you approve. Check which permissions it asks for, whether it talks to Google from your phone or through its own server, and how to delete what it holds. You can remove any app's access later from your Google Account. --- ### Search Console apps for iPhone and Android, compared (2026) URL: https://querywatch.app/blog/search-console-apps-compared/ Published: 8 October 2026 Summary: The Search Console apps on iPhone and Android, plus Google's mobile web: free tier, alerts, widgets and platforms side by side, and who should pick which. Google does not make a Search Console app, so a phone gives you two kinds of option: Google's mobile web, or a third-party app built on Google's Search Console API. The apps we track are Search Console for Google, Search Console SEO Tracker, Search Console Mobile and Search Panel on iPhone, SEO Tracker for Search Console on Android, and QueryWatch on both. Their numbers all come from the same API, so what separates them is the shape of the free tier, whether they send alerts, whether they offer widgets, and which devices they run on. ## How this comparison was made Every competitor fact below comes from that app's own store listing as of September 2026, when we last checked it. QueryWatch's facts come from its own listings in October 2026. Listings change, so read each row as a dated snapshot rather than a verdict, and check the store before you decide. Prices are left out on purpose, because they go stale fastest; [the comparison pages](/vs/) carry them for each app we compare there, with the date they were checked. This is also not a census of the stores. New Search Console clients appear regularly, and these are the ones we measure ourselves against. All of them read the same four parts of [Google's Search Console API](https://developers.google.com/webmaster-tools/v1/api_reference_index): search analytics, sitemaps, the site list and URL inspection. That is why the numbers match from app to app, and why none of them can show you what the API does not carry. ## The apps side by side Competitor rows reflect each store listing as of September 2026. | App | Runs on | Free tier | Push alerts | Widgets | |---|---|---|---|---| | Google Search Console, mobile web | Any browser | Everything, free | No traffic alerts; emails about important events | No | | Search Console for Google (Liangxilan) | iPhone, iPad and Mac; iOS 26 or later | Multi-site access is paid | Not listed | Home-screen | | Search Console SEO Tracker (Valet Hero) | iPhone; iOS 17 or later | Unlimited properties need Premium | Yes, plus a weekly digest | Home-screen | | SEO Tracker for Search Console (Valet Hero) | Android | Top 25 queries | On Pro | Home-screen | | Search Console Mobile (Sawyer Billings) | iPhone, iPad, Mac and Vision | Reviews say it asks for payment before showing data | No | No | | Search Panel (Andrew Moloney) | iPhone, Mac and Vision | Not stated in the listing | No | No | | QueryWatch | iPhone on iOS 26 or later; Android 12 or later | Every property, real numbers, no cap | On Pro, with an evidence snapshot | Free: Home Screen and Lock Screen on iPhone, home-screen on Android | ## What each one does well **Search Console for Google** has a broad feature list: flexible date ranges, period comparison, trend charts with drill-down, custom presets, tags, multi-account support, sitemap management, URL inspection, PageSpeed and Core Web Vitals, home-screen widgets and AI-generated reports. It also runs on iPad and Mac. Pick it if you want that breadth on one or two properties, since multi-site access sits behind its paywall. **Search Console SEO Tracker** ships traffic alerts and a Monday summary on iPhone, alongside widgets, a query watchlist, URL inspection, sitemap view, submit and delete, PageSpeed and an offline cache. It runs on iOS 17, which reaches iPhones that QueryWatch, at iOS 26, cannot. Pick it if you want alerts on an older iPhone and are comfortable paying to see all of your properties. **SEO Tracker for Search Console** is the same developer's Android app, with more than 10,000 installs on its listing. Its free tier covers a dashboard, the top 25 queries, sitemaps, PageSpeed and URL inspection; push alerts, a keyword watchlist and unlimited queries are on Pro. Pick it if you want an Android app with a long install history behind it. **Search Console Mobile** is a straightforward stats reader with large scrubbable charts, query, page, country and device breakdowns, custom date ranges, multi-account switching and favourites, on iPhone, iPad, Mac and Vision. Pick it if you want a low-cost paid tier and never need a notification. **Search Panel** offers MCP access, so an AI assistant can read your Search Console data through the app, along with site groups, adding and removing sites and sitemaps, URL inspection and 40 languages. Pick it if that AI access is what you want. QueryWatch does not offer it. **Google's mobile web** is the source of truth for every app on this page. It is complete, free and needs no install, and it is where you verify properties and read manual actions, security issues and the full Page indexing report, none of which the API provides. Pick it whenever you need something the API does not carry. ## Where QueryWatch fits, and where it does not QueryWatch's free tier lists every property your account can access, with real numbers on each and no cap: 28-day performance with deltas, the top 100 queries and pages, striking distance at positions 8 to 20, the top three contributors behind any change, five watchlist saves, widgets, five URL inspections a day and a CSV of the current view. Pro adds push alerts for drops and spikes, new top-10 queries, watched-URL indexing changes and sitemap errors, each with an evidence snapshot, plus 16 months of history, period comparison, white-label PDF reports and a cannibalisation detector. Lock Screen widgets, a white-label PDF and a cannibalisation detector did not appear in any of the other listings above when we checked them. Where it falls short: it needs iOS 26 on iPhone, it has no iPad or Mac layout, no AI reports, no MCP access and no lifetime plan, and it is a brand-new listing next to apps that have been in the stores for longer. If any of those matter to you, one of the apps above is the better fit, and we would rather you knew that before installing. ## Questions to ask before you sign in to any of them Every one of these apps reads your Google data with your permission, so the questions that matter most are about trust rather than charts. Three do most of the work. Does the app talk to Google from your phone, or through its own server? If it sends alerts, where does your credential live while your phone is asleep? And can you delete what it holds without emailing anyone? [Where does your Google token go?](/blog/where-does-your-google-token-go/) has the full list, with our own answers written out. ## Which one to pick 1. **One site, an occasional glance.** The mobile web, or a home-screen shortcut to the performance report. Nothing to install. 2. **An older iPhone, and you want alerts.** Search Console SEO Tracker, because QueryWatch will not install below iOS 26. 3. **An iPad or a Mac.** Search Console for Google or Search Console Mobile. 4. **An AI assistant reading your data.** Search Panel. 5. **Android.** SEO Tracker for Search Console or QueryWatch; [the Android guide](/blog/google-search-console-app-for-android/) covers what each involves and how to set QueryWatch up. 6. **Many client properties, all visible without paying, with alerts and client reports when you need them.** QueryWatch, which is built around that case. Whichever you choose, keep the website a tap away. [Four ways to check Search Console on your iPhone](/blog/check-search-console-on-your-iphone/) covers the options that do not involve an app at all, and [the QueryWatch product page](/google-search-console-app/) has the full feature list for both tiers. Questions: **Is there a free Search Console app for iPhone?** Every app we checked is free to download, but several limit the free tier, by capping properties or queries or, according to reviews, by asking for payment before showing data. QueryWatch shows every property with real numbers on its free tier. Google's own mobile web is free and complete but sends no traffic notifications and has no widgets. **Why do different Search Console apps show the same numbers?** Because they all read the same data from Google's Search Console API. Small differences usually come from the date range, the last day each app treats as complete, or when its cache was last refreshed. **Can a Search Console app replace the website?** No. Property verification, manual actions, security issues and the full Page indexing report are in the web interface and not in the API that apps use. Keep the website for those and use an app for the daily glance and for alerts. **Do I need a separate app for each Google account?** Not usually. Several of the apps listed multi-account support as of their store listings in September 2026, and QueryWatch Pro puts properties from more than one Google account in the same list. On QueryWatch's free tier you use one Google account, with every property it can access. --- ### AI Overviews and AI Mode in Search Console: what the data shows URL: https://querywatch.app/blog/ai-overviews-and-ai-mode-in-search-console/ Published: 8 October 2026 Summary: AI Overview and AI Mode clicks sit inside Search Console's Web totals; the new Generative AI report adds impressions but no clicks. What you can separate. Yes, Search Console includes AI Overviews and AI Mode, but mostly inside your ordinary numbers. Clicks, impressions and positions from both features are counted in the Performance report under the Web search type, mixed in with every other result, and no filter separates them. Since 31 August 2026, Google has also offered every website a Generative AI performance report, which shows how often your pages appeared in AI Overviews and AI Mode; it reports impressions, with no clicks, no position and no queries. ## Are AI Overviews counted in Search Console? Yes. Google's documentation on [AI features and your website](https://developers.google.com/search/docs/appearance/ai-features) says that sites appearing in them "are included in the overall search traffic in Search Console" and are reported "in the Performance report, within the 'Web' search type". Search Console's help on how data is counted sets out three rules for AI Overviews: - **Click:** following a link in an AI Overview to an external page counts as a click. - **Impression:** the standard impression rules apply. - **Position:** an AI Overview occupies a single position in the results, and every link inside it is given that position. The last rule matters most when you read your reports. If an AI Overview sits at the top of the page and cites your article as its fourth link, the impression is recorded at the AI Overview's position, not at a position of its own. ## How is AI Mode counted? AI Mode has counted towards Search Console totals since June 2025, according to Google's log of documentation updates. Its rules are close to those for ordinary results: - **Click:** following an external link in AI Mode counts as a click. - **Impression:** the standard impression rules apply. - **Position:** worked out the same way as on a Google Search results page. - **Follow-up questions:** a follow-up is treated as a new query, and the impressions, positions and clicks in the new response all count against that new query. Search Console does not include data from Search Labs experiments, so a feature still in Labs does not appear in your numbers at all. ## What the Generative AI performance report shows Google announced the report on 3 June 2026, starting with a subset of website owners in the UK, and says it had reached all websites worldwide as of 31 August 2026. In that announcement post, Google put AI Overviews at more than 2.5 billion monthly active users and AI Mode at more than one billion monthly users. The report counts impressions: how many times links to your site were shown to someone in a generative AI feature on Google Search, currently AI Overviews and AI Mode. You can break those impressions down by page, country, device and date, and filter by search type, either Web: text-based or Web: multimodal, the second covering searches made with images, such as Google Lens and Circle to Search. Dates are in Pacific Time, the newest data can be preliminary, and the usual Performance report limits, such as the 1,000-row table, apply. If your site has had too few impressions in these features, the report may not appear. Discover has a separate generative AI report of its own. [Google's help page for the Search report](https://support.google.com/webmasters/answer/16984139) has the details. The data is a subset of the Web search type in the main Performance report. It is not extra traffic on top of it. ## What you can and cannot separate out | Question | Can Search Console answer it? | |---|---| | Total clicks from Google Search, AI features included | Yes: Performance → Search results, Web | | Clicks that came from AI Overviews | No | | Clicks that came from AI Mode | No | | Which pages appeared in AI features, and how often | Yes, as impressions in the Generative AI report | | Countries and devices for those impressions | Yes, in the Generative AI report | | Which queries showed your site in an AI feature | No: the report has no query dimension | | Where your link sat inside an AI Overview | No: every link shares the overview's position | On the clicks it does not itemise, Google's documentation says that "when people click from search results pages with AI Overviews, these clicks are higher quality", meaning visitors are more likely to spend more time on the site. That is Google's claim about searchers in aggregate. Search Console cannot confirm or refute it for your site; your analytics tool can at least show how organic visitors behave once they arrive. ## What this means when clicks drop 1. **Read the shape of the drop first.** Clicks down with impressions steady is a click-through problem. An AI Overview answering the question above your result is one possible cause, alongside a rewritten title, a rich result or another feature taking the space. Search Console cannot tell you which, but it can narrow the field. 2. **Check the same page in the Generative AI report.** If a page that lost clicks shows rising AI feature impressions over the same dates, AI features are a plausible part of the story. If its AI impressions are flat or absent, look elsewhere. 3. **Do not treat a better average position as good news on its own.** A citation in an AI Overview at the top of the page records the overview's position, so average position can improve while clicks fall. Judge position against clicks and CTR, query by query. 4. **Expect longer, conversational queries.** AI Mode follow-ups are counted as new queries, which is one reason question-like queries you never targeted can turn up in your Queries table. 5. **Be careful with impression comparisons across April 2026.** Google's Data anomalies page records a logging error that prevented Search Console from accurately reporting impressions between 13 May 2025 and 27 April 2026. Impressions, CTR and average position were affected; clicks were not. When a comparison includes days on both sides of 27 April 2026, trust the clicks and treat the impressions with suspicion. 6. **Check the property's settings.** If someone set the property's Search generative AI control to Exclude, it stops receiving traffic and impressions from AI Overviews, AI Mode and generative AI features in Discover, and that shows up as a drop of its own. [Search Console metrics explained](/blog/search-console-metrics-explained/) covers how clicks, impressions, CTR and position move each other, and [clicks dropped, now what](/blog/clicks-dropped-what-now/) walks through a full investigation. ## Should you exclude your site from AI features? That is a business decision, and Search Console now makes it an explicit one. The control sits under Settings → Search generative AI and has three options: Include, which is the default; Exclude; and Inherit from parent, for a property that sits inside another. Google rolled it out to all websites worldwide as of 31 August 2026. Its help pages say the setting is not used as a ranking or inclusion signal for other parts of Search, that exclusion generally takes effect within a few days, and that it does not affect AI training, for which Google points to Google-Extended instead. The cost is stated just as plainly: an excluded site receives no traffic or impressions from these features. Look at the Generative AI report before you decide, so you know what you would be giving up. ## Where QueryWatch fits QueryWatch reads the same Web search data through Google's API, so clicks and impressions from AI Overviews and AI Mode are inside the totals it shows, exactly as they are on the web, and it cannot separate them either. It does not show the Generative AI performance report. What it does cover is the start of the investigation above: on Pro, [an alert](/search-console-alerts/) when a property's clicks move well outside their recent average, and on every tier, a change investigation showing the pages and queries the move came from. If those turn out to be question-style queries on informational pages, you know which report to open next on the web. [The product page](/google-search-console-app/) has the rest. Questions: **Does an average position of 1 mean my page was in an AI Overview?** Not necessarily. An AI Overview occupies a single position and every link inside it is given that position, so a cited page can report a high position, but so can an ordinary top result. Search Console does not tell you which of the two it was. **Can I see which queries show my site in AI Overviews or AI Mode?** Not in Search Console. The Generative AI performance report breaks impressions down by page, country, device and date, but it has no query dimension, and the main Performance report does not mark which queries showed an AI feature. **Will excluding my site from AI Overviews hurt my normal rankings?** Google says the Search generative AI control is not used as a ranking or inclusion signal for other parts of Search. Excluding a property does mean it receives no traffic or impressions from AI Overviews, AI Mode or generative AI features in Discover. **Does Google Analytics separate AI Overview traffic?** Google's documentation does not describe a way to do that. It suggests using tools such as Google Analytics to look at conversions and time spent on your site, which tells you how visitors from search behave but not which search feature they clicked. --- ### The Page indexing report explained: why pages aren't indexed URL: https://querywatch.app/blog/page-indexing-report-explained/ Published: 8 October 2026 Summary: Search Console's Page indexing report gives a reason for every URL that isn't indexed. What each reason means, which to fix, and what is normal. The Page indexing report in Google Search Console (Indexing → Pages) shows how many of the URLs Google knows on your site are indexed, and gives a reason for every one that is not. Some reasons are faults you should fix, such as a 404 on a live page, a server error or a stray noindex tag. Many are not faults at all: redirects, canonicalised duplicates and alternate URLs are meant to stay out of the index. Reading the report well mostly means telling those two groups apart. ## Where is the report, and what does the chart show? Open a property in Search Console and choose Indexing → Pages. The top of the report is a chart of two totals over time, indexed and not indexed. Below it, a table headed "Why pages aren't indexed" has one row per reason, each with a source, a validation status and a count of affected pages. Click a row for its trend and a list of example URLs. Two details save confusion later. The example list is capped at 1,000 rows, and Google says it is not guaranteed to show every affected URL even below that. And a filter above the chart switches between "All known pages" (the default), "All submitted pages", "Unsubmitted pages only" and a single sitemap. To see how the pages you care about are doing, filter to the sitemap that lists them; the default view mixes in every parameter URL and old redirect Google has come across. ## Every common reason, and whether to act The report's Source column marks each row as coming from your website or from Google, and Google's help notes that the issues you can generally fix are the ones whose source is the website. The table below groups the reasons by where the cause usually sits; the Source column in your own report is the authority. | Reason | Cause usually sits with | What it means | Act or ignore | |---|---|---|---| | Server error (5xx) | Your site | Googlebot got a 500-level response | Act if the page matters; check Settings → Crawl stats | | Redirect error | Your site | A loop, a chain that is too long, or a bad URL in the chain | Act | | URL blocked by robots.txt | Your site | A robots.txt rule stops Googlebot crawling it | Act if you want it indexed; ignore if deliberate | | URL marked 'noindex' | Your site | A noindex rule in a meta tag or HTTP header | Act if accidental; ignore if deliberate | | Soft 404 | Your site | The page reads as "not found" but returns a success code | Act: return a real 404 or 410, or give it real content | | Blocked due to unauthorized request (401) | Your site | Googlebot was asked to log in | Ignore for private pages; act if the page should be public | | Blocked due to access forbidden (403) | Your site | The server refused Googlebot | Act if public; often a firewall or bot rule | | Not found (404) | Your site | The URL returns 404 | Ignore if removed on purpose; 301 it if it moved | | Page with redirect | Your site | The URL redirects; its target may be indexed | Ignore, unless it is a page you meant to keep | | Alternate page with proper canonical tag | Your site, working as intended | The page points to a canonical that is indexed | Ignore | | Duplicate without user-selected canonical | Both | A duplicate with no declared canonical; Google picked one | Declare a canonical if Google's pick is wrong | | Duplicate, Google chose different canonical than user | Google | Google disagrees with the canonical you declared | Investigate with URL Inspection | | Crawled – currently not indexed | Google | Crawled, but not added to the index | Improve the page, or accept it | | Discovered – currently not indexed | Google | Known, but not crawled yet | Check server health and internal links; wait | In your report the noindex row may read "Excluded by 'noindex' tag" rather than the help page's wording. It is the same reason. Below the main table, an "Improve page experience" section lists URLs that are indexed but have a problem. "Indexed, though blocked by robots.txt" means Google indexed a URL it was not allowed to crawl, usually because other pages link to it. To get it out, remove the robots.txt block and add noindex: Google's documentation says noindex cannot work on a page robots.txt blocks, because Googlebot never fetches it. "Page indexed without content" means Google could not read what was on the page, which deserves an immediate URL inspection. ## The three reasons that need judgement Most rows are mechanical: something on your server says no, and either you meant it or you did not. Three rows are Google's decisions, and they generate most of the questions. "Crawled – currently not indexed" means Googlebot fetched the page and Google chose not to index it. Google's help says it may or may not be indexed in the future, and that there is no need to resubmit it. It is usually a verdict on the page's value, so the fix is the page, not the Request indexing button. [Crawled – currently not indexed](/blog/crawled-currently-not-indexed/) goes through the causes. "Discovered – currently not indexed" means Google knows the URL but has not crawled it, which is why its last crawl date is blank. Google's explanation is that typically, crawling it was expected to overload the site, so the crawl was rescheduled. See [Discovered – currently not indexed](/blog/discovered-currently-not-indexed/). "Duplicate, Google chose different canonical than user" is the canonical row worth reading. "Alternate page with proper canonical tag" means Google agreed with your canonical; this one means it did not. Inspect a URL and compare the User-declared canonical with the Google-selected canonical; internal links, redirects or a sitemap pointing at the other version are the usual culprits. [Alternate page with proper canonical tag](/blog/alternate-page-with-proper-canonical-tag/) covers the harmless sibling. ## How does "Validate fix" work? Once you have fixed every instance of a reason, open its row and click Validate fix. Google recrawls the affected URLs and reports progress as a status: Not started, Started, Looking good, Passed or Failed. You get an email when Google has confirmed the fix on all URLs. 1. Fix every instance first, then start validation. 2. Click Validate fix once, and not again until the run has passed or failed. 3. Give it time. Google says validation typically takes up to about two weeks, and sometimes much longer. 4. If it fails, find the URL that caused the failure in the validation details, fix it and start again. On a large site, Google suggests validating against a sitemap of your most important pages, which can finish faster. For one important URL, the [URL Inspection tool](/blog/url-inspection-and-request-indexing/) tells you its state without waiting for a validation run. ## What is normal? Google's help is plain about this: you should not expect every URL on your site to be indexed, just the canonical ones. A healthy property can show more not-indexed URLs than indexed ones, because every redirect, parameter variant and retired URL Google has seen gets counted somewhere. Three things deserve attention. A falling indexed total, since Google says that ideally the indexed count rises gradually as a site grows. A sudden jump in a website-side reason after a deploy, which usually means a template change: a noindex left over from staging, a canonical pointing every page at the home page, a firewall rule refusing Googlebot. And an important page turning up under any reason at all, easiest to catch by filtering to your main sitemap. Everything else can wait for a quiet afternoon. A fixed issue stays in the table until ninety days pass without a recurrence, so an old row is not necessarily a live problem. ## Where QueryWatch fits QueryWatch is an independent app, not affiliated with Google, and it does not reproduce this report: the Search Console API has no endpoint for the Page indexing breakdown. What the app covers is the URL-level half. The free tier includes 5 URL inspections a day, showing a page's index verdict, coverage state, last crawl and canonical, plus your sitemap list. On Pro you can mark key pages as watched and get a push alert when one changes its index verdict or coverage state, and another when a sitemap's error count rises. [Search Console alerts](/search-console-alerts/) has the details, and [Clicks dropped. Now what?](/blog/clicks-dropped-what-now/) shows where an inspection fits in a traffic investigation. The reference for every reason is Google's own [Page indexing report help page](https://support.google.com/webmasters/answer/7440203). Questions: **Is it bad to have more not-indexed pages than indexed pages?** Not necessarily. Redirects, canonicalised duplicates, parameter URLs and deliberately noindexed pages all count as not indexed, and on many sites they outnumber the real pages. What matters is whether the pages you want people to find are in the indexed total. **Why doesn't the report list every affected URL?** The example table under each reason is capped at 1,000 rows, and Google says it is not guaranteed to show every affected URL even below that number. Filter the report by sitemap, or check individual pages with the URL Inspection tool. **Can I get the Page indexing report through the Search Console API?** No. The public Search Console API covers search analytics, sitemaps, sites and inspection of one URL at a time, but not the Page indexing report itself. Third-party tools can check specific URLs; the full breakdown stays in the web interface. **How long does a fixed issue stay in the report?** Google removes an issue from the table once ninety days pass without a recurrence. Until then the row stays listed, with its validation status, even if every instance has been fixed. --- ### Crawled – currently not indexed: what it means and how to fix it URL: https://querywatch.app/blog/crawled-currently-not-indexed/ Published: 8 October 2026 Summary: Google crawled the page but chose not to index it, for now. What 'Crawled – currently not indexed' means, the usual causes, what to fix and when to wait. "Crawled – currently not indexed" in Google Search Console means Googlebot fetched the page and Google then decided not to add it to its index, at least for now. Google's help says such a page "may or may not be indexed in the future" and that there is no need to resubmit it. The fetch worked, so this is rarely a technical fault. The usual explanation is a judgement about the page: too thin, too similar to another page, or not important enough to keep. The fix is to change the page or its place in your site, not to keep pressing Request indexing. ## What does "Crawled – currently not indexed" mean? It is one of the reasons listed under "Why pages aren't indexed" in the Page indexing report (Indexing → Pages). Crawling and indexing are separate steps. Google's guide to [how Search works](https://developers.google.com/search/docs/fundamentals/how-search-works) puts it plainly: "Indexing isn't guaranteed; not every page that Google processes will be indexed." This status sits in that gap. The fetch succeeded, so the cause is not robots.txt, a server error or a 404; those have rows of their own in [Google's Page indexing report help](https://support.google.com/webmasters/answer/7440203). Google has a last crawl date for the page, and you can see it in URL Inspection. What went against the page was the decision after the crawl, and the report does not say why. The neighbouring status, "Discovered – currently not indexed", is the earlier stage: Google knows the URL but has not fetched it yet, and the last crawl date is blank. That one is about crawling capacity and priority, and it has [its own write-up](/blog/discovered-currently-not-indexed/). ## Is it a problem? That depends entirely on which URLs are listed. Google's help says you should not expect every URL on a site to be indexed, and plenty of pages land here without anyone needing to care: - tag, category and date archives with one or two posts on them - paginated list pages and internal search results - filtered or sorted views of the same products - thin profile, author or attachment pages - old posts that were never more than a paragraph It is a problem when the list includes pages that are supposed to earn traffic: product and service pages, articles you put real work into, landing pages for campaigns. It is also worth a look when the count jumps suddenly across the whole site. A quick way to separate the two: in the Page indexing report, switch the filter from "All known pages" to "All submitted pages". That narrows the list to URLs in your sitemaps, which are, in theory, the ones you want indexed. ## What causes it? Google's guide lists three common indexing issues: low-quality content on the page, robots meta rules that disallow indexing, and site design that makes indexing difficult. A noindex would show up as its own reason, so for this status the first and third are the ones to check. In practice they take a few recognisable forms. **Thin pages.** Very little text, mostly boilerplate, or a template waiting for content that never arrived. **Near-duplicates.** Location pages that differ by nothing but the town name, product variants with identical descriptions, text that also lives on another site, or two of your own pages answering the same question. Google groups similar pages and picks one to represent the group; the others are left out, sometimes under this reason and sometimes under one of the duplicate reasons. If two of your pages compete for the same queries, [the cannibalisation check](/blog/keyword-cannibalization-search-console/) is the same problem seen from the performance side. **Weak signals of importance.** Pages linked from nowhere except the sitemap, or buried several clicks deep in pagination, tell Google little about why they matter. **Rendering.** If the main content depends on JavaScript that fails or times out, Google may have seen a near-empty page. The live test in URL Inspection includes a screenshot of the page as Google renders it. **Newness.** For a page published last week, the decision may not be final. ## How to fix it 1. List the affected URLs and sort them into two piles: should be indexed, and does not need to be. 2. For the second pile, decide deliberately. Leave them, add noindex, or merge them into a stronger page with a 301 redirect. If a template keeps generating low-value URLs (a tag page per tag, however rarely used), fix the template. 3. For the first pile, open one URL in URL Inspection and run Test live URL. Check that the screenshot and the HTML show your real content, and that the page is not blocked or noindexed by accident. 4. Make the page worth a place in the index. Add what is missing: original information, specifics, the answer a searcher came for. Merge pages that overlap, and make the survivors clearly different from each other. 5. Link to it from relevant pages that are already indexed, with descriptive anchor text, and keep it in your sitemap. 6. Request indexing once, after the change. Google's documentation says requesting a recrawl of the same URL several times will not get it crawled any faster. 7. Check back in a week or two with URL Inspection, not every morning. [URL Inspection and Request indexing](/blog/url-inspection-and-request-indexing/) covers steps 3 and 6 in detail, including what the live test cannot tell you. ## When to wait instead Waiting is the right call in three cases. A new page or a new site, because Google says crawling can take anywhere from a few days to a few weeks and indexing decisions follow. A page you have just improved, because Google has to recrawl it before anything can change. And any URL you have decided does not need to rank, which can sit in this status indefinitely. What does not help is churning: rewriting the page every few days, requesting indexing after each edit, or changing the URL. Make one substantial change, then give it time. ## Watching the pages that matter QueryWatch is an independent app, not affiliated with Google, and it does not show the Page indexing report's URL lists; those stay in the web interface. It helps at the level of individual pages. The free tier includes 5 URL inspections a day, which show a page's verdict, coverage state, last crawl date and canonical, so you can check from your phone whether an improved page has made it in. On Pro you can mark key pages as watched and get a push alert when one changes its index verdict or coverage state, whether that is a page finally getting indexed or an important one slipping out. [Search Console alerts](/search-console-alerts/) explains how those alerts work, and [the Page indexing report explained](/blog/page-indexing-report-explained/) covers every other reason you will meet in the same table. Questions: **Should I click Request indexing for a page that is crawled but not indexed?** Not as a first step. Google's help says there is no need to resubmit these URLs, and Google's documentation says requesting a recrawl of the same URL several times does not get it crawled any faster. Change the page first, then request indexing once if it matters. **Does Crawled – currently not indexed mean my site has a penalty?** No. It is an ordinary indexing status, not a manual action. Google reports manual actions in the Manual actions report and in Search Console's messages, so you can rule one out in a minute. **How long does it take for a crawled page to be indexed?** Google gives no timetable for this status. Its help says the page may or may not be indexed in the future, and its documentation says crawling in general can take from a few days to a few weeks. If an improved page is still excluded after several weeks, look again at its content and its internal links. **Is it a problem if most of my site is crawled but not indexed?** A handful of URLs in this status is normal on any site. A large share of your important pages is a different signal, usually about duplication or thin pages across the site rather than one URL, and it calls for a review of which pages deserve to exist. --- ### Discovered – currently not indexed: causes and how to fix it URL: https://querywatch.app/blog/discovered-currently-not-indexed/ Published: 8 October 2026 Summary: Google knows the URL but hasn't crawled it yet. Why 'Discovered – currently not indexed' happens, how it differs from Crawled, and what to fix first. "Discovered – currently not indexed" in Google Search Console means Google knows a URL exists, usually from a link or a sitemap, but has not crawled it yet, so the report shows no last crawl date. Google's help says that typically it wanted to crawl the URL but expected that to overload the site, so it rescheduled the crawl. The fixes are on the crawling side: a faster and more reliable server, fewer low-value URLs competing for Googlebot's time, and stronger internal links to the pages that matter. ## What does "Discovered – currently not indexed" mean? Google finds new URLs in two main ways: by extracting links from pages it already knows, and from sitemaps you submit. Finding a URL is the first step. Fetching it is the second, and deciding whether to index it is the third. A URL with this status has completed step one and is waiting on step two. Because nothing has been fetched, Google has not yet formed any view of the content. That makes this status quite different from its neighbour in the Page indexing report (Indexing → Pages), even though the names are almost identical. ## How is it different from "Crawled – currently not indexed"? | | Discovered – currently not indexed | Crawled – currently not indexed | |---|---|---| | Has Google fetched the page? | No | Yes | | Last crawl date | Blank | Shown | | What is holding it back | Crawl scheduling: capacity and priority | A decision made after the crawl | | Typical causes | Slow or failing server, too many URLs, weak internal links | Thin, duplicate or low-value content | | Where to look first | Settings → Crawl stats, your URL inventory, internal links | The page itself, through URL Inspection | In short, Discovered is a crawling problem and Crawled is an indexing problem. If a URL moves from the first to the second, Google has now looked at it and declined, and the advice in [Crawled – currently not indexed](/blog/crawled-currently-not-indexed/) takes over. ## Why does it happen? Google's [crawl budget guide](https://developers.google.com/search/docs/crawling-indexing/large-site-managing-crawl-budget) describes two forces, crawl capacity and crawl demand. They tend to show up in three ways. **The server cannot take more.** Google sets a crawl capacity limit so that it can crawl your important content without overloading your server. The guide says the limit goes up when a site responds consistently and its response times hold steady or improve, and comes down when the site slows or returns server errors, including 5xx and HTTP 429 responses. A site on cheap shared hosting, behind an aggressive rate limiter, or with slow database queries on every page can keep Googlebot at a crawl. **There are too many URLs.** Without guidance, the guide says, Google tries to crawl all or most of the URLs it knows about. If most of those are duplicates or pages nobody needs, crawl time goes on them instead of your new article. The usual sources are faceted navigation, sort and filter parameters, tracking parameters, session IDs, calendar pages that go on forever, and tag pages for every tag ever used. **There is not enough reason to crawl yet.** Crawl demand depends partly on how popular your URLs are and how stale Google's copy of them has become. A page linked from nowhere except the sitemap, or reachable after a dozen clicks through pagination, has little pulling it up the queue. ## Is this a crawl budget problem? Sometimes. Google's crawl budget guide is written for large sites (a million or more unique pages, changing weekly), medium or larger sites (10,000 or more pages changing daily), and sites with a large portion of their URLs classified as "Discovered – currently not indexed". For other sites, Google says, keeping the sitemap up to date and checking the Page indexing report is adequate. So the size of the list matters. A small site with a dozen URLs in this status is usually looking at weak internal links, a slow server or simple patience. A large site with a big share of its catalogue stuck here probably has a genuine crawl budget problem, and the guide is worth reading end to end. ## How to fix it 1. Check whether the listed URLs matter. Switch the report filter to "All submitted pages". If the full list is mostly parameter URLs and filtered views, the fix is fewer of those URLs, not more crawling. 2. Check server health in Settings → Crawl stats ([Google's help for the report](https://support.google.com/webmasters/answer/9679690)). Look at average response time, the host status checks (robots.txt fetching, DNS resolution, server connectivity) and the breakdown of responses. The report is available for root-level properties, meaning a Domain property or a root URL-prefix property. 3. Fix what slows Googlebot down: server errors, timeouts, and firewall or CDN rules that answer it with 429 or 403. 4. Shrink the URL inventory. Consolidate duplicates with canonical tags or 301 redirects, block crawling of endless parameter spaces in robots.txt, return 404 or 410 for pages that are gone, and fix soft 404s. Google's guide lists each of these, along with avoiding long redirect chains. 5. Link to the pages that matter from pages Google already crawls: navigation, hub pages, related-content blocks. Fewer clicks from the home page is better. 6. Keep your sitemap current, with accurate lastmod dates for pages that changed. [Submitting a sitemap](/blog/submit-a-sitemap-to-google/) covers the details. 7. For a few important pages, use Request indexing in the [URL Inspection tool](/blog/url-inspection-and-request-indexing/). It needs owner or full user access and has a daily quota, so it is for priorities, not bulk. ## When to wait A new site, or a batch of new pages published at once, often spends time here before crawling catches up; Google says crawling can take anywhere from a few days to a few weeks. After you fix server problems, give it time too. Google's Crawl stats documentation says you cannot tell Google to increase your crawl rate, so the improvement shows up as Googlebot adjusting to a healthier server rather than overnight. ## Where QueryWatch fits QueryWatch is an independent app, not affiliated with Google. It does not show Crawl stats or the Page indexing report's URL lists, neither of which is in the Search Console API, so that diagnosis happens in the web interface. What it does is keep track of the pages you are waiting on. The free tier includes 5 URL inspections a day, showing each page's coverage state and last crawl date, and your sitemap list. On Pro you can mark pages as watched and get a push alert when one changes its index verdict or coverage state, so you hear when a page finally gets crawled and indexed instead of re-checking it every morning. Pro also alerts you when a sitemap's error count rises. [Search Console alerts](/search-console-alerts/) has the details, and [the Page indexing report explained](/blog/page-indexing-report-explained/) covers every other reason in the same table. Questions: **Why is the last crawl date blank for these URLs?** Because Google has not crawled them yet. Google's help says it found the URLs but rescheduled the crawl, which is why the report shows no last crawl date. Once a URL is crawled it moves to another status, such as indexed or Crawled – currently not indexed. **Can I ask Google to crawl my site faster?** Not directly. Google's Crawl stats documentation says you cannot tell Google to increase your crawl rate; Googlebot adjusts to how quickly and reliably your server responds. Faster responses and fewer server errors are the levers you control. **Will submitting a sitemap fix it?** Not on its own. A URL in this status is already known to Google, often from the sitemap itself, so discovery has worked. What moves it along is a responsive server, fewer low-value URLs competing for crawls, and links from pages Google already visits. **Should I use Request indexing on these URLs?** For a handful of important pages, it is reasonable: an owner or full user can request indexing from the URL Inspection tool, within a daily quota. For hundreds or thousands of URLs it does not scale, and fixing server speed, URL bloat and internal links is the real work. --- ### Alternate page with proper canonical tag: should you worry? URL: https://querywatch.app/blog/alternate-page-with-proper-canonical-tag/ Published: 8 October 2026 Summary: Why Search Console lists www, http, slash and parameter URLs as 'Alternate page with proper canonical tag' or 'Page with redirect', and when to act. "Alternate page with proper canonical tag" in Google Search Console means Google found a URL that names a different URL as its canonical, agreed with that choice, and indexed the canonical instead. Google's help says that in this case "there is nothing you need to do". Its sibling, "Page with redirect", means the URL redirects somewhere else, so the target can be indexed but the redirecting URL will not be. Both statuses usually show your canonicalisation working; they matter when a page you wanted in search turns up in either list. ## What do the two statuses mean? Both sit under "Why pages aren't indexed" in the Page indexing report (Indexing → Pages), and neither is an error. Google describes "Alternate page with proper canonical tag" this way: "This page correctly points to the canonical page, which is indexed, so there is nothing you need to do." The URL served a page with a canonical tag naming another URL, and Google indexed that other URL. "Page with redirect" is described as "a non-canonical URL that redirects to another page", and Google adds: "As such, this URL will not be indexed." The redirect target is judged on its own merits. The status to watch is a third one, "Duplicate, Google chose different canonical than user". That means you declared a canonical and Google picked something else. The two here mean Google did what you asked. ## Why do they appear? To a crawler, every variant of an address is a separate URL. One page on your site can be reachable as: | Variant | Example | |---|---| | www and non-www | https://www.example.com/pricing and https://example.com/pricing | | http and https | http://example.com/pricing and https://example.com/pricing | | Trailing slash | /pricing and /pricing/ | | Parameters | /pricing?utm_source=newsletter, /pricing?gclid=…, /shop?sort=price | Google finds these through old links, other people's links, ad clicks, sitemaps and your own templates. Google's documentation is clear that "some duplicate content on a site is normal and it's not a violation of Google's spam policies"; it groups the duplicates, picks one, and crawls the canonical most regularly and the duplicates less often. Whether you see the www and http variants at all depends on the property. A Domain property covers every subdomain and protocol, so all of them land in one report. A URL-prefix property for https://example.com/ does not include www or http URLs. [Domain vs URL-prefix properties](/blog/domain-vs-url-prefix-property/) explains the difference. ## A real example: our own site In October 2026, Search Console emailed us about querywatch.app, this site. Four www URLs were listed as "Alternate page with proper canonical tag". When Google crawled them, the www addresses served the same pages as the apex domain, and each page's canonical tag pointed to the apex version, so Google indexed querywatch.app and set the www copies aside. The http://www address, which redirects, was reported alongside them. Nothing was broken. The canonical tags did their job, and Google's own verdict was that there was nothing to do. What the email did point at was untidiness: the www hostname was serving full pages instead of sending visitors and crawlers straight to the apex domain. That is what the clean-up below is for. ## When is it a problem? Check one URL before deciding. Run it through [URL Inspection](/blog/url-inspection-and-request-indexing/) and compare the User-declared canonical with the Google-selected canonical, then inspect the canonical itself to confirm it is indexed. Then match what you find against this list: - **Harmless:** www, http, slash and parameter variants that point at the URL you prefer. Tidy them up when convenient. - **A problem:** a page you want indexed is listed as an alternate. Its canonical tag points somewhere else, often because of a copied template or a plugin setting. - **A problem:** many unrelated pages all canonicalise to one URL, such as the home page. That is a template bug, and it can take the affected pages out of the index. - **A problem:** an important page appears under "Page with redirect" and nobody meant to redirect it. - **Worth a look:** either count jumps after a deploy or a migration. Inspect a sample before assuming it is fine. ## The 301 clean-up Google's guide to [consolidating duplicate URLs](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls) ranks the signals by strength: redirects and rel="canonical" are strong signals, sitemap inclusion is a weak one. It recommends permanent redirects when you are retiring a duplicate, server-side for the quickest effect, and notes that Google prefers HTTPS over HTTP as canonical unless something conflicts. For hostname and protocol variants, a redirect is the right tool, because nobody needs to read both. 1. Pick one canonical form: https, either www or the apex domain, and one trailing-slash convention. 2. Redirect every other host and protocol combination to it with a single permanent server-side redirect ([301 or 308](https://developers.google.com/search/docs/crawling-indexing/301-redirects)), keeping the path and query string. Send http://www straight to the final URL in one hop rather than through https://www; Google's crawl budget guide advises avoiding long redirect chains. 3. Keep a self-referencing, absolute canonical tag on every canonical page. It handles the variants a redirect should not touch, such as tracking parameters. 4. Make internal links, sitemaps and hreflang annotations use the canonical form and nothing else. 5. Do not use robots.txt or the Removals tool to hide variants. Google's guide says neither is for canonicalisation. On Nginx, the redirect for a www host is a few lines (certificate settings omitted): ```nginx server { listen 443 ssl; server_name www.example.com; return 301 https://example.com$request_uri; } ``` Most hosting platforms and CDNs offer the same thing as a redirect rule. Afterwards, expect the www URLs to move from "Alternate page with proper canonical tag" to "Page with redirect" as Google recrawls them. That is the intended end state, not a new problem, and you do not need to validate it. ## Where QueryWatch fits QueryWatch is an independent app, not affiliated with Google. Its URL inspection, 5 a day on the free tier, shows the Google-selected canonical next to the canonical you declared, so you can check one of these URLs from your phone. On Pro you can watch your key pages and get a push alert when one changes its index verdict or coverage state, which catches a deploy that quietly points a canonical tag at the wrong place. [The Google Search Console app page](/google-search-console-app/) lists what is free and what is Pro, and [the Page indexing report explained](/blog/page-indexing-report-explained/) covers the other reasons in the same table. Questions: **Should I remove the canonical tag so the alternate page gets indexed?** No, unless that page really should be the indexed version. In that case it needs a self-referencing canonical and the other version should point to it. If the two URLs show the same content, leave the tag alone: one indexed version is the goal. **Do URLs listed under Page with redirect hurt my site?** No. Google's help describes them as non-canonical URLs that redirect elsewhere and says they will not be indexed, while the redirect target can be. A long list of old redirected URLs is what a site that has changed over the years looks like. **Should I use a 301 redirect or a canonical tag for www and non-www?** A permanent server-side redirect, because nobody needs to read both hostnames. Google treats both redirects and canonical tags as strong signals, but a redirect also stops the duplicate being served at all. Canonical tags suit duplicates that must stay reachable, such as URLs with tracking parameters. **Why do http and www URLs appear when my site has always used https?** The report counts every URL Google knows about, including ones it found through old links and other sites. A Domain property covers every protocol and subdomain, so those variants are reported next to your main pages. --- ### URL Inspection and Request indexing: how to get a page indexed URL: https://querywatch.app/blog/url-inspection-and-request-indexing/ Published: 8 October 2026 Summary: What Search Console's URL Inspection tool shows, how Request indexing and its quota work, the API's 2,000-a-day limit, and how to get a page indexed. The URL Inspection tool in Google Search Console shows what Google knows about a single URL: whether it is indexed, which canonical Google chose, when Googlebot last crawled it, and whether crawling and indexing were allowed. "Test live URL" checks the version on your server right now, and "Request indexing" asks Google to recrawl the page. Requests need owner or full user access, are subject to a daily quota Google does not publish, and do not guarantee the page will be indexed. ## How do you open the URL Inspection tool? Paste the full URL into the inspection bar at the top of any Search Console screen, or use the inspect link next to a URL in most reports. The URL has to be in the property you have open, so a www URL cannot be inspected from a URL-prefix property for the non-www site. Permissions matter here. Google's permissions table gives owners and full users the whole tool and restricted users a fetch-only view, and Google's documentation says you must be an owner or full user to request indexing. ## What does the inspection result show? The result describes the most recently indexed version of the page, not the live one. At the top is a verdict: "URL is on Google", "URL is on Google, but has issues", "URL is not on Google" or "URL is an alternate version". Underneath, the page indexing section breaks that down: | Field | What it tells you | |---|---| | Sitemaps | Submitted sitemaps (or ones listed in robots.txt) that include the URL | | Referring page | A page Google may have used to discover the URL | | Last crawl | When Googlebot last crawled the page | | Crawled as | Whether the mobile or desktop crawler fetched it | | Crawl allowed? | Whether robots.txt blocked crawling | | Page fetch | Whether Google could get the page from your server | | Indexing allowed? | Whether a noindex rule blocked indexing | | User-declared canonical | The canonical your page declares | | Google-selected canonical | The canonical Google chose | Below that sit enhancements such as breadcrumbs and other rich results. A lot of diagnosis happens in the canonical pair. When the Google-selected canonical is a different URL from the one you inspected, Google has indexed that URL in place of this one, and [Alternate page with proper canonical tag](/blog/alternate-page-with-proper-canonical-tag/) explains when that is fine. ## What does the live test add? "Test live URL" fetches the page as it is now. It is the place to confirm a fix before you ask Google to recrawl, and it is where the screenshot lives: Google's help says screenshots are not available for the indexed version. "View tested page" adds the HTML returned, the HTTP headers, JavaScript console output and the page resources loaded. A screenshot with your main content missing often points at JavaScript that failed or a resource Google could not load. Know its limits. Google says a passing live test confirms that Google can access the page for indexing; it does not mean the page will be indexed. The live test cannot tell you whether the page is a duplicate or an alternate, or whether the tested version will be chosen as canonical. Google's help also notes a per-property daily limit on live inspections. ## How does Request indexing work? 1. Inspect the URL. 2. If you have changed the page, run Test live URL first. Google's help says you cannot request indexing for a page the live test considers non-indexable. 3. Click Request indexing. 4. Leave it alone, and check back with another inspection in a week or two. Google's documentation is direct about what the button does and does not do. There is a quota for submitting individual URLs, and the number is not published. Requesting a recrawl of the same URL several times will not get it crawled any faster. Crawling can take anywhere from a few days to a few weeks. And a request "does not guarantee that the page will appear in the Google Index". For large numbers of URLs, Google's advice is to submit a sitemap. Use it for a new page that matters, a significant update to an important page, or a key page where you have just fixed a noindex, robots.txt or server error. Skip it for pages listed as "Crawled – currently not indexed" that you have not changed; Google's help says there is no need to resubmit those, and [the fix is the page](/blog/crawled-currently-not-indexed/). ## What are the URL Inspection API limits? Search Console's public API includes the URL Inspection API, whose index.inspect method returns much of the same index data as the web tool: verdict, coverage state, robots.txt state, indexing state, last crawl time, page fetch state, both canonicals, sitemaps, referring URLs and the crawler used. Google's [usage limits page](https://developers.google.com/webmaster-tools/limits) sets the quota: - 2,000 queries per day and 600 per minute for each site (property) - 10,000,000 queries per day and 15,000 per minute for each Google Cloud project Two things the API cannot do. It reports on the indexed version, not the live page; Google's reference says you cannot test the indexability of a live URL through it. And it cannot request indexing: the Search Console API's resources are search analytics, sitemaps, sites and URL inspection, none of which submits a URL for crawling. Google's separate Indexing API is restricted to pages with JobPosting or BroadcastEvent embedded in a VideoObject, and is not a route for ordinary pages. ## How do you get Google to index a page? 1. Make it indexable: a 200 status, no noindex, not blocked in robots.txt, and a self-referencing canonical. 2. Make it worth indexing. A page that duplicates another, or says very little, is the classic "Crawled – currently not indexed" case. 3. Link to it from pages Google already crawls and indexes, with descriptive anchor text. 4. Include it in your sitemap; [submitting a sitemap](/blog/submit-a-sitemap-to-google/) covers how. 5. Inspect it, run the live test, and request indexing once. 6. Check again after a week or two. If it sits at "Discovered – currently not indexed", the problem is crawling, and [that post](/blog/discovered-currently-not-indexed/) covers it. ## URL inspection in QueryWatch QueryWatch is an independent app, not affiliated with Google, and it reads the URL Inspection API described above. On the free tier you get 5 URL inspections a day, each showing the verdict, coverage state, last crawl, robots.txt state and the Google-selected canonical next to the one you declared. Pro removes the app's daily cap, though Google's 2,000-a-day per-property quota still applies, and adds watched URLs: mark the pages that matter and get a push alert when one changes its index verdict or coverage state. Live tests and Request indexing are not in the API, so for those you still need Search Console itself. [The app page](/google-search-console-app/) lists what is free and what is Pro, and [Search Console alerts](/search-console-alerts/) covers the watched-URL alert. For the full field-by-field reference, see Google's [URL Inspection tool help](https://support.google.com/webmasters/answer/9012289). Questions: **How many URLs can I submit with Request indexing per day?** Google does not publish the number. Its documentation says there is a quota for submitting individual URLs and a daily limit on index requests, and it recommends a sitemap when you have many URLs. Treat the button as something for a handful of important pages. **Can a third-party app or the API request indexing for me?** Not through the Search Console API, which can inspect a URL's index status but has no method for requesting indexing. Google's separate Indexing API is limited to pages with JobPosting or BroadcastEvent structured data, so for ordinary pages the Request indexing button in Search Console is the route. **URL Inspection says the URL is on Google, so why can't I find it in search?** Being indexed means Google can show the page, not that it will rank for the query you typed. Search for a distinctive phrase from the page, and check the Performance report to see which queries it does appear for. **Is there a limit on live tests?** Yes. Google's help says there is a per-property daily limit of live inspections, separate from the limit on indexing requests. The live test also needs the URL to be reachable from the internet without a login. --- ### How to submit a sitemap to Google, and fix "Couldn't fetch" URL: https://querywatch.app/blog/submit-a-sitemap-to-google/ Published: 8 October 2026 Summary: Submit a sitemap under Indexing → Sitemaps in Search Console. What Success, Has errors and Couldn't fetch mean, the 50,000-URL limit, and how to fix each. To submit a sitemap to Google, open your property in Search Console, go to Indexing → Sitemaps, paste the sitemap's URL into "Add a new sitemap" and press Submit. Google fetches it straight away and reports one of three statuses: Success, Has errors or Couldn't fetch. A single sitemap can list up to 50,000 URLs or 50 MB uncompressed, so larger sites split it and submit a sitemap index. You can also list the sitemap in robots.txt, which needs no Search Console access at all. The rest of this post covers what Google accepts, what each status means, and how to fix Couldn't fetch. ## What does Google accept in a sitemap? Google reads XML sitemaps, plain-text sitemaps (one URL per line), and RSS or Atom feeds. A sitemap index, a sitemap of sitemaps, is accepted too. The rules worth checking first are short: - Every URL must be fully qualified and absolute: `https://example.com/pricing`, not `/pricing`. - The file must be UTF-8 encoded. - One sitemap holds at most 50,000 URLs and 50 MB uncompressed. Past either limit, split it and list the parts in an index. - A sitemap index can list up to 50,000 sitemaps, but it cannot list other index files. - Google uses `` when it is consistently and verifiably accurate, and ignores `` and ``. Google recommends posting the sitemap at the root of the site. It also has to match the property you submit it in: a sitemap for `http://example.com` will not show in the report for `https://example.com`, and www versus non-www mismatches produce "Path mismatch" errors. If you are unsure which property type you have, [Domain vs URL-prefix properties](/blog/domain-vs-url-prefix-property/) explains the difference. ## How to submit a sitemap in Search Console 1. Check your access. Google's Sitemaps help says you need owner permissions to submit; its permissions table also lists full users. If the submit box does nothing for you, ask an owner or use robots.txt instead. 2. Publish the sitemap on the site, ideally at the root, for example `https://example.com/sitemap.xml`. 3. Test it. Paste the sitemap URL into URL Inspection and run a live test; "Page fetch" should be Successful and "Crawl allowed?" should say Yes. 4. Open Indexing → Sitemaps, paste the URL into "Add a new sitemap" and click Submit. 5. Google fetches the file right away. If the status is anything other than Success, click the row for the error details. Crawling the URLs inside takes longer, and Google is clear that not every URL listed will be crawled. A sitemap is a hint about what exists, not an instruction to index it. ## The robots.txt line Any crawler that reads your robots.txt can find your sitemap from one line: ``` Sitemap: https://example.com/sitemap.xml ``` Google picks it up the next time it crawls robots.txt. This is the route to use when you have no Search Console access, and it is worth having even when you do, because Bing and other search engines read the same line. Sitemaps found this way also count as "submitted" in the Page indexing report's sitemap filter. The old habit of pinging Google with a URL whenever the sitemap changed is gone: Google announced in June 2023 that the sitemaps ping endpoint was going away. Its current documentation lists three ways in: the Sitemaps report, the Search Console API and robots.txt. ## What the sitemap statuses mean | Status | What Google says it means | What to do | |---|---|---| | Success | The sitemap was loaded and processed with no errors | Nothing. Google will recrawl it periodically | | Has errors | The sitemap was fetched but has one or more errors | Open the row and fix the listed errors; URLs Google could parse are still queued for crawling | | Couldn't fetch | The sitemap could not be fetched at all | Work through the causes below, then resubmit | On the top-level list, a sitemap with problems may also show a count such as "Sitemap had 3 errors". The details page names each one. The errors you are most likely to meet are Parsing error, Invalid URL, Invalid date, Too many URLs, Sitemap file size error, Empty sitemap, Compression error, the two Path mismatch variants, and "Sitemap contains urls which are blocked by robots.txt". ## How to fix "Couldn't fetch" Google's help lists five causes. Check them in this order, because the first three cover most cases. 1. **The URL is wrong.** A typo, a missing trailing segment, or the sitemap living at `/sitemap_index.xml` when you submitted `/sitemap.xml`. Open the URL in a browser; if it returns a 404, that is your answer. 2. **robots.txt blocks it.** A broad `Disallow` rule can catch the sitemap itself. Run URL Inspection's live test on the sitemap URL and check that "Crawl allowed?" is Yes. 3. **The server failed.** A timeout, a 5xx, or a firewall or bot-protection rule that challenges Googlebot. "Page fetch" in the live test should be Successful. Google notes that transient errors may clear on their own, so wait and see whether it persists. 4. **Low crawl demand for the sitemap.** Google lists this as a cause in its own words. On a small or new site it usually resolves with time. 5. **An unresolved manual action.** Rare, but open the Manual actions report and rule it out; it takes ten seconds. Google retries a failed fetch for a few days, then stops. Once you have fixed the cause, submit the sitemap again as a new request. Google's [Sitemaps report help](https://support.google.com/webmasters/answer/7451001) has the full error list with a fix for each. ## Removing a sitemap does less than you think Open a sitemap's details, choose the more-options menu and select "Remove sitemap", and it disappears from the report. Google does not forget it, though: the sitemap and every URL in it stay known. To stop Google visiting the sitemap itself, block it in robots.txt, delete the file, or serve it with a noindex response header. Removing a sitemap from the report is housekeeping, not a de-indexing tool. ## What to look at after Success A successful sitemap shows when Google last read it and how many pages and videos it discovered. Discovered is not indexed. The useful view is the Page indexing report (Indexing → Pages) filtered to that sitemap, using the dropdown above the chart: "All submitted pages" or the specific sitemap URL. That shows how many of the URLs you said matter are actually in the index, and why the rest are not. [The Page indexing report explained](/blog/page-indexing-report-explained/) covers every reason you will see there. Google's [sitemap documentation](https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap) has the format details if you build sitemaps by hand. ## A note on Bing and IndexNow Bing reads sitemaps too, submitted in Bing Webmaster Tools or found through the same robots.txt line, and its webmaster blog calls `` "a key signal" for deciding what to recrawl. Bing also supports IndexNow, a protocol for notifying search engines the moment a URL changes. The participating engines listed on indexnow.org are Microsoft Bing, Naver, Seznam.cz, Yandex and Yep. Google is not on the list, so IndexNow does nothing for your Google indexing; your sitemap and robots.txt line do that job. ## Where QueryWatch fits QueryWatch reads your sitemaps from Google's Search Console API, so on an iPhone or Android phone you can see each sitemap for every property, with when it was last read and its error and warning counts. That list is on the free tier. Submitting and deleting sitemaps from the phone is Pro. It is also the one moment the app asks Google for write access: the extra permission is requested the first time you submit or delete, never at sign-in. Deleting in the app does exactly what "Remove sitemap" does in Search Console, with the same caveat above. Pro also includes a sitemap error alert, a push when a submitted sitemap's error count rises or the sitemap disappears from Search Console, which is often the first sign that a deploy broke something. The relay behind it checks every six hours; [the alerts page](/search-console-alerts/) explains how, and [the app page](/google-search-console-app/) covers the rest. QueryWatch is an independent app and is not affiliated with Google. Questions: **Do I need to resubmit my sitemap every time I publish a page?** No. Once a sitemap has been fetched successfully, Google recrawls it periodically on a schedule of its own. Resubmitting is optional and mostly worth doing after large changes, such as a migration or a new section of the site. **Does submitting a sitemap guarantee my pages get indexed?** No. Google describes a sitemap as a hint. It helps Google discover URLs, but whether each one is crawled and indexed depends on the page itself, and the Page indexing report is where you see the outcome. **Can I submit a sitemap without owner access to the property?** Google's Sitemaps report help says submitting needs owner permissions, while its user permissions table also lists full users. If you cannot submit in Search Console, add a Sitemap line to robots.txt, which Google reads without any Search Console access. **Does Google still support the sitemap ping URL?** Google announced in June 2023 that its sitemaps ping endpoint was going away. Its current sitemap documentation lists the Sitemaps report, the Search Console API and a Sitemap line in robots.txt as the ways to tell Google about a sitemap. --- ### Domain vs URL-prefix property in Search Console: which to use URL: https://querywatch.app/blog/domain-vs-url-prefix-property/ Published: 8 October 2026 Summary: A Domain property covers every subdomain and protocol and needs DNS verification; a URL-prefix property covers one exact prefix. Which to choose, and why. A Domain property in Google Search Console (`example.com`) covers every subdomain and every protocol, so www, m., http and https all land in one set of data, and the sole way to verify it is a DNS record. A URL-prefix property (`https://www.example.com/`) covers nothing but URLs that begin with that exact string, protocol included, and can be verified several ways: an HTML file, a meta tag, Google Analytics, Google Tag Manager or DNS. If you can edit the domain's DNS, start with a Domain property, then add URL-prefix properties for any section you want to report on by itself. ## What each property type covers | | Domain property | URL-prefix property | |---|---|---| | Written as | `example.com` (no protocol, no www) | `https://www.example.com/` | | Subdomains | All of them: www, m, shop, blog | None beyond the one in the prefix | | Protocols | http and https together | The one in the prefix | | Paths | The whole domain | Everything under the prefix, such as `/blog/` | | Verification | DNS record | HTML file, HTML tag, Google Analytics, Google Tag Manager, DNS | | In the Search Console API | `sc-domain:example.com` | `https://www.example.com/` | Google's own example, from its [help page on adding a property](https://support.google.com/webmasters/answer/34592), makes the difference concrete. A Domain property for `example.com` includes `http://example.com/dresses/1234`, `https://example.com/dresses/1234`, `http://www.example.com/dresses/1234` and even `http://support.m.example.com/dresses/1234`. A URL-prefix property for `http://example.com/` includes the first of those and none of the others: not the https version, not the www version. Two details trip people up. A Domain property is entered without "www"; Google says not to include it. And a Domain property for a subdomain does not reach upwards: `fish.example.com` contains no data about `example.com`, because a child domain does not contain its parent. ## How to verify a Domain property 1. Open the property selector at the top of any Search Console page and choose "Add property". 2. Pick Domain and enter the bare domain, for example `example.com`. 3. Search Console gives you a DNS record to add. Depending on how your domain is set up, it is a TXT record or a CNAME record. 4. For some domain providers, Google can add the record for you after you sign in to the provider. Otherwise, add it yourself in your DNS settings. 5. Click Verify. Google warns that a provider can take two or three days to start serving a new record, so if it fails, wait a day and try again. 6. Leave the record in place. Google's help is explicit: to stay verified, do not remove it after verification succeeds. Data starts to appear in a new property within a few days. ## How to verify a URL-prefix property A URL-prefix property accepts every method, which is why it is the usual choice when DNS is out of reach: - **HTML file.** Upload a file Google gives you to the site. Deleting it later loses you the verification. - **HTML tag.** A meta tag in the `` of the homepage. You need to be able to edit the page source, and the homepage has to load for logged-out visitors. - **Google Analytics.** Works if the homepage carries an analytics.js or gtag.js snippet and you have edit rights on that Analytics account, signed in with the same Google account. - **Google Tag Manager.** Needs Publish or Admin permission on the container, again with the same Google account. - **DNS record.** The same method as a Domain property, and Google notes that using it on a URL-prefix property verifies you for the Domain property as well. File and tag tokens are tied to the person who placed them. Several people can verify the same property by different methods, and Google asks owners not to overwrite each other's tokens. [Google's verification help](https://support.google.com/webmasters/answer/9008080) has the details for each method. ## Which should you choose? For a site you own and whose DNS you control, a Domain property is the sensible default. It catches the traffic that leaks into the versions of your site you forgot about: the http copy, the www copy, the staging subdomain someone left open. It also saves you reconciling four properties that each hold a slice of the truth. URL-prefix properties earn their place in three situations. When you cannot touch DNS, because the client's IT team owns it or the registrar login is lost. When you want a section on its own, because a `/blog/` property gives the blog its own reports, its own sitemaps and its own row limits in exports. And when you want to give someone access to one part of a site without the rest. Google's help suggests a separate property for each domain or subpath you want to track, and adding them is cheap: once a parent property is verified, child properties you add are verified automatically with the same method. One account can hold up to 1,000 properties. Remember that properties overlap. A Domain property's numbers already include its URL-prefix children, so never add them together in a report. If you want to split a Domain property by path without creating more properties, a page filter in the Performance report does it. ## The agency version If you work on client sites, the cleanest setup is this: the client verifies a Domain property themselves with a DNS record, then adds you as a user. You never need their registrar login, and they never have to trust you with it. [How to add a user to Search Console](/blog/add-a-user-to-search-console/) walks through the roles and which one to ask for. Two things are worth saying to the client out loud. First, the DNS record has to stay. Verification lasts as long as Search Console can find the token, and if every verified owner loses verification, every other user loses access after a grace period, agency included. Second, sitemaps belong to the property they were submitted in. A sitemap submitted to the old `https://www.` property will not appear in the new Domain property, so resubmit it there. [How to submit a sitemap to Google](/blog/submit-a-sitemap-to-google/) covers the rest. ## How properties appear in API-based apps Every third-party Search Console app, ours included, reads properties through Google's Search Console API, and the API names them differently from the interface. A Domain property comes back as `sc-domain:example.com`. A URL-prefix property comes back as the full URL with its trailing slash, `https://www.example.com/`. Each also carries your permission level: `siteOwner`, `siteFullUser`, `siteRestrictedUser` or `siteUnverifiedUser`. So if you see both `sc-domain:example.com` and `https://www.example.com/` in an app's list, that is two properties for one site, and their numbers overlap exactly as they do in Search Console. An app that reads the API, like ours, cannot verify a property for you; do that in Search Console first, and the property appears in the app once your account has access. Search Console has also begun rolling out a third kind, platform properties, which track how a creator's content on Instagram, TikTok, X or YouTube performs in Google Search. Google says the rollout is gradual. For a website, the choice is still Domain or URL-prefix. ## Where QueryWatch fits QueryWatch lists every property your Google account can see, Domain and URL-prefix alike, with real numbers on each and no site limit on the free tier. For agency lists, client tags and colours are free too, so a client's Domain property and its section properties can sit together under one tag. Pro adds multiple Google accounts, for the properties a client granted to a different login. Verification itself stays in Search Console. [QueryWatch for agencies](/search-console-for-agencies/) has the full picture, and [managing 20+ client properties](/blog/managing-client-properties-search-console/) covers the day-to-day. QueryWatch is an independent app, not affiliated with Google. Questions: **Do I need both a Domain property and URL-prefix properties?** Not necessarily. A Domain property on its own covers the whole site. URL-prefix properties are worth adding for sections you want to report on separately, or when someone should see one part of a site without the rest. **Why does my Domain property show more clicks than my https://www property?** Because it includes every subdomain and protocol: www and non-www, http and https, and any other subdomains such as a shop or a blog. The URL-prefix property counts just the URLs that start with its exact prefix. **Will deleting the DNS record unverify my site?** Eventually, yes. Search Console periodically checks that the verification token is still present; if it cannot confirm it, owners are notified and their permissions expire after a grace period. Google's help says to leave the record in place after verification succeeds. **What does sc-domain: mean?** It is how the Search Console API names a Domain property, as in sc-domain:example.com. URL-prefix properties appear as their full address, protocol and trailing slash included. Any third-party app built on the API sees these identifiers. --- ### Search Console vs Google Analytics: why clicks don't match GA4 URL: https://querywatch.app/blog/search-console-vs-google-analytics-4/ Published: 8 October 2026 Summary: Search Console counts clicks on Google results; GA4 counts sessions on your site. What each measures, why the numbers differ, and when to use which. Search Console and Google Analytics 4 will never show the same number, because they count different things in different places. Search Console counts clicks on your results in Google Search, recorded by Google on its own results pages. GA4 counts sessions recorded by a tag on your website, from every source, for visitors whose browsers run that tag and, depending on your consent setup, who have not opted out. Small differences are normal; a large gap usually comes from missing tags, consent, time zones, canonical URLs or comparing GA4's whole Organic Search channel with Google alone. ## What Search Console measures Search Console reports what happens on Google before anyone reaches your site: impressions, clicks, click-through rate and average position, broken down by query, page, country, device and search appearance, along with whether your pages are indexed at all. It covers Google and nothing else, split into web, image, video and news results, with Discover in a separate report. Outside its 24-hour view, its daily data is labelled in Pacific Time, and you cannot change that. It keeps 16 months of data, and collected data is usually available two to three days later. None of it depends on anything installed on your site, which is why it still counts clicks to pages your analytics never sees. ## What GA4 measures GA4 reports what visitors do after they arrive: sessions, users, engagement, key events and revenue, from every channel, including other search engines, social, email and direct visits. It depends on the tag. A page without it, a browser that blocks it, or a visitor who declines tracking is a visit GA4 may never record. Its reports use the time zone set on the property. GA4 does not report the queries people typed into Google. The query data you can see inside GA4 comes from Search Console, through the integration described below. ## Side by side | | Search Console | Google Analytics 4 | |---|---|---| | Counts | Impressions and clicks on Google results | Sessions, users and events on your site | | Recorded by | Google, on its results pages | A tag on your pages | | Sources | Google Search; Discover in its own report | Every channel | | Search queries | Yes, with rare queries left out of tables | Imported from Search Console when linked | | Page URLs | The canonical URL Google chose | Every URL that carries the tag | | Time zone | Pacific Time, fixed | The property's time zone | | History | 16 months | Standard reports are not affected by the retention setting; explorations keep 2 or 14 months | | Affected by consent and blockers | No | Yes | ## Why the numbers don't match 1. **A click is not a session.** Search Console counts a click when someone follows your result out of Google. GA4 counts a session when the tag on the landing page runs. Someone who clicks and leaves before the page finishes loading is a click with no session. 2. **Missing tags.** Pages without the GA4 tag still receive clicks from Search, and Search Console counts them. The same goes for PDFs and other non-HTML files shown in results: Search Console includes them, while a tag cannot run inside a PDF. 3. **Consent, JavaScript and blockers.** Google's own guidance notes that if visitors opt out of tracking, Analytics data is skewed, and that Analytics tracks traffic from users who have JavaScript enabled, not from those who have not. Some browsers and extensions block analytics scripts too. None of this affects Search Console. 4. **Time zones.** Search Console's days run on Pacific Time; GA4's run on whatever the property is set to. For a property set to London time, the two tools' days are eight hours apart for most of the year, so they share 16 of their 24 hours and daily figures never line up exactly. 5. **Channels and attribution.** GA4's Organic Search channel counts sessions from a list of search sites, not Google alone, and assigns each session to a channel by its own rules. Search Console counts every click from Google Search. 6. **Canonical URLs.** Search Console attributes clicks to the canonical URL Google selected. GA4 counts whichever URL carried the tag, parameters included, so page-level comparisons drift apart, especially when Google picked a canonical you did not expect. 7. **Privacy filtering and row limits.** To protect privacy, Search Console leaves rare queries, often called anonymised queries, out of its tables but includes them in chart totals, and a table shows at most 1,000 rows. Adding up the query rows will usually fall short of the total. 8. **Bots and timing.** GA4 automatically excludes known bots. And Search Console's most recent days are still being collected, so a comparison that includes them is comparing an unfinished number with a finished one. [Why Search Console data is days behind](/blog/why-search-console-data-is-days-behind/) covers the timing point in more depth. ## How to compare them fairly 1. Pick a date range that ended at least three days ago, so Search Console's numbers have settled. 2. In GA4, open Reports → Acquisition → Traffic acquisition, change the table's primary dimension to Session source / medium, and read sessions for the google / organic row. 3. In Search Console, open Performance → Search results for the same dates and read total clicks. 4. Allow for the time-zone offset before reading anything into a single day. 5. For page-level detail, link the two. In GA4 go to Admin → Product links → Search Console links and choose Link; you need the Editor role on the Analytics property and must be a verified owner of the Search Console property. Then publish the Search Console collection from the Library, where it sits unpublished by default. Once linked, the Google Organic Search Traffic report lists landing pages with Search Console and Analytics metrics together, and Google Organic Search Queries shows queries with their Search Console metrics. A web data stream can link to one Search Console property, and Search Console metrics there combine with three Analytics dimensions and no others: landing page, device and country. [Google's guide to using the two together](https://developers.google.com/search/docs/monitor-debug/google-analytics-search-console) and the [Search Console help on data discrepancies](https://support.google.com/webmasters/answer/17010575) go further. ## When to use which Use Search Console for questions about Google: are we being shown, for which queries, in which positions, did people click, and are our pages indexed. It is the place to start when organic traffic falls, because it tells you whether the change happened on Google or on your site; [clicks dropped, now what](/blog/clicks-dropped-what-now/) is the investigation step by step. [Search Console metrics explained](/blog/search-console-metrics-explained/) covers how to read its four numbers. Use GA4 for questions about your site: what visitors from search did next, whether they converted, and how search compares with every other channel. A fall in GA4's google / organic sessions that Search Console's clicks do not share usually points at your tag or consent setup rather than at Google. Use both when a client asks whether SEO is working: Search Console for the traffic Google sent, GA4 for what it was worth. ## Where QueryWatch fits QueryWatch reads Search Console and nothing else. The clicks, impressions, CTR and positions in the app are Search Console's figures through Google's API, labelled with the last complete day, so they line up with the Search Console website for the same dates and differ from GA4 for every reason above. There is no GA4 data in the app; a GA4 overlay is on the "later" part of the roadmap, without a date. If you want your Search Console numbers on your phone, with an alert when they move, [the product page](/google-search-console-app/) explains what the app does. Questions: **Should I report Search Console clicks or GA4 sessions to a client?** Use each for the question it answers. Search Console clicks show how much traffic Google Search sent and for which queries; GA4 shows what those visitors did once they arrived. Say which one a number comes from, and do not put the two side by side as if they should match. **Why does GA4 show more organic traffic than Search Console?** Usually because GA4's Organic Search channel includes other search engines, not just Google, and because GA4 records every URL that carries its tag while Search Console reports the canonical URL Google chose. Filter GA4 to the google / organic source and medium before comparing. **Can I see Search Console queries inside GA4?** Yes, once you link the two. The link adds a Search Console collection with Google Organic Search Queries and Google Organic Search Traffic reports, which is unpublished by default and has to be published from the Library. The data covers up to 16 months, because that is what Search Console keeps. **How big a difference is normal?** Google does not publish a threshold. Its guidance treats small differences as normal and large ones as worth investigating, using causes such as missing tags, consent choices, time zones and canonical URLs. --- ### How to add a user to Google Search Console, and which role URL: https://querywatch.app/blog/add-a-user-to-search-console/ Published: 8 October 2026 Summary: Owners add users in Settings → Users and permissions. What owner, full and restricted users can do, what agencies should ask for, and removing access. To add a user to Google Search Console, an owner of the property opens Settings → Users and permissions, clicks "Add user", enters the person's Google Account email address and chooses a permission level: Owner, Full or Restricted. A full user can see all the data and take most actions; a restricted user can view most data and act on very little. For an agency, full access to the client's Domain property covers nearly all day-to-day work, while the client keeps ownership. ## What can owners, full users and restricted users do? Google's permissions table runs to more than twenty rows. These are the ones that decide what an agency or a colleague can actually get done: | Action | Owner | Full user | Restricted user | |---|---|---|---| | View all reports, including Performance | Yes | Yes | Yes | | URL Inspection | Yes | Yes | Limited (fetch) | | Submit sitemaps | Yes | Yes | No | | Remove URLs (Removals tool) | Yes | Yes | View, no changes | | Disavow links | Yes | Yes | No | | Validate fixes in issue reports | Yes | Yes | No | | Change of Address | Yes | View, no changes | View, no changes | | Link a Google Analytics account | Yes | No | No | | Add users and change permissions | Yes | No | No | Google describes a full user as having "view rights to all data" and the ability to "take some actions", and a restricted user as having "simple view rights on most data". Restricted users also receive messages from Search Console that specifically affect them, rather than everything. There is a fourth relationship, the associate, which covers linked services rather than people browsing your reports. Google's help notes that associates cannot open your Search Console account or view its data directly. ## Verified owners and delegated owners There are two kinds of owner, with the same powers. A verified owner proved ownership themselves, with a DNS record, an HTML file, a meta tag or another token. A delegated owner was made an owner by an existing owner, without a token of their own. In Users and permissions, a verified owner is labelled both "Owner" and "Verified"; a delegated owner is labelled "Owner". The difference matters when people leave. A property must have at least one verified owner. If every verified owner is removed, every other user, delegated owners included, loses access after a grace period. Data keeps being collected, but nobody can see it until someone verifies again. ## How to add a user, step by step 1. Sign in to Search Console with an account that owns the property, and select the property. 2. Open Settings, then Users and permissions. The page is visible to owners alone, so if you cannot see it, you are not an owner. 3. Click "Add user". 4. Enter the person's Google Account email address. It has to be a valid Google Account; an email group will not work. 5. Choose Owner, Full or Restricted, then save. Add people to the property that matches what they need. Adding someone to a Domain property (`example.com`) gives them every subdomain and protocol; adding them to a URL-prefix property (`https://example.com/blog/`) gives them that section and nothing else. If the difference is new to you, [Domain vs URL-prefix properties](/blog/domain-vs-url-prefix-property/) explains it. If Search Console refuses to add someone as a full or restricted user, they probably already own a property containing this one. Google treats that as implicit ownership, so they can be added as an owner and nothing lower. ## How to change or remove access In Users and permissions, open the menu next to the person. "Change permissions" switches them between levels; "Remove access" takes them off the property, and Google says the change takes effect quickly. Verified owners are the exception. You cannot downgrade them, and removing them is not quite enough: their token may still be on the site, and if it is, they can regain access by verifying again. Remove the DNS record, file or tag they used. Google notifies all current owners if a removed owner re-verifies, so you will at least know. A property can have up to 100 non-owners. Delegated owners can be added until verified and delegated owners together reach 500. ## What an agency should ask a client for An onboarding email that asks for "access to Search Console" gets whatever the client clicks first. Be specific instead: - **Full user, not owner.** Full access covers reporting, URL Inspection, sitemaps, the Removals tool and validating fixes. Ask for owner when you genuinely need it: adding your own colleagues, linking Google Analytics or running a Change of Address during a migration. - **The Domain property, if one exists.** It shows the whole site in one place. If the client has URL-prefix properties alone, ask for each one that carries traffic, both http and https and www and non-www where they exist. - **The exact Google Account to add.** Tell the client which address to use, ideally an agency Google Account per person rather than a personal Gmail. Getting the address right up front saves a round of "it doesn't show up for me". - **A verified owner who stays.** The client should keep at least one verified owner and leave the DNS record in place. If their one verified owner leaves the company and the record is removed, you lose access too, after the grace period. When the engagement ends, ask the client to remove your access, and check that they did. Leaving old agency accounts on client properties is how strangers end up reading a business's search data three years later. ## How a newly shared property appears in third-party apps Search Console access belongs to a Google account, not to an app. Every third-party Search Console app, ours included, asks the Search Console API for the list of properties that the signed-in Google account can see, along with its permission level for each. So once a client adds your address, the property turns up in any app signed in to that account the next time it refreshes its property list. Nothing needs to be shared with the app itself. The same logic runs the other way. An app can never do more than your role allows: a restricted user's app can read the Performance numbers but cannot submit a sitemap. When the client removes you in Search Console, the property disappears from every app on the next refresh. And if the client added a different address from the one you signed in with, the property will not appear until you sign in with that account too. If you want to cut an app off without touching your Search Console access, remove it from your Google Account's list of connected third-party apps. ## Where QueryWatch fits QueryWatch shows every property your Google account can see, whatever your permission on it, with real numbers on each and no site limit on the free tier. The permission level is shown on each property, so you know before promising a client something whether your role allows it. Client tags and colours are free, for grouping a portfolio by client; [managing 20+ client properties](/blog/managing-client-properties-search-console/) shows how that works week to week. Pro adds multiple Google accounts, for clients who granted access to a different login. Users themselves are managed in Search Console, not in the app. Your Google token stays on your phone unless you turn on push alerts; [where does your Google token go](/blog/where-does-your-google-token-go/) explains what happens when you do. [QueryWatch for agencies](/search-console-for-agencies/) has the rest, and Google's [user and permissions help](https://support.google.com/webmasters/answer/7687615) has the full permissions table. QueryWatch is an independent app and is not affiliated with Google. Questions: **Can a full user add other people to a property?** No. Adding and removing users, and changing anyone's permission level, is reserved for owners. A full user who needs a colleague added has to ask an owner of the property, or an owner of a parent property. **Why is the Change permissions option greyed out for one user?** That person is a verified owner. Verified owners cannot be downgraded; they can be removed, and to remove them for good you also need to remove their verification token from the site, or they can verify again. **How many people can have access to one Search Console property?** A property can have up to 100 non-owners, counting full, restricted and associate users. Owners are counted separately: delegated owners can be added until verified and delegated owners together reach 500. **Can I add a shared team inbox as a Search Console user?** Users need their own valid Google Account, and Google's help says an email group cannot be added as a user. Add each person's Google Account instead, and remove them individually when they leave. --- ### The Search Console 1,000-row limit and anonymised queries URL: https://querywatch.app/blog/search-console-row-limits-and-anonymized-queries/ Published: 8 October 2026 Summary: Search Console tables stop at 1,000 rows, the API at 50,000 rows a day, and rare queries are hidden. Why the rows never add up, and how to get more data. The Google Search Console web interface shows at most 1,000 rows in any table, and exports to Google Sheets, Excel or CSV are cut to the same 1,000 rows. The Search Console API returns up to 25,000 rows per request and exposes at most 50,000 rows per day per search type, sorted by clicks. On top of both limits, Google leaves out rare queries to protect searchers' privacy. These anonymised queries count in the chart totals but never appear as rows, which is why the rows in a query table never add up to the total above it. None of this is a bug, and most of it can be worked around. Here is what each limit is, where the gaps come from, and how to get more of your data out. ## The limits at a glance | Where you read the data | Row limit | Notes | |---|---|---| | Performance report table | 1,000 rows | Google: "Our tables can show a maximum of 1,000 rows" | | Export to Sheets, Excel or CSV | 1,000 rows | Totals in the export are actual totals, not capped ones | | Search Console API, one request | 1 to 25,000 rows | Default is 1,000; page through with `startRow` | | Search Console API, per day | 50,000 rows per search type | Top rows, sorted by clicks | | Bulk data export to BigQuery | No row cap stated | Google: "all the performance data available", except anonymised queries | ## What are anonymised queries? Google's help (which spells it "anonymized") puts it in one line: "Some queries are omitted from the report to protect user privacy." These are rare queries, and Google's data documentation says it may not track some queries that are made a very small number of times at all. The important behaviour is how they are counted. Anonymised queries are included in the chart totals, so the clicks and impressions at the top of the Performance report contain them. They are never shown as rows in the Queries table. And the moment you apply a query filter, such as "queries containing" or "queries not containing" a word, they drop out of the totals too. That last point catches out anyone splitting branded from non-branded traffic. Filter for your brand name, then for everything not containing it, and the two totals add up to less than the unfiltered figure. The difference is the anonymised long tail, which belongs to neither side because Google never tells you what it was. Google does not publish a typical share, and it varies by site. A site whose traffic comes from a few head terms should lose little this way; a site living on long, specific queries is likely to see more of its impressions behind the curtain. The section below shows how to measure yours. ## Why the rows never add up to the total Three separate effects stack up, and it helps to know which one you are looking at. **Anonymised queries.** Counted in the chart total, absent from the table, as above. This one affects the Queries view. **Truncation.** Google says that "due to internal limitations, Search Console stores top data rows and not all data rows". The interface shows up to 1,000 of them; the API's documentation says it "does not guarantee to return all data rows but rather top ones". Google's API guide adds that when you group by page or query, "our system may drop some data". **Aggregation.** The chart is always aggregated by property: if two of your pages appear for one search, that counts as one impression. The Pages table is aggregated by page, so the same search counts once for each page. Queries, countries, devices and dates are aggregated by property. So the Pages table can legitimately add up to more than the chart total, while the Queries table adds up to less. [Search Console metrics explained](/blog/search-console-metrics-explained/) goes further into how clicks, impressions and position are counted. ## How to see more than 1,000 rows 1. **Shorten the date range.** The 1,000-row cap applies to whatever range you pick, so a single week surfaces different long-tail rows from a three-month view. Exporting week by week builds a fuller list. 2. **Filter before you export.** Filter by page or folder (for example, URLs containing `/blog/`), by country or by device, and each slice gets its own 1,000 rows. 3. **Use the API.** Request 25,000 rows at a time and page with `startRow` until a response comes back empty. Google's own guide on [getting all your data](https://developers.google.com/webmaster-tools/v1/how-tos/all-your-data) recommends querying one day at a time, and each day can return up to 50,000 rows per search type. Requests grouped or filtered by page or query are the expensive ones, so do not run them in tight loops. 4. **Turn on the bulk data export.** It sends a daily copy of the property's performance data to BigQuery, which Google describes as all the performance data available to Search Console for the property, anonymised queries excepted. It needs a Google Cloud project with billing, and it does not backfill: it starts from the day you set it up. [How long Search Console keeps data](/blog/search-console-data-retention-16-months/) covers the setup. 5. **Add URL-prefix properties for big sections.** Google suggests a separate property for each subpath you want to track. A `/blog/` property has its own 1,000-row tables, so the blog's long tail is no longer competing with the rest of the site for the same rows. ## How to measure your anonymised share With the bulk export, it is one query. Rare queries arrive as rows with `is_anonymized_query` set to true and an empty query field, so you can sum them directly: ```sql SELECT SUM(IF(is_anonymized_query, clicks, 0)) / SUM(clicks) AS anonymised_click_share, SUM(IF(is_anonymized_query, impressions, 0)) / SUM(impressions) AS anonymised_impression_share FROM `your_project.searchconsole.searchdata_site_impression` WHERE data_date BETWEEN '2026-09-01' AND '2026-09-30'; ``` Without the export, you can estimate it from the API. Request the property's totals for a day with no dimensions, then request the same day grouped by query and page through every row. The gap between the two is anonymised queries plus whatever was truncated, so treat it as an upper bound. The [Search Console help on dimensions and data groupings](https://support.google.com/webmasters/answer/17011259) has Google's own description of what is left out. ## What it means in practice For most decisions, the top rows are what matter: rows are sorted by clicks, so the queries and pages that carry your traffic are not the ones that get cut. The limits bite in three places. Long-tail research, where the interesting queries are exactly the rare ones. Reconciliation, when a client asks why the queries in a report do not add up to the headline number. And branded versus non-branded splits, where the anonymised remainder belongs to neither. For the second, the honest answer is a sentence in the report: the total includes searches Google does not itemise, for privacy reasons. ## Where QueryWatch fits QueryWatch reads the same Search Console API, so the same rules apply to it. Its Queries and Pages tabs show the top 100 rows for the range you choose, alongside the country and device splits, and the gap between those rows and the property total is there for the same reasons. That is a deliberate fit for a phone: the top 100 is what you scan on the move, and [striking distance](/blog/striking-distance-keywords-search-console/) picks out the queries at positions 8 to 20 worth working on. For complete long-tail data, use the bulk export on a laptop. The app is described on [the QueryWatch page](/google-search-console-app/); QueryWatch is independent and not affiliated with Google. Questions: **Does the Search Console API include anonymised queries?** Not as rows. Like the web interface, the API returns the top rows sorted by clicks and leaves rare queries out, so a request grouped by query will not add up to an ungrouped request for the same dates. The BigQuery bulk export does include those rows, with the query text blanked and a flag set. **Why do my totals drop when I filter by query?** Anonymised queries count towards the chart totals until a query filter is applied. Any filter such as queries containing or queries not containing a word removes them, so a branded view and a non-branded view will add up to less than the unfiltered total. **Is the 1,000-row limit per day or per date range?** In the web interface it applies to the table for whatever range you select, so a three-month view and a one-day view each show at most 1,000 rows. The API's 50,000-row ceiling is per day per search type, and Google recommends querying one day at a time. **Can I find out what the anonymised queries were?** No. Google withholds them to protect the privacy of the people searching, so no export, API call or third-party tool can restore the text. You can measure how much traffic they account for, but not what was typed. --- ### How long does Search Console keep data? The 16-month rule URL: https://querywatch.app/blog/search-console-data-retention-16-months/ Published: 8 October 2026 Summary: Search Console keeps 16 months of performance data, then drops it. How to archive it with exports, the API or BigQuery, and what it means for comparisons. Google Search Console keeps 16 months of performance data. The window rolls forward every day, so as a new day arrives the oldest one drops off, and once it has gone you cannot get it back from Search Console. To keep a longer history you have to export it yourself, and Google's own suggestion is the Search Analytics API or the bulk data export to BigQuery. The bulk export accumulates data from the day you set it up but does not backfill, so the sooner it is running, the more you keep. ## What the 16 months covers The limit applies to the performance data: clicks, impressions, CTR and average position, by query, page, country, device and date. In the Performance report's date filter, "Last 16 months" is the longest preset, and custom ranges cannot reach further back. All dates are in Pacific Time. The same ceiling follows the data wherever it goes. Google's Analytics help says that "Search Console keeps data for the last 16 months", and that the Search Console reports inside Google Analytics 4 therefore include a maximum of 16 months too. Third-party tools that read the API, ours included, see the same window. None of them is a way around it. ## What 16 months means for comparisons Sixteen months is a year plus four months, which is enough for a year-over-year comparison of recent months. The Compare tab in the date filter offers comparisons such as "Compare last 3 months year over year", and that works because the previous year's three months still fall inside the window. The arithmetic sets a hard edge. A year-over-year comparison can cover roughly the most recent four months, and no more. Comparing this full year with last year needs 24 months of data, which Search Console never holds. If you report annually, or want to see whether a slow decline started before last summer, you need your own archive. Google's guide to [debugging traffic drops](https://developers.google.com/search/docs/monitor-debug/debugging-search-traffic-drops) uses the window this way: select "Last 16 months" to check whether a drop is seasonal, something that happens every year around a holiday or a trend. It also says what to do if that is not enough: "If you'd like to extend the 16 months, you could use the Search Analytics API or bulk data exports to pull data and store it in your systems." ## A caveat for year-over-year comparisons in 2026 Google's Data anomalies page in Search Console Help records a logging error that prevented accurate reporting of impressions from 13 May 2025 until 27 April 2026. Google says the issue is resolved and that you may notice a decrease in impressions as a result. Impressions, CTR and average position were affected; clicks were not. If your year-over-year comparison has one side inside that period, which in October 2026 it does, compare clicks. Treat impression, CTR and position deltas across that boundary with suspicion, and say so in any client report that uses them. [Did a Google core update hit my site?](/blog/did-a-google-core-update-hit-my-site/) has more on ruling out causes that are not about your site. ## Three ways to keep more than 16 months | Method | Effort | What you keep | Limits | |---|---|---|---| | Manual export from the report | A few minutes a month | Chart data plus up to 1,000 table rows per export | Easy to forget; long tail cut off | | Search Analytics API to your own storage | A script and somewhere to put it | Up to 50,000 rows per day per search type | Quotas; you maintain the script | | Bulk data export to BigQuery | One-off setup in Google Cloud and Search Console | All performance data, daily, except anonymised query text | Starts on the setup day; Google Cloud costs | **Manual export.** The Performance report has an export button that downloads the chart and table data to Google Sheets, Excel or CSV. Tables are cut to 1,000 rows, though the totals in the file are actual totals. Export a 16-month range with the Dates tab selected and you get a daily total for every day in the window, roughly 490 rows and well under the limit. Do it on the same day each month and you have an archive of daily totals plus your top queries and pages. [The 1,000-row limit](/blog/search-console-row-limits-and-anonymized-queries/) explains what gets left out. **The API.** A small script that requests yesterday's data each day and writes it to a database or a spreadsheet builds an archive with far more rows than the interface allows. Run it once at the start to collect the 16 months still available. **The bulk data export.** This is Google's own answer for keeping everything, and the one to set up if the history matters to you. ## How to set up the bulk data export 1. In Google Cloud, create or pick a project with billing enabled, and enable BigQuery. 2. In that project's IAM settings, add the principal `search-console-data-export@system.gserviceaccount.com` and grant it two roles: BigQuery Job User and BigQuery Data Editor. 3. In Search Console, open the property's Settings, then Bulk data export, and enter the Cloud project ID (the ID, not the project number). 4. Keep the default dataset name, `searchconsole`, unless you are exporting several properties to one project. Choose the dataset location carefully: Google warns it cannot easily be changed once exports have started. 5. Wait. The first export arrives up to 48 hours after setup and runs daily from then on. The export does not include anything from before the setup day; for that, Google points you to the API or the reports. So on the day you switch it on, also pull the 16 months still available through the API. Do not put that backfill off: every day you wait, another day ages out. Two settings decide what it costs and how long it lasts. Google says the data accumulates indefinitely unless you set an expiration time, and that it is subject to Google Cloud storage and query costs, with a free usage level. Leave expiration unset if the point is a permanent archive, and set a budget alert either way. Google's [bulk export setup guide](https://support.google.com/webmasters/answer/12917675) has the screens. ## Where QueryWatch fits QueryWatch reads the same Search Console API, so its history is Google's 16 months and no longer; it is a reader, not an archive. On the free tier you get 7, 28 and 90-day presets with deltas against the previous period, and a CSV of whatever view you are looking at. Pro opens the full 16 months, with custom ranges and period comparison, plus a comparison CSV with the previous period's numbers and the change on every row, ready to paste into a client report from a phone. For anything older than 16 months, the bulk export above is the right tool. [The free and Pro split](/blog/free-vs-pro-why-we-never-cap-properties/) is written out in full, and [the QueryWatch page](/google-search-console-app/) covers the rest. QueryWatch is an independent app, not affiliated with Google. Questions: **Can I get Search Console data that is older than 16 months?** Not from Search Console. Once a day passes the 16-month mark it is gone from the reports, and the bulk data export does not backfill. The older data you can use is whatever you, or a tool you set up, exported before it aged out. **Does Google Analytics keep Search Console data for longer?** No. When Search Console is linked to Google Analytics 4, Google's help says the Analytics reports also include a maximum of 16 months of Search Console data, because that is all Search Console keeps. **How much does the BigQuery bulk export cost?** Google says the exported data is subject to Google Cloud storage and query costs, with a free usage level. What you pay depends on how much traffic your site has and how you query the tables, so set a budget alert in Google Cloud when you turn it on. **Is the bulk export a complete copy?** Google describes it as all the performance data available to Search Console for the property, apart from anonymised queries, which arrive as flagged rows with an empty query field. Its data anomalies page also records 28 February and 1 March 2026 as missing from bulk exports for some properties. --- ### Core Web Vitals report in Search Console: LCP, INP and CLS URL: https://querywatch.app/blog/core-web-vitals-report-search-console/ Published: 8 October 2026 Summary: The Core Web Vitals report rates real-user LCP, INP and CLS at the 75th percentile over 28 days. The thresholds, URL groups, missing data and validation. The Core Web Vitals report in Google Search Console shows how your pages perform for real Chrome users, split into mobile and desktop and rated Good, Need improvement or Poor. A page group is Good when its Largest Contentful Paint is 2.5 seconds or less, its Interaction to Next Paint is 200 milliseconds or less and its Cumulative Layout Shift is 0.1 or less, each measured at the 75th percentile of visits over the last 28 days. The numbers come from the Chrome User Experience Report (CrUX), not from a lab test, which is why smaller sites often see no data at all. ## What do LCP, INP and CLS measure? Three metrics, one for each kind of frustration a visitor feels. Largest Contentful Paint (LCP) measures loading: how long until the largest image, video or text block in the viewport has rendered. On most pages that is a hero image or the headline block. Interaction to Next Paint (INP) measures responsiveness: how long the page takes to visibly respond after a click, a tap or a key press. It observes interactions throughout the visit, and the value reported is the longest one, ignoring outliers. Cumulative Layout Shift (CLS) measures visual stability: how much content jumps around unexpectedly, such as the button that moves just as you go to tap it. INP replaced First Input Delay (FID) as a Core Web Vital on 12 March 2024, and FID was removed from Search Console the same day. FID measured the input delay of the first interaction alone; INP covers every click, tap and key press. Any checklist that still mentions FID is out of date. ## What are the thresholds? | Metric | Measures | Good | Need improvement | Poor | |---|---|---|---|---| | LCP | Loading | 2.5 s or less | Over 2.5 s, up to 4 s | Over 4 s | | INP | Responsiveness | 200 ms or less | Over 200 ms, up to 500 ms | Over 500 ms | | CLS | Visual stability | 0.1 or less | Over 0.1, up to 0.25 | Over 0.25 | Every value is the 75th percentile. For LCP, that is the time by which 75 percent of visits to the URLs in a group had reached the LCP moment. Using the 75th percentile rather than the median means a page has to be fast for most of its visitors, not just for the typical one on good Wi-Fi. ## Where does the data come from? From CrUX, Google's dataset of anonymised performance timings from real Chrome users. Not every visit is in it. Chrome's documentation excludes Chrome on iOS, Android apps that use WebView, and other Chromium browsers such as Microsoft Edge, and counts users who have usage statistics reporting and history sync turned on. A page also has to be publicly discoverable: one that returns a status other than 200 or carries a noindex is left out. In Search Console, the group metrics cover the last 28 days, the report includes indexed URLs alone (a page that is [not indexed](/blog/page-indexing-report-explained/) will never appear in it), and the example URLs are a sample rather than a full list. That last point catches people out. If a page you care about is missing from the examples, it can still be in a group. ## How do URL groups work? Search Console groups URLs that it judges to provide a similar experience, typically pages built on the same template, and reports one status for the whole group. The group's status is its slowest metric for that device type: a group with good LCP and INP but a CLS of 0.3 is Poor. That is useful rather than a nuisance: fixing the template usually moves the whole group. When a URL group has too little data, Search Console falls back to an origin group, which covers every URL under one protocol, host and port. The http and https versions of a site are separate origins. ## Why does the report say there is not enough data? Because CrUX did not record enough visits. Chrome publishes data for a page, and separately for an origin, once it passes a minimum number of visitors, and the exact threshold is not disclosed. Low-traffic sites, sites whose audience mostly uses iPhones, and pages behind a noindex all run into it. A newly added property may show "No data available" for a few days while existing CrUX data is processed, and a URL group without data for both LCP and CLS is left out of the report entirely. Nothing you change in Search Console fixes this; more traffic does. In the meantime, PageSpeed Insights will run a Lighthouse lab test on any URL, and it falls back to origin-level field data when a single URL has too little. ## How to fix an issue and validate it 1. Open Experience → Core Web Vitals and choose Open report next to the mobile or the desktop chart. Start with whichever has more Poor URLs. 2. Pick the issue affecting the most URLs and open its example URLs. 3. Run two or three of those URLs through PageSpeed Insights. The lab data from Lighthouse is what you debug with; the field data tells you whether real visitors agree. 4. Fix the template rather than the page, then deploy. 5. Go back to the issue in Search Console and click Start tracking (Validate fix in some of Google's documentation). This begins a 28-day monitoring session. If the issue is not present on any URL during that window, it counts as fixed. 6. Wait. Validation does not trigger a recrawl or anything else on Google's side, and because the data is a rolling 28 days, the chart moves gradually rather than overnight. Validation moves through Not started, Started, Looking good and then Passed or Failed. If it fails, fix what is left and choose Start new validation. ## How much do Core Web Vitals matter for rankings? Google says Core Web Vitals are used by its ranking systems and recommends achieving good scores. Its [page experience documentation](https://developers.google.com/search/docs/appearance/page-experience) is just as clear about the limits: good scores do not guarantee top rankings, Google Search will still show the most relevant content even when its page experience is sub-par, and chasing a perfect score purely for SEO reasons is probably not worth the time. Google's core ranking systems generally evaluate page experience page by page, not site-wide. The practical reading is to move Poor groups to Good on the templates that carry your traffic. Shaving 50 milliseconds off a group that is already Good is unlikely to change where you rank. If you want a cadence, a glance at the Poor count once a week is enough; [our ten-minute weekly check-in](/blog/weekly-seo-check-in-ten-minutes/) slots it in at minute seven. ## Where QueryWatch fits The Search Console API does not expose the Core Web Vitals report, so no third-party app can show you Search Console's URL groups or start a validation. Those stay in the web interface, and Google's [Core Web Vitals report help](https://support.google.com/webmasters/answer/9205520) covers every status in detail. What QueryWatch Pro adds is Core Web Vitals per page: LCP, INP and CLS for a single URL, checked from your phone, which is the view the grouped report deliberately does not give you. Per-page field data still depends on Chrome having recorded enough visits to that page, so a quiet page will have less to show in any tool, ours included. Because the Search Console report includes indexed URLs alone, it is also worth confirming a page is indexed; the free tier covers five URL inspections a day, and [URL inspection explained](/blog/url-inspection-and-request-indexing/) shows what to read in the result. Every property is on the free tier, and [the product page](/google-search-console-app/) lists what Pro adds. QueryWatch is an independent app and is not affiliated with Google. Questions: **Does Core Web Vitals data include visitors on iPhone?** No. The report uses Chrome User Experience Report data, which excludes Chrome on iOS as well as Safari and other non-Chrome browsers. A site whose audience is largely on iPhones can have healthy traffic and still very little field data. **How long do Core Web Vitals fixes take to show in Search Console?** Around four weeks. The report is built from a rolling 28-day window of real-user data, so a fix shows up gradually as old visits age out, and validation runs its own 28-day monitoring period without triggering a recrawl. **Is First Input Delay still a Core Web Vital?** No. Interaction to Next Paint replaced First Input Delay on 12 March 2024, and FID was removed from Search Console the same day. INP looks at clicks, taps and key presses across the whole visit, not just the first interaction. **Why do PageSpeed Insights and Search Console show different numbers?** PageSpeed Insights runs a Lighthouse lab test on one URL and shows field data for that URL, or for the whole origin when the URL has too little. Search Console reports field data for groups of similar URLs, so the two describe different slices of the same underlying data. --- ### Did a Google core update hit my site? How to tell URL: https://querywatch.app/blog/did-a-google-core-update-hit-my-site/ Published: 8 October 2026 Summary: Check the Search Status Dashboard dates, compare a week after the rollout with a week before, and rule out tracking, indexing and seasonality first. To tell whether a Google core update hit your site, check the update's start and end dates on Google's Search Status Dashboard, wait at least a full week after the rollout finishes, then compare a week after it with a week before it started in Search Console's Performance report. If the drop begins inside the rollout window, is spread across many pages and queries, and nothing on your side broke, the update is the likely cause. Google says core updates do not target individual sites, there is no specific fix, and recovery can take months. A drop that coincides with an update is not proof of one, which is why the second half of the job, ruling things out, matters as much as the first. ## When were the recent core updates? Google lists confirmed ranking updates on its [Search Status Dashboard](https://status.search.google.com/), with a start date and a duration for each, in US Pacific time. These are the five most recent core updates as of 8 October 2026. | Update | Started | Listed duration | |---|---|---| | May 2026 core update | 21 May 2026 | 11 days, 21 hours | | March 2026 core update | 27 March 2026 | 12 days, 4 hours | | December 2025 core update | 11 December 2025 | 18 days, 2 hours | | June 2025 core update | 30 June 2025 | 16 days, 18 hours | | March 2025 core update | 13 March 2025 | 13 days, 21 hours | Google says core updates happen several times a year, and that it also makes smaller core updates between them which are not announced because they are not widely noticeable. The dashboard lists other updates too. The September 2026 spam update began on 24 September 2026 with a listed duration of 13 days and 16 hours; spam updates target sites that violate Google's spam policies, which is a different diagnosis with a different remedy. ## Step 1: line the drop up with the dates Open Performance → Search results, set the date range to the last 16 months, and look at clicks and impressions. Then narrow to three months around the suspected update. You are asking one question: did the decline start inside the rollout window? A drop that began a week before the update started is not the update. A drop that began on the second day of a rollout and deepened over the following ten is consistent with it. Two habits make this cleaner. Ignore the last two or three days of any chart, because [Search Console data is finalised two to three days late](/blog/why-search-console-data-is-days-behind/) and a partial day always looks like a drop. And mark the dates: right-click the Performance chart to add a custom annotation, up to 120 characters, so the next person to open the property sees "May 2026 core update starts" on the right day. ## Step 2: compare the right periods Google's [core updates guidance](https://developers.google.com/search/docs/appearance/core-updates) is specific: wait at least a full week after the update completes, then compare that week with a week before the rollout started. Comparing anything inside the rollout window measures a moving target. Use Compare in the date filter, choose custom ranges, and match the weekdays: Monday to Sunday against Monday to Sunday. Then run the same comparison year over year. [Search Console's 16 months of history](/blog/search-console-data-retention-16-months/) covers that for an update in roughly the last four months; for older ones you need an export saved at the time. If last year's same weeks fell by a similar amount, you are looking at seasonality, and Google Trends for your main queries will usually confirm it. ## Step 3: page level or query level? Sort the Pages tab by clicks difference, then the Queries tab, and look at the shape rather than the list. A drop concentrated in one or two pages is usually a page problem: a template change, a canonical that moved, a page that dropped out of the index. A drop spread thinly across dozens of pages and hundreds of queries, with positions slipping a few places each, is the shape a broad ranking change leaves. Check the search type filter too. Google's guidance asks whether the drop happened in Web, Images, Video or News, because each can move separately. Then look at the size. Google's own example is that slipping from position 2 to 4 needs no drastic action, while falling from 4 to 29 calls for a deeper assessment. ## Step 4: rule out what looks like an update | What you see | Likely cause | Where to check | |---|---|---| | Analytics sessions fell, Search Console clicks did not | Tracking or consent change | Your analytics setup | | A sharp dip across unrelated properties on the same day | Logging issue on Google's side | Google's "Data anomalies in Search Console" help page, and system annotations on the chart | | Indexed pages falling | Indexing problem | Indexing → Pages | | A message about a manual action | Spam policy violation | Security & Manual Actions → Manual actions | | Drop starts the day of a deploy or migration | Robots.txt, noindex, redirects, canonicals | URL inspection on the top lost pages | | Same fall in the same weeks last year | Seasonality | Year-over-year comparison, Google Trends | The first row catches people out: the two tools count differently, and [Search Console and GA4 never match](/blog/search-console-vs-google-analytics-4/) for reasons that have nothing to do with Google's rankings. If none of these fit and the timing does, you have a reasonable case for the core update. Write it down with the dates and the comparison you used, because the client will ask, and "it was the update" without evidence sounds like an excuse. [Clicks dropped, now what](/blog/clicks-dropped-what-now/) walks through the page-by-page part of this investigation in detail. ## What Google recommends if it was the update Google's guidance is short, and calmer than the urgency a drop tends to create. For a small drop, take no drastic action, and avoid changing content that is already performing well. For a large, sustained drop, assess whether the site overall delivers content that is helpful, reliable and made for people, starting with the pages that fell furthest, and consider asking someone unaffiliated with the site for an honest view. Avoid quick fixes. Google advises changes that make sense for users and are sustainable over the long term, and treats deleting content as a last resort. Expect to wait. Google says it could take several months for its systems to recognise improvements, and that sometimes the effect does not show until the next core update. There is no guarantee that changes will produce a noticeable impact, which is worth saying to a client before they hear it from someone else. ## Where QueryWatch fits QueryWatch does not know when Google ships an update, and it does not annotate charts with them. What it does is make sure you notice a drop on the day the data is final rather than at the end of the month. With Pro alerts on, a relay checks every six hours, compares the latest complete day with the same weekday over the previous four weeks, and pushes a notification when the move reaches 30 percent or two standard deviations, both adjustable per property, with at most one notification per property per day. Each alert stores an evidence snapshot: the observed value, the baseline, the dates and the top contributing pages at that moment. That snapshot is useful during a core update, because Search Console data shifts while you investigate, and a dated record of what moved first is what you want when you line it up against the dashboard. [The alerts page](/search-console-alerts/) has the details. The change investigation, which shows the top three pages, queries, countries or devices behind any move on the free tier and twenty on Pro, covers Step 3 from your phone. Pro adds 16 months of history and period comparison for Step 2. QueryWatch is an independent app and is not affiliated with Google. Questions: **How long does a Google core update take to roll out?** Usually about two weeks, though it varies. On Google's Search Status Dashboard the core updates since 2025 are listed with rollouts of between roughly 12 and 18 days, and the March 2024 core update took 45 days. **Is a core update drop a penalty?** No. Google describes core updates as broad changes that do not target specific sites or pages. A manual action is applied by a human reviewer and is reported in Search Console's Manual actions report and message centre; a core update drop shows up in neither. **Will my traffic come back after the next core update?** There is no guarantee. Google says improvements can take several months to be recognised, and that sometimes the effect does not show until the next core update, which is why changes should be made for users rather than to reverse one update. **Can Search Console mark core update dates on the chart?** Search Console's system annotations are for data-processing and reporting issues, and Google's help does not list ranking updates among them. You can add a custom annotation of up to 120 characters on the update's start date yourself, and every user of the property will see it on the Performance chart. --- ### Search Console regex filters: syntax, examples and gotchas URL: https://querywatch.app/blog/search-console-regex-filters/ Published: 8 October 2026 Summary: How the Custom (regex) filter in Search Console's Performance report works: RE2 syntax, case rules, and tested patterns for questions, brands and folders. Search Console's Performance report lets you filter queries and pages with a regular expression: choose Add filter, pick Query or Page, select Custom (regex), then Matches regex or Doesn't match regex. It uses Google's RE2 syntax, matches anywhere in the text unless you anchor it with `^` or `$`, and is not case-sensitive by default; put `(?-i)` at the start for a case-sensitive match. Regex is how you isolate question queries, branded searches, long-tail queries or a group of folders in one filter. This is a guide to the Search Console web interface. QueryWatch does not have regex filters, and we say more about what it does instead at the end. ## How to add a regex filter 1. Open a property and go to Performance → Search results. 2. Click + Add filter in the filters row at the top of the report. 3. Choose Query or Page. 4. In the match-type menu, choose Custom (regex). 5. Type the expression. Keep the default, Matches regex, to include what it matches, or switch to Doesn't match regex to exclude it. 6. Click Apply. The chart, the totals and every tab of the table now reflect the filter. Google documents the filter in its [advanced filtering help page](https://support.google.com/webmasters/answer/17011165). The same expressions work in the Search Analytics API through the includingRegex and excludingRegex operators. ## What RE2 supports, and what it does not RE2 covers everything you need for this job: alternation with `|`, anchors `^` and `$`, character classes such as `[a-z]` and `\d`, the word boundary `\b`, whitespace `\s` and non-whitespace `\S`, and repetition with `?`, `*`, `+` and `{n,}`. A dot matches any character, so a literal dot is `\.` and a literal question mark is `\?`. What it leaves out is lookahead, lookbehind and backreferences. If a pattern you found online contains `(?!` or `(?<=`, it will not work here. You rarely need it. Instead of a negative lookahead, write a pattern for the thing you want gone and choose Doesn't match regex. ## Patterns worth saving Replace the example brand, northwind, and the example domain with your own. Each pattern was checked against Google's RE2 library with case-insensitive matching, as Search Console applies it. | Goal | Filter | Regex | |---|---|---| | Question queries | Query, matches | `^(who\|what\|when\|where\|why\|how\|which\|can\|does\|is\|are\|should)\b` | | Branded queries | Query, matches | `northwind\|north wind\|nortwind` | | Non-branded queries | Query, doesn't match | `northwind\|north wind\|nortwind` | | Long tail, five words or more | Query, matches | `^\S+(\s+\S+){4,}$` | | Short head, one or two words | Query, matches | `^\S+(\s+\S+)?$` | | Comparison and price intent | Query, matches | `\b(vs\|versus\|alternatives?\|compare\|reviews?\|price\|pricing\|cost)\b` | | Queries with a year in them | Query, matches | `\b20[0-9]{2}\b` | | One folder | Page, matches | `/blog/` | | Several folders | Page, matches | `/(blog\|guides\|help)/` | | The home page and nothing else | Page, matches | `^https://www\.example\.com/$` | | URLs with parameters | Page, matches | `\?` | | PDF files | Page, matches | `\.pdf$` | | A case-sensitive path | Page, matches | `(?-i)/Products/` | The question pattern is anchored with `^` and closed with `\b` on purpose. Without them, "how" also matches "show", "however" and "knowhow". The long-tail pattern counts runs of non-space characters, so "how to fix crawled currently not indexed" is seven words and qualifies. The comparison pattern is a useful companion to a [striking-distance list](/blog/striking-distance-keywords-search-console/): queries at positions 8 to 20 with buying intent in them are often the ones worth an afternoon. ## The gotchas Page values are full URLs. The Page dimension stores `https://www.example.com/blog/post`, not `/blog/post`, so `^/blog/` matches nothing. Either drop the anchor or include the protocol and host. Unanchored patterns match anywhere. That is helpful for folders and harmful for short words, which is why the question pattern above is anchored. Spaces are characters. `how | why` matches "how " and " why" with the spaces included, which is rarely what you meant. Write `how|why`. Case is ignored by default. Some guides tell you to add `(?i)` to make a pattern case-insensitive; in Search Console that is already the behaviour, and `(?-i)` is the switch that turns case sensitivity on. Totals shrink when you filter by query. Google's help says anonymised queries are included in chart totals unless a query filter is applied, and filtering by query or URL can also be affected by data truncation. Expect branded plus non-branded to come to less than the unfiltered total. [Row limits and anonymised queries](/blog/search-console-row-limits-and-anonymized-queries/) explains why. Exports stay capped. An export from the report is truncated to 1,000 rows, filtered or not. The upside is that a filter gives you a different 1,000 rows, so a large site can export its long tail folder by folder. ## Regex or the branded queries filter? Search Console now has a built-in branded queries filter, which Google's [help on report dimensions](https://support.google.com/webmasters/answer/17011259) describes as separating queries that include your brand name, your domain, or a brand-specific product or service. It saves you maintaining a list of misspellings. It also has limits: it is not available for sub-properties such as `https://example.com/blog/` or for sites with a low number of impressions, and Google notes that some queries might be classified incorrectly. Use the built-in filter where you have it and it looks right. Keep the regex for sub-properties, smaller sites, and any case where you need to control exactly which terms count as brand, such as a product name that is also an ordinary word. ## Letting Search Console write the regex Google is testing an AI-powered configuration for the Performance report, opened from the filter icon in the report header, which turns a plain-language request into filters and comparisons, including regex query filters. It is experimental, visible to a small percentage of users, limited to 20 requests a day, and Google warns that it may produce filters that do not match your request. If you have it, read the regex it writes before you trust the numbers under it. ## Where QueryWatch fits QueryWatch does not offer regex filtering; this post is about the web interface, and on a phone that means the mobile web version of Search Console. What QueryWatch does instead is cover some of the jobs people write regex for. The striking-distance view lists queries at positions 8 to 20, ranked by opportunity, on the free tier. The watchlist tracks specific queries, pages or query-page pairs, five on the free tier and unlimited on Pro. And the current view, including the top 100 queries or pages, exports as CSV. When you need a pattern, open Search Console. When you want to know what moved this morning, [the app](/google-search-console-app/) is quicker. QueryWatch is an independent app and is not affiliated with Google. Questions: **Can I use regex filters in the Search Console API?** Yes. The Search Analytics API accepts includingRegex and excludingRegex as filter operators, using the same RE2 syntax, and its documentation lists a maximum length of 4,096 characters for a filter expression. **Does Search Console regex support negative lookahead?** No. RE2 does not support lookahead, lookbehind or backreferences. To exclude something, write a pattern that matches it and choose Doesn't match regex instead. **Why don't my branded and non-branded clicks add up to the total?** Applying any query filter removes anonymised queries from the totals, and those can be a large share of a site's clicks. Branded plus non-branded will therefore usually come to less than the unfiltered total, and that is expected. **Can I filter Search Console by regex on my phone?** Yes, in Search Console's own web interface opened in a phone browser, which has the same filter. QueryWatch does not offer regex filtering, so on a phone the browser is the way to do it. --- ### Weekly SEO checklist: a ten-minute Search Console check-in URL: https://querywatch.app/blog/weekly-seo-check-in-ten-minutes/ Published: 8 October 2026 Summary: A ten-minute Monday routine in Search Console: the week's delta, top movers, indexing, sitemaps, Core Web Vitals and one striking-distance query. A useful weekly SEO check-in takes ten minutes in Google Search Console: compare clicks and impressions for the last complete week against the week before, see which pages and queries moved most, glance at Indexing → Pages and Indexing → Sitemaps for new errors, check the count of Poor URLs in Core Web Vitals, and pick one striking-distance query to work on. Everything else can wait for the monthly review. The routine fits a Monday morning, reads complete days, and ends with one written line per property. Google itself says there is no need to sign in every day and suggests checking [around once a month](https://developers.google.com/search/docs/monitor-debug/search-console-start), or after changing the site. That is reasonable for a site owner who will hear from Search Console by email if it finds new issues. If you are paid to notice traffic changes before a client does, weekly is the right rhythm, and this is the version that fits in ten minutes. ## Before you start: which week are you reading? Search Console performance data is finalised two to three days after the day it describes, and the most recent days in any chart are provisional. On a Monday morning, the weekend is not finished being counted. Compare seven complete days with the seven before, and treat the right-hand edge of every chart as unfinished. [Why the data is days behind](/blog/why-search-console-data-is-days-behind/) has the detail. Search Console also counts days in California time, which matters if you work in London or Sydney: Google's Tuesday is not quite yours. ## Minutes 0 to 2: the week's delta Open Performance → Search results. In the date filter, choose Compare, then a custom range: the last seven complete days against the seven before. Look at two numbers: total clicks and total impressions. You are classifying, not investigating. Flat or within the usual wobble: move on. Clicks down with impressions down: Google is showing the site less, so the next two minutes matter. Clicks down with impressions steady: people are seeing the site and choosing it less, which usually points at titles, snippets or a new result type above you. [Search Console metrics explained](/blog/search-console-metrics-explained/) covers how the four numbers move each other. ## Minutes 2 to 4: the top movers With the comparison still on, open the Pages tab and sort by the clicks difference column, then do the same on the Queries tab. Read the top five losers and the top five gainers in each. The shape matters more than the names. One page carrying most of the loss is a page problem worth opening today. A loss spread thinly across many pages is a site-wide or demand question for the monthly review. A page gaining clicks for a query another of your pages lost is a sign Google has swapped which page it shows. ## Minutes 4 to 6: indexing Open Indexing → Pages and look at the chart, not the table. Is the indexed count roughly flat? Has any reason under "Why pages aren't indexed" jumped since last week? A sudden rise in Not found (404), Server error (5xx) or noindex exclusions usually means a deploy changed something. Most of the other reasons are normal background; [the Page indexing report explained](/blog/page-indexing-report-explained/) separates the faults from the noise. While you are there, check Search Console's messages. Google emails you when it finds new issues on the site, but it takes seconds to confirm nothing about a manual action or a security issue is waiting. ## Minute 6 to 7: sitemaps Open Indexing → Sitemaps. Every sitemap you care about should show Success. Has errors means Google fetched it and found problems; Couldn't fetch means it could not retrieve the file at all. Either is worth a ticket today, because a broken sitemap is often the first visible sign of a broken build. ## Minute 7 to 8: Core Web Vitals Open Experience → Core Web Vitals and look at the count of Poor URLs on mobile and desktop. The report uses a rolling 28 days of real-user data, so it moves slowly and a weekly glance is plenty. A jump in Poor URLs after a release is the signal; anything else belongs to the monthly review. [The Core Web Vitals report](/blog/core-web-vitals-report-search-console/) explains the thresholds and the URL groups. ## Minutes 8 to 10: one striking-distance query Back in Performance, switch to the last 28 days, open Queries, and use the table's row filter on Position to narrow the list to roughly 8 to 20. Sort by impressions. Pick one query with real impressions, a page that matches its intent, and a click-through rate that looks low for its position. One query, not twenty. The job for the week is to improve that page's title, its opening paragraph or its internal links, then look again next Monday. [Striking-distance keywords](/blog/striking-distance-keywords-search-console/) has the method. ## Write one line per property The last thirty seconds: one line per property in a running log. "Week to [date]: clicks [up or down] [percent], mostly [page]; sitemaps fine; working on '[query]'." In twelve weeks that log is the backbone of a quarterly review. Search Console can hold some of this itself. A custom annotation on the Performance chart takes up to 120 characters, a property can hold up to 200 of them, and every user of the property can see them. Annotate releases, migrations and title rewrites on the day they happen, and next month's chart explains itself. Annotations do not show in comparison mode, so switch it off to read them. ## What to skip | Skip | Why | |---|---| | Site-wide average position | It moves whenever the mix of queries changes, even when nothing ranks differently | | The last two or three days of any chart | Provisional, and usually lower than they will end up | | Day-against-day comparisons | A Sunday is not a Monday | | The Links report | Changes slowly; monthly is enough | | Re-inspecting pages that are fine | Inspection is for a page you have a reason to doubt | ## Doing it across twenty properties The routine above is ten minutes for one property. For a portfolio, triage first: run step one on every property, and open the rest of the routine on the two or three whose numbers moved outside their usual range. The web interface makes that slow, because each property is a dropdown and a reload, and that is the part worth automating. ## The automated version QueryWatch puts every property you have access to on one list for free, grouped by client tag if you like, and each one opens on clicks, impressions, CTR and average position for the last 28 days with deltas against the previous period. That turns step one for a portfolio into a few taps rather than twenty reloads. The striking-distance view, positions 8 to 20 ranked by opportunity, is also free, and so are home-screen widgets if you would rather see the number without opening anything. With Pro, the weekly digest arrives every Monday with each property's week against the previous one, the queries that entered or left the top ten, the alerts that fired, and the biggest mover. Between Mondays, push alerts cover traffic drops and spikes, a new query entering your top ten, watched-URL indexing changes and sitemap errors, each with an evidence snapshot. [The alerts page](/search-console-alerts/) explains how the checks work. The routine still matters; the digest and alerts mean you run it knowing where to look. QueryWatch is an independent app and is not affiliated with Google. Questions: **How often should I check Google Search Console?** Google's own guidance says there is no need to sign in every day and suggests checking around once a month, or after changing the site. Weekly suits anyone responsible for other people's traffic, provided something else, an alert or a digest, watches the days in between. **Should I check Search Console every day?** Usually not. Performance data is finalised two to three days late, so a daily look mostly shows provisional numbers, and much of the day-to-day movement is weekday rhythm. An alert that fires on a real anomaly is more useful than a daily look. **What is a good weekly SEO metric to track?** Clicks for the last complete seven days against the seven before, with impressions alongside to explain any move. Site-wide average position is a poor weekly metric because it shifts whenever the mix of queries changes. --- ### Monthly SEO report for clients: a Search Console template URL: https://querywatch.app/blog/monthly-seo-report-for-clients/ Published: 8 October 2026 Summary: What a monthly client SEO report should take from Search Console, how to explain it, 28 days or a calendar month, and a template outline to copy. A monthly SEO report for a client should open with one number, clicks from Google search for the month, compared with the previous month and the same month last year, followed by one sentence on why it moved and one on what happens next. From Search Console, add impressions, click-through rate and average position, the pages and queries that gained and lost the most, a one-line health check on indexing, sitemaps and Core Web Vitals, and a short list of opportunities. Date it to the last finalised day, not the day you send it. Everything below that first paragraph is evidence. Clients read the number, the direction, the reason and the plan, and skim the rest, so the structure should follow the questions they ask in the order they ask them. ## What to include from Search Console | Section | Where it comes from | What it tells the client | |---|---|---| | Headline clicks | Performance → Search results, with Compare | Whether search traffic grew | | Impressions and CTR | Same report | Whether the site was shown more, and chosen more | | Pages that gained and lost | Pages tab, sorted by clicks difference | Where the change happened | | Top queries | Queries tab | What people searched to find them | | Country or device split | Countries and Devices tabs | Worth a line when one market or device moved | | Indexing health | Indexing → Pages | Whether the pages that matter are in Google | | Sitemaps | Indexing → Sitemaps | Whether Google can read the site's map | | Core Web Vitals | Experience → Core Web Vitals | Whether real visitors find the pages fast | | Manual actions and security | Security & Manual Actions | That nothing is wrong, in one line | | Opportunities | Queries at positions 8 to 20 | What next month's work is aimed at | A health check line that says "no issues" is a good line. It tells the client someone looked. ## How to explain the metrics to someone who is not an SEO Many clients have never opened Search Console, and the words in it mean something slightly different from what they sound like. A short glossary on the last page, written once and reused every month, saves a phone call. | Metric | Say this | Avoid saying | |---|---|---| | Clicks | Times someone clicked through to the site from Google's results | "Visitors" or "sessions", which analytics counts differently | | Impressions | Times the site appeared on a results page someone loaded | "Times people saw us"; the result may have been below the scroll | | CTR | The share of those appearances that turned into a click | "Conversion rate" | | Average position | The average of the highest spot the site held each time it appeared | "Our ranking", as if it were one fixed place | Clicks will never match the client's analytics, and someone will notice. [Search Console vs GA4](/blog/search-console-vs-google-analytics-4/) has the reasons in a form you can paste into a footnote. [Search Console metrics explained](/blog/search-console-metrics-explained/) goes deeper on how the four numbers move each other. ## 28 days or a calendar month? A 28-day window always contains exactly four of each weekday, which makes one period directly comparable with the next. For monitoring it is the sounder default, and QueryWatch's overview opens on the last 28 days for that reason. A calendar month matches how clients think, invoice and budget, but months differ in length and in their mix of weekdays. August 2026 had 31 days and 21 weekdays; September 2026 had 30 days and 22 weekdays. A business site that gets most of its searches on weekdays can look better in September than in August through the calendar alone. The practical answer is to report the calendar month, because that is the conversation the client is having, and to make year-over-year the headline comparison. September 2026 against September 2025 compares two 30-day months with 22 weekdays each, and strips out seasonality as well. Use month-on-month as the secondary line, and when the months differ in length, quote clicks per day alongside the total. Search Console keeps 16 months of performance data. That always covers the month just finished against the same month a year before, with about three months to spare, but a year-over-year view of last spring will already be out of reach by autumn. Anything older has to be exported while it is still there; [how long Search Console keeps data](/blog/search-console-data-retention-16-months/) covers the options. ## Date it to the finalised day Performance data is finalised two to three days after the day it describes, and Search Console counts days in California time. A report run on 1 October contains provisional days that will read differently when the client checks them. Send it on the 3rd or 4th, and print the range on the cover: "1 to 30 September 2026, data through 30 September". If you add an appendix table, remember that an export from Search Console is [truncated to 1,000 rows](https://support.google.com/webmasters/answer/12919797) while the totals shown are actual totals, so the rows in a large site's appendix will not sum to the headline. Say so in the notes. ## The narrative: three sentences before any chart Write these first, and build the rest of the report to support them. *Clicks from Google in September were [number], [up or down] [percent] on September last year and [percent] on August. Most of the change came from [page or topic], because [reason]. In October we are [action], and the next report will show whether it worked.* If the month contained a drop, the drop goes in the first sentence, with the page that caused it and what you did about it. A client who finds a fall on page three of a report they had to read for themselves starts wondering what else is not on page one. ## A template outline to copy 1. **Summary.** The three sentences above. 2. **Headline numbers.** Clicks, impressions, CTR and average position, each against the previous month and the same month last year. 3. **What moved.** The five pages that gained the most clicks and the five that lost the most, with the main query behind each. 4. **Health check.** One line each for indexing, sitemaps, Core Web Vitals, and manual actions or security issues. 5. **Opportunities.** Five queries at positions 8 to 20, each with the page that should rank and the change you propose. 6. **Work done and next month's plan.** What shipped, what is next, and what you need from the client. 7. **Notes on the data.** Date range, the finalised day, California time, the 1,000-row export cap, and a line on why clicks differ from analytics. 8. **Glossary.** The four definitions above. If the client asks about AI Overviews, Search Console has offered a Generative AI performance report to all websites since 31 August 2026, showing impressions in AI Overviews and AI Mode for sites that have enough of them. It is useful context rather than a headline; [AI Overviews and AI Mode in Search Console](/blog/ai-overviews-and-ai-mode-in-search-console/) explains what it can and cannot separate. ## How QueryWatch helps with the monthly report QueryWatch reads Search Console, so it covers the Search Console half of this template from a phone. On Pro, it generates a branded or white-label PDF with a property summary, the trend, the top queries and pages and the striking-distance list. The branded version carries the client's name, your logo and your colour; the white-label option removes QueryWatch's branding altogether. [White-label reports from your phone](/blog/white-label-search-console-reports/) shows what the client receives. Pro also has 16 months of history, custom ranges and period comparison, and a comparison CSV with previous-period columns and a delta on every row. The free tier has the CSV of the current view, the striking-distance list, and client tags and colours on every property. What it does not do matters for planning. There is no scheduled sending, no GA4 data, and no client login; you generate the report and send it yourself. [The agencies page](/search-console-for-agencies/) has the full picture. QueryWatch is an independent app and is not affiliated with Google. Questions: **When should I send a monthly SEO report?** On the third or fourth day of the following month. Search Console data is finalised two to three days late, so a report sent on the first contains provisional days that will show different numbers when the client checks them later. **Why do the clicks in my SEO report not match the client's Google Analytics?** The two tools count different things. Search Console counts clicks on Google results in California time; analytics counts sessions where its tag ran, which depends on JavaScript and cookie consent, in the site's own time zone. Put a one-line note in the report so the gap is explained before anyone asks. **How far back can a client SEO report compare?** Search Console keeps 16 months of performance data. That is enough to compare the month just finished with the same month last year, with about three months to spare, but not to compare older months year over year. Export each month as it closes and keep the files if you want a longer history. **Should a client SEO report include rankings?** Report average position from Search Console for the handful of queries that matter, with a plain explanation of what it is. A site-wide average position is not a ranking and moves whenever the mix of queries changes, so it makes a poor headline. --- ### Why Google never shipped a Search Console app URL: https://querywatch.app/blog/why-google-never-shipped-a-search-console-app/ Published: 5 October 2026 · Updated: 8 October 2026 Summary: Search Console has been a web tool for two decades. What Google tried in 2024, why the gap is still open, and what to ask of any third-party app that fills it. The short answer first, because most people arrive here having typed it into a search box: there is no Google Search Console app. Not on the App Store, not on Google Play, not in 2026. Search Console lives at search.google.com/search-console, it renders in a phone browser, and it has a public API. Everything you can install is a third-party client built on that API. QueryWatch is one of them. That answer tends to surprise people, because the product is old, central to how anyone with a website works, and made by a company that has shipped phone apps for plenty of less important things. So it is worth spending a few minutes on how we got here, what Google has actually tried, and what you should ask of any app that offers to fill the gap. ## Two decades of a web tool Search Console started life as Google Webmaster Tools and was renamed in May 2015. Through every redesign since, it has stayed a website. Google has shipped phone apps for several of its other business products over the same period; Search Console was never one of them. This is not an oversight nobody noticed. Search Console's mobile web has been the subject of forum threads and feature requests for as long as phones have had browsers, and the question "is there an app for this" is one of the more common things typed into Google about Google. The demand is real. The app is still not there. ## The one time it nearly happened In March 2024, Google tested an Android progressive web app for Search Console with a small group of SEOs. Screenshots circulated. It looked like the real thing: a property list, performance charts, a home screen icon. It was never released. There has been no public signal since: the Search Central blog has not announced a mobile app, nothing called "Search Console" has appeared under Google LLC on either store, and the mobile web interface has not gained an install prompt. A test with a handful of people, two and a half years ago, is the entire history of Google's Search Console app. ## Why the gap is probably still open Google has not said, so this is our reading rather than theirs. A few things line up. Search Console is free and earns nothing directly, which makes it a hard place to justify a second engineering team for a second platform. Its audience, while loyal, is small next to the consumer products that get native apps. The web interface does work on a phone, in the sense that every page renders and every number can eventually be reached. And the performance data is finalised two to three days after the fact, for everyone, which takes some of the shine off a "check it on the go" pitch: there is rarely anything new to see at 9 a.m. that was not there at 9 p.m. Most of all, there is an API. Google has published the Search Console API for years, and the terms allow third parties to build on it with a user's permission. From Google's side, the gap is already being filled by other people, at no cost to Google. That is a stable arrangement, and stable arrangements do not get disrupted by the company benefiting from them. ## What people do instead In practice, four things. A bookmark to the mobile web, which works and is free and is what most site owners do. Adding that page to the home screen, which gives it an icon and nothing else. A Looker Studio dashboard with Search Console as the data source, which is a good answer for a report and a poor one for a glance. And a third-party app, of which there are now a handful on iOS and Android, each with its own idea of what to charge for. We have written up the trade-offs of each in [four ways to check Search Console on your iPhone](/blog/check-search-console-on-your-iphone/). The honest summary is that the mobile web is the authoritative source for all of them, and none of the alternatives replace it; they add the things a website cannot do on a phone. ## What to ask of any third-party app Because every app in this category is reading your Google data with your permission, the questions that matter are less about charts and more about trust and pricing. Six are worth asking before you sign in to anything, including us. Does the app talk to Google directly from your phone, or through its own server? Either can be legitimate, but the app should tell you which, and why. Where does your Google token live, and what happens to it if the app offers push alerts? An alert has to be computed while your phone is asleep, which means something other than your phone needs permission to read your data. An app that offers alerts and does not explain this is hiding the most important sentence in its privacy policy. We have [a longer piece on exactly this question](/blog/where-does-your-google-token-go/). Does it show every property you have access to without paying? Several apps cap the number of sites on the free tier, which makes the free tier useless to anyone who manages sites for other people. Our position is that the number of properties is never the thing to charge for, and [the free tier reflects that](/blog/free-vs-pro-why-we-never-cap-properties/). Is it a rank tracker in disguise? Search Console reports the average position Google saw for queries you actually appeared for. Scraping search results to track positions for arbitrary keywords breaks Google's terms, and an app that does both is putting your account next to behaviour Google does not allow. Does the privacy policy name the specific Google APIs it reads, say where the data is stored, and give you a way to delete it that does not require asking nicely? And does it say, somewhere visible, that it is not affiliated with Google? Google's brand rules require it, and an app that skips it has either not read the rules or hopes you will not. ## Where QueryWatch sits QueryWatch is a native app for iPhone and Android that signs in to your own Google account and reads your own Search Console data. It adds the things the mobile web cannot do: push alerts when a property's clicks or impressions move, with the pages and queries that caused it attached; Home Screen and Lock Screen widgets; one screen for every property you manage, grouped by client; and exports a client can read. Every property is free, with real numbers on each. It is available on the [App Store](https://apps.apple.com/app/querywatch-search-console-app/id6811357323) and [Google Play](https://play.google.com/store/apps/details?id=com.empath.querywatch). The product page has the full comparison with the other options, including what each of them does better than we do: [Is there a Google Search Console app?](/google-search-console-app/) --- ### Four ways to check Search Console on your iPhone, compared URL: https://querywatch.app/blog/check-search-console-on-your-iphone/ Published: 5 October 2026 · Updated: 8 October 2026 Summary: The mobile web, an Add-to-Home-Screen icon, a Looker Studio report and a third-party app: what each one gives you on a phone, what it costs, and which fits you. Since Google has [never shipped a Search Console app](/blog/why-google-never-shipped-a-search-console-app/), checking your search traffic on a phone means choosing between four imperfect options. All four are reasonable. They differ in what they let you do standing in a queue, what they cost, and what you have to trust. Here they are, in the order most people try them. ## 1. The mobile web in Safari Open search.google.com/search-console on your phone and you get the real thing. Every report, every filter, every property you have access to, free, from Google. It is the authoritative source for the other three options, and nothing below replaces it. What it costs you is friction. Every visit starts with a login check and a property picker. The property switcher is a dropdown followed by a full page reload, so a morning check across twenty client sites is twenty of those. The tables are desktop tables made small: dense, horizontally scrolling, with controls sized for a cursor. And there is nothing it can do when you are not looking at it. No push notification when clicks fall, no widget, nothing on the home screen. One tip makes it tolerable for a single property: bookmark the performance report itself rather than the Search Console home. The report URL carries the property in its query string, so the bookmark skips the picker and lands on the chart. ## 2. Add it to the Home Screen In Safari, the share sheet has an "Add to Home Screen" option. Use it on the Search Console performance report and you get an icon that opens the page without the browser chrome. It feels more like an app, and for one property it is a perfectly good way to check a number. It is still the same web page. It cannot send a notification, it cannot put a number on the Home Screen or the Lock Screen, and if Google signs you out it is still a login screen. Treat it as a nicer bookmark, which is a fine thing to be. ## 3. A Looker Studio report Looker Studio connects to Search Console as a data source, and a report built on it works in a phone browser. You can add several properties as separate sources, build one page per client, and schedule the report to be emailed to you or to the client on a fixed day. This is the right answer for a report and the wrong one for a glance. It loads slowly on a phone, it shows you what you built rather than what changed, and its scheduling is a calendar, not a trigger: a drop on Tuesday arrives in whatever delivery was already planned. The data is the same two to three days behind as everywhere else, because that lag is Google's, not the tool's. If you already send clients a monthly Looker Studio PDF, keep doing it. It will not tell you anything on a Wednesday afternoon. ## 4. A third-party app There are now a handful of Search Console apps on iOS and Android, and they exist to add the things a website cannot do on a phone: a notification when a number moves, a widget, one screen for every property, an export you can send from the share sheet, a cache that still works on a train. Two things change when you install one. First, you are granting a third party access to your Search Console data, which Google classes as a sensitive permission. The app should tell you whether it talks to Google directly from your phone or through its own server, and if it offers push alerts it should say plainly where your token goes. We wrote [a separate piece on what to ask](/blog/where-does-your-google-token-go/), because this is the part that deserves suspicion. Second, each app charges for something: the number of properties, the number of queries, or depth of history and features. Read the free tier carefully. A free tier that caps properties is a demo, not a tier, if you manage sites for other people. Our comparison pages go through [each app on iOS, and Google's mobile web](/vs/), with what each one does better than QueryWatch. For what it is worth, QueryWatch lists every property you have access to on the free tier with real numbers on each, the Home Screen and Lock Screen widgets are free, and push alerts are the Pro feature. It is available on the [App Store](https://apps.apple.com/app/querywatch-search-console-app/id6811357323), and on [Google Play](https://play.google.com/store/apps/details?id=com.empath.querywatch) for Android. ## Which one is for you If you own one site and want to know how it did yesterday, a bookmark or a Home Screen icon is enough, and a widget from an app is a pleasant upgrade rather than a necessity. If you are a freelancer or run a small agency with five to thirty properties, the picker is the problem, and the thing you actually want is not a better chart but a list of every property with yesterday's clicks on it, plus a notification when one of them moves. That is an app's job. Keep Looker Studio for the client-facing report; it is better at that than any phone app. And whichever you pick, the mobile web stays open in a tab somewhere. It is where the numbers come from. --- ### How to get notified when your organic traffic drops URL: https://querywatch.app/blog/get-notified-when-organic-traffic-drops/ Published: 5 October 2026 · Updated: 8 October 2026 Summary: Search Console sees a drop days before you do and never tells you. Three ways to fix that, from a scheduled report to a push alert, and what any alert needs. Most people find out about a traffic drop in one of two ways: a client emails, or the monthly report comes round. Both are late. Search Console had the number days earlier and did nothing with it, because Search Console does not do anything with numbers. It shows them to whoever turns up. This post is about closing that gap. There are three realistic ways to do it, and whichever you choose, the alert has to be designed a certain way or it will be switched off within a week. ## What Search Console already emails you about Google does send email, and the email is worth keeping: manual actions, security issues, and large changes in indexing coverage all arrive in your inbox. Those are the things that are broken in Search Console's own terms. What Google does not email you about is an ordinary, unexplained fall in clicks on a page that still indexes fine. No manual action, no error, nothing in the coverage report, just thirty percent less traffic since Tuesday. Commercially, that is the one that usually matters first, and it is the one you have to arrange a notification for yourself. Keep one thing in mind for every option below: Search Console performance data is finalised two to three days after the fact, for everyone. No notification can arrive sooner than the data does. The goal is to hear about a drop the day the data is final, instead of the week after. ## Option 1: a scheduled report The least effort. Build a Looker Studio report on your Search Console data and schedule it to be emailed to you daily or weekly. It costs nothing and takes an afternoon. It is a calendar, not a trigger. The report arrives whether or not anything changed, and you still have to open it and read the chart to see that something did. If it comes weekly, a drop on Tuesday is read on Monday. If it comes daily, you have signed up to read a PDF every morning for the rest of your life. Some people are fine with that, and for a single property it is honestly not a bad deal. ## Option 2: a script The Search Console API is public, and a few dozen lines of Apps Script or Python can pull the latest complete day for a property, compare it with a baseline, and send you an email or a Slack message when the difference is large. Plenty of SEOs have one of these running. You get complete control and you own all the maintenance: the OAuth token that expires, the day Google's API returns a partial day you did not expect, the weekend when every property "drops" because you compared Saturday with Friday. In practice the code is the easy part. The hard part is the baseline design, which is the same for every option and is the subject of the last section. ## Option 3: an app with push alerts The newest option. A handful of Search Console apps on iOS and Android now offer push notifications when a property's traffic moves, QueryWatch among them, and at least one other that you will find on [our comparison pages](/vs/). There is a trade that every one of these apps makes, and you should know it before you enable anything. A notification has to be computed while your phone is asleep, and a phone cannot reliably run a job every few hours in the background. So the check runs on a server, and that server needs permission to read your Search Console data. That means a credential of yours lives somewhere other than your phone. The app should say where, how it is protected, and what happens when you turn alerts off. [We have written out our answers](/blog/where-does-your-google-token-go/), and the same questions apply to any other app. ## What a good alert has to carry, whichever way you build it The difference between an alert you keep and an alert you mute is not the delivery channel. It is six design decisions. Compare the latest complete day, not today. Today is always a partial day in Search Console, and a partial day always looks like a drop. Use a weekday baseline, not yesterday. A site's Sunday is not its Monday. Comparing each day with the same weekday over the previous four weeks absorbs the weekly rhythm; comparing it with the day before fires every Saturday, and even a seven-day average flags every quiet weekend on a site that lives on weekday traffic. Set a threshold that fits the site. A property with fifty clicks a day is noisy; one with fifty thousand is not. QueryWatch's default is a day that sits thirty percent away from its usual weekday, or two standard deviations from it, and both numbers can be changed per property. Whatever your rule, it should be adjustable per site. Attach the evidence. "Clicks down 34%" is a feeling. "412 clicks on Sunday, Sep 6 against a usual Sunday of 624, and /pricing explains 56% of it" is something you can act on, and still makes sense a week later when the numbers have moved on. Those figures are from our demo dataset, but they are the shape every alert should have. Cap it. One notification per property per day. An alert that fires twice for the same drop trains you to ignore it. Fire on spikes too. A sudden rise is information as well, usually happier, and occasionally the first sign of a page ranking for something it should not. That is the design. [The alerts page](/search-console-alerts/) describes how QueryWatch implements it, including the four rules, the six-hour check and what the notification actually looks like, and [the anatomy of a traffic alert](/blog/anatomy-of-a-traffic-alert/) goes through each field and why it is there. --- ### Anatomy of a traffic alert you can act on URL: https://querywatch.app/blog/anatomy-of-a-traffic-alert/ Published: 5 October 2026 · Updated: 8 October 2026 Summary: Why "clicks down 20%" is noise, and what a traffic notification has to carry: the value, the baseline, the dates, the pages behind it, and a cap. A traffic alert is a sentence that has to survive two readings. The first is on a phone at 11:40 on a Wednesday, between two other things, when all you need is to know whether to care. The second is a week later, when a client asks what happened and the numbers in Search Console have since been restated and no longer match what you remember. Most alerts fail the first reading by saying too little and fail the second by storing nothing. This is what we think an alert has to carry, field by field, using the example from QueryWatch's own Demo Mode dataset. The numbers are demo numbers; the structure is the point. ## The notification What lands on the Lock Screen is one line plus one sentence: *brightloom.co · clicks down 34%. 412 clicks on Sunday, Sep 6 vs a usual Sunday of 624. /pricing explains 56% of it.* Four facts, each doing a job. The property, because you manage more than one. The metric and the size of the move, so you know whether to stop walking. The observed value against its baseline, so "34%" is anchored to real clicks rather than a feeling. And the page that explains most of the move, which is the difference between an alarm and a lead. If the drop is mostly one page, you already know what kind of problem this is before you open anything. ## The baseline The percentage only means something if you know what it is measured against, and the wrong baseline produces the alert everyone switches off. QueryWatch compares the latest complete day with the same weekday over the previous four weeks: a Sunday against the last four Sundays, a Tuesday against the last four Tuesdays. Not today, because today in Search Console is always a partial day, and a partial day always looks like a drop. Not yesterday alone, because a site's Sunday is not its Monday, and comparing adjacent days fires every weekend. Not a plain seven-day average either: on a site that does most of its traffic on weekdays, a seven-day average makes every quiet Sunday look like a 40 percent drop, which is exactly the false alarm that gets an alert switched off. The rule that fires is a day at least thirty percent away from that weekday baseline, or at least two standard deviations from it, whichever you hit. Both numbers are adjustable per property. A property doing fifty clicks a day and one doing fifty thousand do not want the same threshold, and a rule you cannot change per site is a rule you will end up disabling for all of them. ## The evidence snapshot This is the field that handles the second reading. At the moment an alert fires, QueryWatch stores what it saw: the observed value, the baseline it was compared against, the dates of both, the threshold that was hit, and the top contributing pages at that moment. It does this because Search Console data keeps moving. Google finalises performance numbers two to three days after the fact and sometimes restates them afterwards. An alert that simply links to the live report will, a week later, open a chart that no longer shows the thing it alerted you about. The snapshot means the alert still says, verbatim, what it saw on the day. When the client asks, you can quote it. ## The screen it opens Tapping the notification lands on the change investigation for that day, which is the part that turns an alert into work you can do. It lists the pages that contributed to the move, each with its before and after numbers and the share of the drop it accounts for. In the demo example, /pricing went from 186 clicks to 68 and explains 56 percent; /features/automations from 92 to 41 for 24 percent; a blog post for 8 percent more. The same view exists by query. It also shows the counter-mover: the page that moved the other way. In the demo it is a blog post up 22 clicks on the same day. A counter-mover matters because a loss on one page and a gain on another often means Google swapped which of your pages it shows for a query, which is a different problem from a page losing visibility outright. We go through the whole investigation step by step in [clicks dropped, now what](/blog/clicks-dropped-what-now/). The free tier shows the top three contributors; Pro shows twenty and keeps the history. ## The four rules The anomaly rule above is the one people think of as "the alert", but there are three more, each switchable per property. A new query in the top ten: a query you are watching, or any query with at least fifty impressions that day, enters positions one to ten. This is the alert that tells you a page finally landed rather than that something broke. A watched URL changing its indexing state: a page you have marked as watched changes its index verdict or coverage state in Google's URL Inspection results. This catches the key page that silently drops out of the index, which otherwise shows up weeks later as a slow bleed in clicks. A sitemap error: a submitted sitemap's error count rises, or the sitemap disappears from Search Console. Usually the first sign that a deploy broke something structural. ## The cadence, and the cap The relay checks every six hours. It would be easy to promise every fifteen minutes and it would be useless, because the data does not change faster than Google finalises it. Polling more often re-reads the same numbers and risks alerting on a partial day. And there is a hard cap: one notification per property per day. If two rules fire for the same site on the same day, they arrive as one notification. An alert that fires twice for the same drop trains you to ignore it, and an app that cries wolf gets its notifications switched off within a week, after which it is worth nothing. ## The Monday digest Alerts fire when something moves. The digest arrives every Monday whether or not anything did: clicks, impressions, CTR and position for the week against the previous one, how many queries entered or left the top ten, which alerts fired, and the biggest mover across your properties. It is templated and deterministic. No model writes it and nothing in it is invented, which is a deliberate choice for something you might forward to a client. The last twelve are kept. ## What it costs you Alerts are a Pro feature, and turning them on is the one thing in QueryWatch that sends a Google credential off your phone, because something has to check Search Console while you are asleep. The app explains this in a consent screen before anything is sent, the relay is our own server rather than a third-party backend, and turning alerts off deletes the row immediately. [The alerts page](/search-console-alerts/) has the full version, and [where does your Google token go](/blog/where-does-your-google-token-go/) has the questions you should put to any app that offers the same thing. --- ### Clicks dropped. Now what? A 15-minute investigation from your phone URL: https://querywatch.app/blog/clicks-dropped-what-now/ Published: 5 October 2026 · Updated: 8 October 2026 Summary: A step-by-step way to find what caused a Search Console traffic drop before the client asks: confirm it, find the pages and queries, write the sentence. The notification says a property's clicks are down a third. You have fifteen minutes before the next thing, a phone, and a client who may or may not have noticed yet. This is the order to work in. Throughout, the numbers are from QueryWatch's Demo Mode dataset for a sample property called brightloom.co, so you can follow the same screens in the app without connecting an account. They are demo numbers, not a real customer's. ## Minutes 0 to 2: is it real? Two things make a drop look bigger than it is, and both are worth two minutes before you do anything else. First, check which day you are looking at. Search Console performance data is finalised two to three days after the fact, and the most recent day in any report is often partial. A partial day is always a drop. QueryWatch labels the last complete day it is showing; in the web interface, assume the last day or two are incomplete and look at the one before. Second, check what the drop is being compared with. A Sunday against a Saturday is not a drop, it is a weekend. The comparison that means something is the day against the same weekday in the weeks before it. In the demo, Sunday, Sep 6 had 412 clicks against a usual Sunday of 624, which is 34 percent down and well outside the normal spread. That is real. Move on. ## Minutes 2 to 5: which pages? Open the change investigation, or in the web interface, compare the day with the previous week in the Pages report and sort by the difference. What you want is not the list but its shape. In the demo, three pages explain 88 percent of the drop: /pricing lost 118 clicks and accounts for 56 percent on its own, /features/automations lost 51 for 24 percent, and a blog post lost 18 for 8 percent. That concentration is the first real finding. A drop that lives in one or two pages is a page problem: something changed on the page, in how Google indexes it, or in what Google shows for its queries. A drop spread thinly across fifty pages is a site problem, an algorithm update, seasonality, or a tracking artefact, and the rest of this investigation looks different. Here it is a page problem, and the page is /pricing. ## Minutes 5 to 8: which queries, and what kind of loss? Now look at the queries for the top page, and ask one question: did it lose impressions, or did it lose clicks while impressions held? Fewer impressions means Google is showing the page less, or lower. Check the position for the main queries. If the position fell, the page lost ranking; if the position held but impressions fell, demand fell or Google is showing the page for fewer queries. Clicks down with impressions steady is a click-through problem, and it almost always has a visible cause: a title Google has rewritten, a competitor's rich result sitting above you, a new SERP feature pushing the result down the page, or a date in the snippet that now looks stale. These are the drops that recover fastest, because the fix is on your side. ## Minutes 8 to 10: the counter-mover Look for the page that moved the other way on the same day. QueryWatch shows it next to the contributors; in the web interface, sort the comparison the other way. In the demo, a blog post gained 22 clicks while /pricing lost 118. The gain is small, but what matters is whether the two pages share queries. If a page lost clicks and a sibling page gained them for the same queries, Google has swapped which of your pages it shows, which is a cannibalisation problem, and the fix is on your site rather than in the SERP. If the counter-mover is unrelated, it is just noise in the other direction, and you can ignore it. [Spotting cannibalisation](/blog/keyword-cannibalization-search-console/) has the full method. ## Minutes 10 to 12: country and device Split the drop by country and by device. A drop confined to one country points at something local: a regional competitor, a localised SERP change, an outage in a CDN region. A drop confined to mobile with desktop holding steady is a rendering or page experience issue, or a mobile-specific SERP feature. A drop that is uniform across both says the cause is upstream of either, and that is the more common and less fixable case. ## Minutes 12 to 14: is the page still indexed? Run URL inspection on the top contributor. You are checking three things: that the page is still indexed, that the canonical Google chose is the one you expect, and when it was last crawled. A page that dropped out of the index, or whose canonical quietly moved to a parameter version of itself, explains an overnight drop entirely, and is the kind of thing a deploy breaks without anyone noticing. The free tier covers five inspections a day, which is enough for an investigation like this one. While you are there, open Search Console's messages. A manual action or a security issue will have an email too, but it takes ten seconds to rule out. ## Minutes 14 to 15: write the sentence The point of all this is to email the client before the client emails you, and the email is one paragraph: what moved, by how much, the likely cause, the next step, and when they will hear from you again. *Clicks on brightloom.co were down 34% on Sep 6 against the previous week. Most of it is /pricing, which is still indexed and still ranking but is getting fewer impressions for its main queries. I'm checking whether a competitor result moved above us and will update you Friday.* That is the entire product thesis, and it works without the app too: the difference between explaining a drop and being asked about one. ## What you cannot see from your phone Be honest about the limits. Server logs, how the page renders, what the SERP actually looks like for the query in the client's country, and whether a change shipped on Tuesday all live on a laptop. The fifteen minutes are for finding out which of those to open first, and for getting your sentence in before theirs. If you would rather the first two minutes happened without you, that is what [the alerts](/search-console-alerts/) are for: the notification arrives already pointing at the page. --- ### Why Search Console data is two or three days behind, and how to monitor it anyway URL: https://querywatch.app/blog/why-search-console-data-is-days-behind/ Published: 5 October 2026 Summary: The lag is Google's and applies to every tool. What is delayed, why, and how it changes the way you read a chart, build an alert and date a client report. Every Search Console tool gets the same complaint: the number on the screen is from the day before yesterday. It is a fair complaint and it has a simple answer. The delay is Google's. It applies to Google's own interface, to the API, and therefore to every app and dashboard built on either, QueryWatch included. Nobody downstream can shorten it. What you can do is stop letting it mislead you. ## What is actually delayed Search Console's performance data, meaning clicks, impressions, click-through rate and average position, is finalised two to three days after the day it describes. Google's own interface will show you fresher, provisional figures for the most recent day or so; they are flagged as such, and they move. The finalised numbers, which are what the API serves and what the reports eventually settle on, arrive a couple of days later, and even then Google occasionally restates a day after the fact. Other parts of Search Console run on their own clocks. URL inspection reflects Google's index as of the last crawl of that page. Coverage and sitemap reports update on their own schedules. But the chart everybody looks at, the one with clicks on it, is the one with the lag. ## Why Google has never published the full pipeline, and we are not going to pretend to know it. What Google does say is that the figures are provisional until they are finalised, and that finalisation takes time. It is reasonable to assume that aggregating every search impression on the planet, removing what Google considers invalid, and reconciling it across data centres is not a same-day job. The practical point is that this is a property of the source, and it is the same for everyone. ## How to read the chart Three habits, none of them hard. Ignore the last two days when you are looking for a trend. They are the ones most likely to be incomplete or to change, and a line that dips at the right-hand edge is usually just a line that has not finished being drawn. Compare complete days with complete days. A drop on the most recent day in a report is, more often than not, a partial day being compared with full ones. QueryWatch labels the last complete day it is showing rather than quietly presenting a partial day as a whole one; whatever tool you use, find out which day it considers final. And compare a day with the same weekday, or with the average of the previous week, rather than with yesterday. The lag is one way to invent a drop. The weekend is the other. ## What it means for alerts If you want a notification when traffic moves, the lag dictates the design. The comparison has to be the latest complete day against a baseline, never today. Checking more often than the data changes is pointless: QueryWatch's relay checks every six hours, and we would not promise every fifteen minutes even though it would be easy, because polling faster only re-reads the same numbers and risks alerting on a partial day. The honest promise is that you hear about a drop the day the data is final, instead of the week after. Restatements are why every QueryWatch alert stores an evidence snapshot at the moment it fired: the observed value, the baseline, the dates and the top contributors as they were. A week later, when Google has adjusted the day by a few percent, the alert still says exactly what it saw, which is what you need when a client asks what happened. [Anatomy of a traffic alert](/blog/anatomy-of-a-traffic-alert/) goes through the whole structure. ## What it means for client reports Date your reports to the last finalised day, not to the day you sent them. A monthly report that runs to the 31st includes two or three provisional days that will be different numbers when the client looks them up. Run it to the 28th and say so in the report. "Clicks through 28 October" is a sentence that will still be true in November; "clicks this month" is not. The same applies to any comparison that includes recent days. If the current period has two unfinished days in it and the previous one does not, the comparison is wrong before you start. ## The upside The lag has one real benefit: there is nothing to check hourly. Search Console is not a real-time tool, and any product that describes itself as "real-time Search Console" is showing you provisional data and hoping you will not notice when it changes. A number that is final is a number you can act on, send to a client, and quote a week later. Two or three days is the price of that, and it is a price worth paying. A Home Screen widget showing the last complete day is, for that reason, about the right amount of attention to pay to Search Console on most days. We wrote about [what the widgets show](/blog/search-console-widgets-iphone/) separately. --- ### Striking-distance keywords: the queries sitting at positions 8 to 20 URL: https://querywatch.app/blog/striking-distance-keywords-search-console/ Published: 5 October 2026 Summary: How to find the queries you already rank for just off page one, rank them by what they are worth, and turn the list into a quarter of work. A striking-distance query is one your site already ranks for, at an average position somewhere between 8 and 20: the bottom of page one or the top of page two. Google has already decided the page is relevant to the query. It just has not decided it is good enough to show prominently. That makes these the cheapest traffic on your site to go after, because you do not need new content, new links at scale or a new strategy. You need to make a page you already have a little better for a query it already appears for. This post is how to build that list from Search Console, how to rank it so you work on the right end first, and what to do with each row. ## Why 8 to 20 Click-through rate falls steeply as you move down a results page, and falls off a cliff between page one and page two. A query at position 14 is producing impressions, which is Google telling you the page is in the running, but almost no clicks. Move it to position 6 and the same impressions start converting. Nothing about the query's demand changed; you just crossed the line where people stop scrolling. Positions 1 to 7 are a different kind of work: holding, defending and incremental gains against pages that are already good. Positions below 20 are mostly aspiration; the page is in the index but not in contention. The band in between is where effort and reward line up. ## Finding them in Search Console In the web interface, open the Performance report, set the date range to the last 28 days (three months if the site is small and the numbers are thin), and switch to the Queries tab. Export to Google Sheets. In the sheet, filter the position column to between 8 and 20, then sort by impressions, descending. That is the list. Two refinements make it useful. First, add the page. A query is not actionable on its own; a query paired with the page Google shows for it is. In the Performance report, click a query and switch to the Pages tab to see which URL carries it, or export with both dimensions if you are comfortable in the API. Some queries will show two of your pages at different positions, which is its own problem and is covered in [spotting cannibalisation](/blog/keyword-cannibalization-search-console/). Second, filter out the noise: brand queries, which you rank for regardless, and queries with a handful of impressions, which will not move anything even if they hit position one. ## Ranking by what it is worth, not by position The mistake most spreadsheets make is sorting by position, so the query at 8.2 sits at the top. Position is not opportunity. A query at position 9 with forty impressions a month is worth less than a query at position 15 with four thousand, because the second one has far more clicks waiting behind the page-one line. The ranking that works is by what a move would be worth: roughly, impressions multiplied by the difference between the click-through rate you would expect at the target position and the rate you get now. You do not need the exact curve. Sorting by impressions within the band gets you most of the way, and if you want the extra precision, any published CTR-by-position table will do. QueryWatch's striking-distance view does this ranking for you, on the property's own latest complete day, and it is on the free tier. It exists because this is the report every agency builds by hand in a spreadsheet, every quarter, for every client, and it should take one tap rather than an afternoon. ## What to do with each row Work from the top of the ranked list, one query-and-page pair at a time. The checklist is short and the order matters. Make the page answer the query explicitly. Open the page and read it as someone who typed that query. If the answer is in paragraph six under a heading that says something else, move it to the top and give it a heading that uses the query's words. This single change does more than everything below combined, because it is the thing Google is checking. Rewrite the title and the snippet. The title should contain the query or its obvious variant. The meta description should promise what the page delivers. Both affect click-through rate, and click-through rate at position 9 is where the fastest gains live. Add internal links from pages that already rank well, with the query or something close to it as the anchor text. Three links from strong pages is a meaningful signal and costs twenty minutes. Add what is missing. Compare the page with the ones above it for the query. If they all have a table, a comparison, a worked example or an answer to a follow-up question and yours does not, that is the gap. Check for a sibling page. If two of your pages appear for the query at positions 11 and 14, you are competing with yourself, and consolidating them usually moves the survivor further than any amount of polishing either. Then watch it. Save the query to a watchlist, and give it four to eight weeks. In QueryWatch the watchlist holds five queries on the free tier and is unlimited on Pro, and Pro's new-top-ten alert notifies you the day a watched query enters positions 1 to 10, which is a satisfying message to receive. ## How often For retainer work, monthly is about right: rebuild the list, see what moved, pick the next three pairs. The list changes slowly, and the point of it is to answer "what should we do next quarter", which is a harder question to answer from a phone than "what happened yesterday", and the one clients actually pay for. --- ### Spotting keyword cannibalisation in Search Console URL: https://querywatch.app/blog/keyword-cannibalization-search-console/ Published: 5 October 2026 Summary: How to tell when two of your pages are competing for the same query, when that is fine, and how to fix it when it is not. The manual method, and the detector. Keyword cannibalisation is what happens when two or more of your own pages appear for the same query and Google cannot settle on which one to show. It alternates between them, or splits the impressions, and neither page builds the signals it would have built alone. The result is usually two pages stuck at positions 9 and 14 where one page could be at 5. It is also one of the most over-diagnosed problems in SEO, so this post covers both halves: how to find it in Search Console, and how to tell when what you have found is not a problem at all. ## What it looks like in the data Three symptoms, and you will usually see two of them together. The query's average position bounces. Not a steady decline, but a line that sits at 8 one week, 13 the next, 9 the week after, with no change on your side. Google is swapping which page it shows, and the average is blending two different positions. Two pages share the impressions for one query, with neither growing. Each has a slice of the demand and a middling position, and polishing either one on its own has not moved it. The click-through rate is lower than the position suggests, because on the days Google shows the wrong page, the snippet does not match what the searcher wanted, and they scroll past. ## Finding it in Search Console For a single query, the web interface does this directly. Open the Performance report with a date range of three months, so the numbers are smooth, go to the Queries tab, click the query, then switch to the Pages tab. If more than one page appears with meaningful impressions, note each page's position and impressions. Two pages at similar positions, splitting the impressions roughly evenly, is the classic shape. For a whole site, you need the query-and-page pairs together, which means exporting from the API or using a tool that reads it. Group the pairs by query, keep the queries with two or more pages, and sort by total impressions so the ones that matter are at the top. A query where a second page has three impressions is not cannibalisation; it is noise. The list you want is the one where real demand is being split. QueryWatch's cannibalisation detector, a Pro feature, does that grouping for you and shows the queries where two of your pages are competing, ranked by what is at stake. The free striking-distance view will also surface pairs, because a query with two of your pages at 11 and 14 is very often a striking-distance query with a cannibalisation problem underneath it. ## When it is not a problem Before you merge anything, check three things. Are the positions stable? Two pages that each hold a steady position for a query are not fighting; Google has decided they both belong, often because the query carries two intents and you have a page for each. A buying guide and a product page for the same term can coexist indefinitely. Is Google showing both at once? If the two pages appear as two listings on the same results page, or one as a sitelink of the other, you are getting more real estate, not less. That is the opposite of a problem. Is the second page tiny? A page with a handful of impressions for a query another page owns is just the index being thorough. Leave it. The case that needs fixing is the bouncing one: a single intent, two pages, positions that trade places, and a combined result that is worse than either page would manage alone. ## Fixing it There are four moves, and the right one depends on how different the two pages are. Consolidate. If the pages say roughly the same thing, keep the stronger one, move anything unique from the weaker one into it, and redirect the weaker URL permanently. This is the move that works most often and the one people avoid longest, because deleting a page feels like losing something. You are not; you are concentrating it. Differentiate. If the pages serve different purposes but have drifted onto the same query, retarget one of them. Change its title, its heading and its opening to the query it should own, and remove the contested term from its title. This is the fix when consolidation would destroy a page that does a job. Canonicalise. If the pages are near-duplicates that both have to exist, parameter versions, print versions, a syndicated copy, point the duplicate's canonical at the original. Point the internal links one way. Whichever page you choose, every internal link that uses the query as anchor text should go to it, and none to the other. Inconsistent internal linking is often how the cannibalisation started. ## Watching the fix Give it four to eight weeks. The survivor's position for the query should settle first, then rise. Save the query to a watchlist so you notice when it does; in QueryWatch the watchlist holds five queries on the free tier, unlimited on Pro. One more place cannibalisation shows itself: in a traffic drop. When one page loses clicks on the same day a sibling page gains them, Google has swapped which page it shows, and the change investigation's counter-mover is where it turns up. [Clicks dropped, now what](/blog/clicks-dropped-what-now/) has that step. --- ### Search Console widgets for your iPhone Home Screen and Lock Screen URL: https://querywatch.app/blog/search-console-widgets-iphone/ Published: 5 October 2026 Summary: The number without opening anything: what the QueryWatch widgets show, how to add one per property, when they update, and why they are free on every plan. The most common question anyone with a website asks Search Console is "how did we do yesterday", and the most common thing they do with the answer is nothing. It is a glance. On the mobile web that glance costs a browser, a login check, a property picker and a wait. A widget costs nothing, which is why the widget is the feature that decides whether an app like this one becomes a habit. This is what the QueryWatch widgets do, how to set them up, and the one thing they are not. ## What a widget shows Each widget is one property. It shows that property's clicks for the last complete day Google has finalised, the change against the previous period, and a sparkline of the recent days so you can see whether the number is a blip or a trend. That is all, deliberately. A widget that tries to show four metrics shows none of them at a glance. Home Screen widgets come in the usual sizes. Lock Screen widgets are the small ones that sit under the clock, and for a property you check every morning they are the right place: the number is there before you unlock the phone. ## Setting one up On iPhone, press and hold an empty area of the Home Screen, tap Edit, then Add Widget, and search for QueryWatch. Pick a size and add it. Then press and hold the widget itself, choose Edit Widget, and select the property it should show. Repeat for each property you want on the Home Screen; a widget per client is a sensible way to lay out an agency's phone, and iOS lets you stack several of the same size and swipe between them. For the Lock Screen, press and hold the Lock Screen, tap Customise, choose the Lock Screen, tap the widget area under the clock and pick QueryWatch. On Android, press and hold the home screen, choose Widgets, and find QueryWatch in the list. If the widget shows no data, open the app once so it has signed in and loaded the property; widgets read from the app's cache rather than from Google directly. ## When it updates Honestly: less often than you might expect, and it does not matter. iOS decides when widgets refresh, within a budget it manages per app, so a widget is not a live ticker. But Search Console data is finalised two to three days after the fact anyway, so the number a widget shows is a finished day, and it changes once a day, not once a minute. A widget that refreshed every five minutes would show the same number for five minutes at a time. [Why the data is days behind](/blog/why-search-console-data-is-days-behind/) explains the lag; the widget just lives with it, which is the right amount of attention to pay to Search Console on most days. ## What a widget is not A widget is passive. It shows you the number if you look. It will not tap you on the shoulder when the number falls, and no widget can, because a widget only runs when the system draws it. If what you want is "tell me when it moves", that is a push alert, which is a different mechanism: something has to check Search Console while your phone is asleep, which means a server with permission to read your data. Alerts are QueryWatch's Pro feature, and [the alerts page](/search-console-alerts/) explains exactly what that involves, including where your Google token goes. The widget and the alert complement each other: the widget for the daily glance, the alert for the day you were not glancing. ## Why they are free Widgets are on the free tier for every property, on every plan. Some apps in this category charge for them, and we understand why: the widget is the thing people want most. That is exactly why we do not. A widget is the reason you open the app, and charging for the reason to open the app is how a free tier turns into a demo. What we charge for is depth: sixteen months of history, the push alerts, the exports, the unlimited watchlist. [The free and Pro split](/blog/free-vs-pro-why-we-never-cap-properties/) is written out in full, and the short version is that the number of properties and the number of widgets are never the thing you pay for. --- ### Managing 20+ client properties in Search Console without losing your mind URL: https://querywatch.app/blog/managing-client-properties-search-console/ Published: 5 October 2026 · Updated: 8 October 2026 Summary: The property picker is not built for agencies. How to run a portfolio of client sites from a phone: tags, colours, favourites, multiple accounts and alerts. If you run search for other people, the hard part is not reading a chart. It is holding twenty or thirty properties in your head, knowing which three need attention this week, and avoiding the specific professional damage of a client noticing a drop before you did. Search Console is a superb tool for one site at a time. At twenty, its interface becomes the problem. This is how the portfolio problem actually breaks down, and how QueryWatch is built around it. ## Three ways a portfolio goes wrong The picker. Search Console's property switcher is a dropdown followed by a full page reload. A morning check across twenty client sites is twenty of those, on a phone, and after the sixth one you stop. Which means the properties at the bottom of the list get looked at monthly, if then. The account mess. Agency properties are never all under one login. Some are yours, verified from your own account. Some were granted by the client, under their account, with a permission level they chose. Some live in a second Google account you made three years ago for a reason you no longer remember. Search Console shows you one account's view at a time. The silent property. The dormant client site, the one on a small retainer that nobody opens, drops thirty percent in March and nobody knows until the client's quarterly review. There was no error, no manual action, nothing Google would email about. Just less traffic, unobserved. ## A portfolio, not a picker The fix for the first problem is a different shape of screen: one list, every property you have access to, with yesterday's clicks and a sparkline on each row. You read the whole portfolio the way you read a stock list, and you only open a property when its row looks wrong. In QueryWatch that list is the home screen, and the organisation on it is yours. Client tags group properties by who they belong to; each tag gets a colour, so a row is recognisable before you read it. Favourites pin the four sites you check daily to the top. Hidden properties take the dormant ones you inherited out of the list without removing your access. And the permission level is shown per property, owner or full or restricted, so you know before you promise a client something whether you can actually do it. Our demo dataset has a property tagged Brightloom in orange next to one you only have restricted access to, which is roughly what a real agency's list looks like. All of that is on the free tier. Every property, with real numbers on each, tagged and coloured however you like. ## Multiple Google accounts The second problem is a Pro feature, because it is an agency problem rather than an edge case. Multi-account switching lets you sign in with more than one Google account and see the properties from all of them in the same portfolio. The client-granted properties and your own sit in one list, tagged by client rather than by which login they happen to live under. ## The silent property The third problem is what the alerts are for, and it is the one that costs money. A push notification when any property's clicks or impressions move outside their normal range, with the page that explains most of it attached, means the dormant site gets watched exactly as closely as the big one, without you doing anything. [How to get notified when traffic drops](/blog/get-notified-when-organic-traffic-drops/) covers the options, including the ones that are not us. ## A weekly rhythm What a portfolio on a phone looks like in practice, with Pro: Monday morning, the digest lands: every property, the week against the previous one, which queries entered or left the top ten, which alerts fired, and the biggest mover across the portfolio. You know which two clients need a sentence in their update before you open a laptop. Wednesday at 11:40, a push says one property's clicks are down 34 percent and one page explains 56 percent of it. You open the change investigation on the walk back from lunch and see the page, its before and after, and the one URL that moved the other way. You email the client first. Thursday, before the call, a branded PDF from the phone with their name, your logo and your colour. [Reports a client can read](/blog/white-label-search-console-reports/) goes into what should be in it. ## Priced per person, not per property Pro costs $4.99 a month or $14.99 a year and covers every property you have access to, three or thirty. This is the one thing we will not change. Every competing app we have looked at either paywalls the property count or hides most of the data until you pay, which makes the free tier useless for exactly the person this is built for. We charge for depth, history, alerts, exports, because depth is what costs us money to provide; the number of sites is never the thing you pay for. [The comparison pages](/vs/) have each app's pricing from its own listing. ## What is not there yet Being clear now is cheaper than disappointing you later. There are no read-only client logins; sharing a live dashboard with a client is on the roadmap, and today you send an export. There are no team seats; one person, one subscription, and three people at an agency are three subscriptions. There is no GA4 overlay, and no Bing Webmaster Tools yet, though Bing is next. And there is no rank tracking, which is a permanent non-goal rather than a gap: [why QueryWatch is not a rank tracker](/blog/why-querywatch-is-not-a-rank-tracker/) explains. --- ### White-label Search Console reports from your phone URL: https://querywatch.app/blog/white-label-search-console-reports/ Published: 5 October 2026 · Updated: 8 October 2026 Summary: What a client actually reads in a search report, what the branded and white-label PDF contains, when to send CSV instead, and the sentence to put on top. The report is the artefact a client judges you on, and for most freelancers it is built the same way every month: on a laptop, on Thursday night, by pasting Search Console exports into a spreadsheet template and hoping the chart updates. This post is about what should be in it, what QueryWatch generates from the phone, and when a PDF is the wrong format. ## What clients actually read Less than you think, and in a fixed order. They read one number, usually clicks this month against last. They read the direction. They read the sentence that says why. And they read what you are going to do next. Everything after that is evidence, and evidence is skimmed, not read. That has a consequence for the report. The forty-row query table is not the report; it is the appendix that proves you did the work. The top of the first page should be the number, the trend, and the explanation, and the sections should follow the questions a client asks in the order they ask them: how did we do, what changed, why, what now. The "what now" is where a striking-distance list earns its place. A page of queries sitting at positions 8 to 20, ranked by what moving them would be worth, is a plan a client can see, and it is the part of the report that justifies next quarter's retainer. [Striking-distance keywords](/blog/striking-distance-keywords-search-console/) explains how the list is built. ## What the QueryWatch PDF contains The report is generated on the phone, with the same components the app draws its own screens with, and goes out through the normal share sheet to Mail, Slack, Files or wherever the client lives. It carries a property summary, the trend, the top queries and pages, and the striking-distance list, dated to the last complete day of data. A branded report carries the client's name, your logo and your colour. The white-label option removes QueryWatch's branding altogether, so what arrives in the inbox is your report with nothing on it that is not yours. Both are Pro features; the free tier has the CSV described below. The colour is the client tag's colour from your portfolio, so a report for the client you have tagged in orange arrives in orange without any setup, which is a small thing that makes the report look like it came from somewhere organised. ## When to send CSV instead Some clients live in spreadsheets, and for them a PDF is a picture of data they would rather have as data. Send the CSV. A CSV of whatever table you are looking at is on the free tier, and it carries a context header row naming the property, the date range and the dimension, so a file that has been sitting in a Slack thread for a month still says what it is. The comparison CSV, with previous-period columns and a per-row delta, is Pro; it is the one to send when the client's own analyst wants to see the movement rather than the snapshot. ## Date it to the finalised day Search Console performance data is finalised two to three days after the fact. A report run on the 31st includes two or three provisional days that will show different numbers when the client looks them up in Search Console, which is exactly the kind of discrepancy that erodes trust for no reason. Run the report to the last complete day and say so on it: "through 28 October". [Why the data is days behind](/blog/why-search-console-data-is-days-behind/) has the detail, but the rule is one line. ## The sentence on top The PDF is evidence. The message is the email you attach it to, and it is one paragraph: the number, the direction, the cause, the next step, and when they will hear from you. If the month had a drop in it, the sentence about the drop goes first, with the page that caused it and what you did, because a client who finds the drop on page three of a report they had to read themselves is a client who wonders what else you are not mentioning. If you have the alerts on, you will usually have already sent that sentence the day the drop happened, and the monthly report confirms it rather than revealing it. That is the difference between explaining a drop and being asked about one, and it is most of what an agency is paid for. ## What the report does not do There is no scheduled sending; you generate the report when you want it and send it yourself. There is no client portal or read-only login; sharing a live dashboard is on the roadmap, not in the app yet. And there is no GA4 or revenue data in it, because QueryWatch reads Search Console and nothing else. If your client wants a report that arrives on the first of the month without you touching it, a scheduled Looker Studio delivery is the right tool, and it is a good one. The PDF from the phone is for the other case: the call is in an hour, the number moved, and you want something with their name on it in their inbox before you dial in. --- ### Where does your Google token go? Questions to ask any Search Console app URL: https://querywatch.app/blog/where-does-your-google-token-go/ Published: 5 October 2026 Summary: Every Search Console app reads your Google data with your permission. Seven questions to ask before you sign in to one, with QueryWatch's answers written out. Every third-party Search Console app, this one included, works the same way: you sign in with Google, grant the app permission to read your Search Console data, and from then on the app holds a credential that can read everything Google knows about your sites' search traffic. Google classes that permission as sensitive, and it is right to. Reviews of apps in this category are full of people asking, reasonably, what exactly they just handed over and to whom. So here are the questions we think you should ask before signing in to any of them, with our own answers written out. The questions are more important than the answers; put them to every app, and be suspicious of any that cannot answer plainly. ## What are you actually granting? When you sign in, Google shows a consent screen listing what the app is asking for. For a Search Console app, it is the Search Console scope: permission to list your properties and read their performance data, inspect URLs and view sitemaps on your behalf. Google requires apps requesting that scope to go through its verification process, and an app that has not will show you a warning screen saying so. Read the consent screen. It is the one document in this process that Google wrote rather than the app. QueryWatch asks for the Search Console scope and nothing else: no Gmail, no Drive, no Analytics. [The privacy policy](/privacy/) names the specific API calls it makes. ## Does the app talk to Google directly from your phone, or through its own server? Either can be legitimate, but it determines whether a copy of your data exists anywhere other than your phone and Google. QueryWatch talks to Google directly from the device. On iPhone, your refresh token is stored in the Keychain. On Android, Google Play services hold the grant and the app never receives a refresh token at all. With the default settings there is no row about you on any server of ours, because there is no server in the path. ## If it offers push alerts, where does the credential go? This is the question that matters most, and the one apps are quietest about. A notification has to be computed while your phone is asleep, and a phone cannot reliably run a background job every few hours. So the check runs on a server, and that server needs permission to read your Search Console data. An app that offers alerts and does not explain this is leaving out the most important sentence in its privacy policy. Our answer: with alerts off, which is the default, nothing leaves the device. When you turn alerts on, a Google credential is sent to our relay, the refresh token on iPhone, or on Android a one-time authorisation code that the relay exchanges for a token of its own. The relay is our own server in Germany, not a third-party backend service. The credential is stored encrypted at rest with libsodium and decrypted in memory only while a scheduled check runs, every six hours. The app shows you exactly this, in a consent screen of four sentences, before anything is sent. ## What happens when you turn it off? Ask whether "off" means deleted or means archived. For QueryWatch, turning alerts off deletes the row, the rules, the watched URLs and the alert history immediately. Not soft-deleted, not kept for thirty days. Gone, and you can turn them back on later with a fresh grant. ## Can you delete everything without asking anyone? An app that requires you to email support to remove your data has given you a promise rather than a control. There should be a route that needs nobody's cooperation. For QueryWatch there are three. In the app: Settings, then Privacy and data, then Delete all my data. Without the app: revoke QueryWatch's access at myaccount.google.com/permissions, which makes every credential it holds useless immediately, whether or not we have deleted it. And a public page, [delete my data](/delete-my-data/), that needs no login and says what exists in the first place, so you know what you are deleting. If you had alerts on and want to be certain the relay row is gone, an email to hello@querywatch.app gets it removed, but you do not need us for the first two. ## Does the privacy policy name the APIs and carry Google's Limited Use wording? Google requires apps that use its APIs to commit to its Limited Use policy: the data is used to provide the feature you asked for, not sold, not used for advertising, not read by humans except in narrow cases. A privacy policy that does not carry that commitment, in Google's words, has either not been reviewed or is hoping you will not look. Ours does, verbatim, and it names everyone who sees anything: Apple for payment, RevenueCat for subscription status, Google Analytics 4 with Firebase Crashlytics for anonymous product analytics and crash reports, and the German server the relay runs on. Nobody else, and your Search Console data goes to none of them. ## Does it also track rankings? A rank tracker scrapes Google's results pages to find positions for keywords, which breaks Google's terms of service. An app that holds your Google credential and also runs scraping infrastructure is putting your account next to behaviour Google does not allow. QueryWatch shows the average position Google itself reports in Search Console, for queries your site actually appeared for, and will never scrape. [Why QueryWatch is not a rank tracker](/blog/why-querywatch-is-not-a-rank-tracker/) is the longer version. ## Stay suspicious, including of us A consent screen is a promise, not a proof. What you can verify is the permissions page in your Google account, which shows every app with access and what it was granted, and which lets you revoke any of them in one tap. Check it after you sign in to anything, and check it again in a month. An app that is honest about where your token goes should be pleased that you did. --- ### Search Console metrics explained: clicks, impressions, CTR and position URL: https://querywatch.app/blog/search-console-metrics-explained/ Published: 5 October 2026 Summary: What the four numbers on the performance report actually count, how they move each other, which one to watch weekly, and the traps in average position. The Search Console performance report has four numbers across the top, and most people watch the wrong one. This is what each of them counts, how they move each other, and which one deserves your attention on a Monday morning. ## Clicks A click is counted when someone clicks a link to your site from a Google search results page. It is the metric closest to a visit, though it will never match your analytics exactly, because the two tools count different things in different ways and some visits never report back. Clicks are the number to watch. They are what traffic is, they are what a client means when they ask how the site is doing, and they are what every other number on the report exists to explain. QueryWatch's headline figure, total clicks across your properties this month, is clicks for that reason. ## Impressions An impression is counted when a link to your site appears on a results page that someone loaded. The link does not have to be seen: if your result is at position nine and the searcher never scrolls that far, it still counts, as long as they did not have to click to load more results. For a single search, a page gets at most one impression regardless of how many links to it appear. Impressions are visibility. They tell you how often Google is showing you at all, which makes them the first thing to check when clicks fall: fewer impressions means you are being shown less, or lower; steady impressions with fewer clicks means you are being shown but not chosen, which is a different problem with a different fix. ## Click-through rate CTR is clicks divided by impressions. It is the metric that tells you whether, given the chance, people chose you. It is also the one that moves for reasons that have nothing to do with ranking. A rewritten title, a new rich result above you, a date in your snippet that now looks old, or a featured snippet that answers the question before anyone clicks will all move CTR while position holds still. That is why CTR is where the fastest wins live: the fix is on your side of the page, and it takes an afternoon rather than a quarter. Compare CTR between queries at similar positions, not across the whole report. A brand query at position one will always have a high CTR and will drag the average up; a page that ranks for twenty informational queries at position eight will drag it down, and neither tells you anything about the other. ## Average position Position is the average of the topmost position your site held for each impression. Two things in that sentence cause most of the confusion. "Topmost" means that if you have results at positions 3 and 8 for the same search, that search counts as position 3. "Average" means that a page showing at position 2 for some searches and position 20 for others reports position 11, which is a number nobody ever actually saw. Average position is a summary, not a rank, and treating it like a rank-tracker number leads to real mistakes. The most common is panicking when average position gets worse because the page started appearing for new, lower-ranking queries: more impressions, worse average, and nothing wrong. Position is also not the same thing as rank in a rank tracker, which reports a specific result for a specific location and device at a specific time, including for keywords you do not appear for at all. Search Console tells you what Google actually showed, averaged over real searches, and only for queries you were in. [Why QueryWatch is not a rank tracker](/blog/why-querywatch-is-not-a-rank-tracker/) is about that distinction. ## How they move each other A drop in clicks has one of two shapes. Impressions fell too, in which case Google is showing you less, and the question is why: a position change, a competitor, a change in demand, a page dropping out of the index. Or impressions held and CTR fell, in which case Google is still showing you and people have stopped choosing you, and the answer is on the results page, in your title and snippet and whatever now sits above them. Working out which shape you are looking at is the second step of any investigation. [Clicks dropped, now what](/blog/clicks-dropped-what-now/) walks through all of them. ## Which one to watch weekly Clicks, against the previous week. Impressions when clicks move, to see which shape the move has. CTR when you are working on titles and snippets. Position when you are working on a specific query, and only for that query, never as a site-wide average. The report defaults to showing all four lines on one chart, which is the least useful way to look at them. Pick clicks, compare against the previous period, and only turn the others on when clicks have asked a question. And remember the last two or three days are not finished yet: [the data is days behind](/blog/why-search-console-data-is-days-behind/), for everyone, and a dip at the right-hand edge is usually just a day that has not been counted. --- ### Why QueryWatch is not a rank tracker, and never will be URL: https://querywatch.app/blog/why-querywatch-is-not-a-rank-tracker/ Published: 5 October 2026 Summary: Search Console position and rank-tracker rank measure different things. What each is for, why scraping Google is off the table, and how the two fit together. The obvious feature request for any app that shows you search data is rank tracking: type in a keyword, see where you rank, watch it daily. QueryWatch does not do that, will not do that, and this post is the reasoning, because "we chose not to" is more useful to you than a missing menu item. ## What a rank tracker does A rank tracker runs a Google search for a keyword, from a chosen location and device, and records where your URL appears. It repeats that daily, for a list of keywords you chose, including ones you do not rank for yet and ones your competitors rank for instead. The result is a clean daily position per keyword per location, which is a useful thing to have. To get it, the tracker has to query Google at scale, which means either scraping results pages directly or paying a service that does. Google's terms of service do not permit automated queries of its search results, and never have. The entire category operates in a space Google tolerates rather than allows. ## Why we will not Three reasons, in order of weight. The first is your account. A Search Console app holds a credential for your Google account, granted through Google's own OAuth process and subject to Google's verification. Running scraping infrastructure next to that credential puts your account alongside behaviour Google does not allow, and asks you to trust that the two never touch. We would rather not ask. The second is honesty about what the product is. QueryWatch is a client for Search Console. It reads what Google reports about your sites, through Google's public API, with your permission. A rank tracker is a different product that happens to show a number with the same name, and bolting one onto the other would make both worse. The third is the name. An earlier working name for this app had the word "Rank" in it, and we dropped it partly for this reason: it advertised the one feature we had already decided never to build. QueryWatch watches queries, the ones you already appear for, which is exactly what Search Console is. ## What Search Console's position actually is Average position is the average of the topmost position your site held for each impression, over real searches by real people, for queries you actually appeared for. It is not a probe from a data centre; it is a summary of what happened. That makes it different from rank in two ways that matter. It is personalised and localised the way real results are, because it is made of real results, so it reflects what your searchers saw rather than what a logged-out browser in a particular city saw. And it is an average, so a page shown at position 2 for some searches and position 20 for others reports 11, a number nobody saw. [Search Console metrics explained](/blog/search-console-metrics-explained/) goes through the traps. It is a better number for some questions and a worse one for others, and the mistake is treating either as the whole truth. ## What you lose without a rank tracker Keywords you do not rank for yet, because Search Console has no row for a query you never appeared for. Competitor positions, because Search Console only knows about your sites. A daily, location-specific position for a keyword a client cares about, because the average blends locations and days. And tracking of SERP features, like whether a featured snippet or a map pack sits above you. If you need those, you need a rank tracker as well as this, and most SEO professionals already pay for one inside Semrush, Ahrefs, SE Ranking or similar. Nothing about QueryWatch replaces that, and we would rather say so than pretend. ## How the two fit together A rank tracker answers "where would we show, if someone searched this, here, today". Search Console answers "what did we actually show, over every real search, and did anyone click". The first is for planning and for keywords you are chasing. The second is for knowing what is happening to the traffic you have. Inside Search Console, two things do part of a rank tracker's job for the queries you already appear for. A watchlist of queries, five on the free tier and unlimited on Pro, keeps the ones you care about one tap away. And Pro's new-top-ten alert notifies you the day a watched query, or any query with at least fifty impressions, enters positions 1 to 10, which is the one rank-tracking event most people actually want to hear about. The striking-distance view is the planning half: [the queries at positions 8 to 20](/blog/striking-distance-keywords-search-console/), ranked by what moving them would be worth. ## The short version If an app offers you both Search Console data and rank tracking in one place, ask how it gets the second and what that means for the credential it holds for the first. We would rather be the Search Console companion that is clearly only that, and leave rank tracking to the tools built for it. [The comparison pages](/vs/) say what each of the other apps does and does not do, in their own words. --- ### Free vs Pro: what you get without paying, and why we never cap properties URL: https://querywatch.app/blog/free-vs-pro-why-we-never-cap-properties/ Published: 5 October 2026 · Updated: 8 October 2026 Summary: The full free tier, what Pro adds at $4.99 a month or $14.99 a year, and the reasoning behind no property cap, no free trial and no weekly plan. Pricing pages tell you what things cost. This is the other half: why the lines are drawn where they are. If you only want the numbers, they are in the next two sections and nothing is hidden in the rest. ## The free tier, in full Sign in with Google and every property you have access to appears, with real numbers on each and no cap on how many. For each property: a 7, 28 and 90-day overview with deltas, the top 100 queries, pages, countries and devices, the striking-distance view of queries at positions 8 to 20, and change investigation showing the top three pages or queries behind any move. Client tags and colours, favourites and hidden properties, so the list is organised the way you work. Home Screen and Lock Screen widgets for every property. A watchlist of five queries. URL inspection, five a day. Sitemaps, read-only. A CSV export of whatever you are looking at, with a context header row. An offline cache, so the last data loaded is still there on a train. And Demo Mode, which runs the whole app, Pro screens included, on a sample dataset with no sign-in at all. That is not a teaser. For someone with one or two sites who wants yesterday's number on the Home Screen and a list of queries worth a push, it is the product. ## What Pro adds Pro is $4.99 a month or $14.99 a year. New subscribers can start the yearly plan with a first month for $0.99, and it renews at $14.99 a year after that. There is no weekly plan, no free trial and no lifetime option. For that: sixteen months of history with custom ranges and period comparison; change investigation showing twenty contributors and kept as history; push alerts, the anomaly, new-top-ten, watched-URL indexing and sitemap rules, each with its evidence snapshot; the Monday digest; an unlimited watchlist; more than one Google account in the same portfolio; unlimited URL inspection; sitemap submit and delete; Core Web Vitals and PageSpeed per page; the comparison CSV with previous-period columns; branded and white-label PDF reports; and the cannibalisation detector. Pro is priced per person. Three properties or thirty, the price is the same. ## Why properties are never capped Every other app in this category that we have looked at either charges by the number of sites or hides most of the data until you pay. We understand the logic: properties are the obvious thing to count. It is also the wrong thing to count, because it makes the free tier useless for exactly the person a Search Console app is most useful to, the freelancer or agency managing sites for other people. A free tier that shows three of your twenty properties is a demo, not a tier. So we charge for depth instead. History costs us storage. Alerts cost us a server that runs every six hours. Exports and the detector cost us engineering. The number of properties costs us nothing, and we are not going to charge you for something that costs us nothing. This is the one line we will not move. [The comparison pages](/vs/) show each competing app's own pricing from its own listing, so you can check the claim. ## Why there is no free trial There is a paid first month at $0.99 on the yearly plan instead, and it is deliberately not a trial. A free trial produces a lot of starts from people who forget to cancel, which is revenue nobody should want and reviews nobody should want more. A first month that costs a dollar produces fewer starts, from people who have decided they want the thing, and that is the relationship we would rather have. Because it renews at the full yearly price, we name that price in the same sentence as the $0.99, everywhere the offer appears, including here. Nobody should find out what the second charge is from their bank. ## Why there is no weekly plan Several apps in the category sell a weekly subscription, and their own reviews show how it is received: as the price you did not notice until it had charged you eight times. We had one in an earlier draft of the pricing and removed it. Two rungs are enough, and a ladder that reads as a trap is worse than no ladder. ## How billing actually works Payment is taken by Apple or Google through your store account; we never see your card. Subscriptions renew until you cancel, and you cancel from your phone's subscription settings, not from us. Cancelling stops the renewal and you keep Pro until the period you paid for runs out. The introductory month is offered once, to new subscribers, on the yearly plan, and cancelling during it means nothing further is charged. Refunds are the store's to give under the store's policy; we cannot issue them, but tell us if something went wrong and we will help you make the case. Prices may change for future periods. An existing subscription keeps its price until it renews, and the store notifies you of an increase and asks you to agree before it takes effect. ## What is not for sale at any price Rank tracking, because it breaks Google's terms. Your Search Console data, to anyone, for anything, because Google's Limited Use policy forbids it and so would we. And a per-property price, for the reasons above. [The support page](/support/) has the billing questions people ask most, and the answer to any you do not find there is an email away. --- ## Links - App Store: https://apps.apple.com/app/querywatch-search-console-app/id6811357323 - Google Play: https://play.google.com/store/apps/details?id=com.empath.querywatch - Website: https://querywatch.app - Contact: hello@querywatch.app - Made by: Nadril (https://nadril.com/) - Also by the same developer: MergeBell (https://mergebell.app/): GitLab merge request review, approvals and pipeline alerts on iPhone and Android QueryWatch is an independent app and is not affiliated with, endorsed by, or sponsored by Google LLC. Google Search Console is a trademark of Google LLC.