ScreenshotNeo

BlogHow-to

How to Track Competitor Rankings with Google Search Screenshots in India

Build a repeatable record of competitor search results in India with consistent queries, locations, languages, devices, screenshots, and careful notes.

By the ScreenshotNeo team4 October 202612 min read

A Google search screenshot records what appeared for one query under one set of conditions at one point in time. It can help you compare competitor visibility over time, but it is not a universal India ranking, a stable position report, or an explanation of why a page appeared. To make comparisons useful, keep the query, time window, location method, language, and device consistent, and record what you observed rather than inferring a cause.

This guide shows a repeatable manual workflow, how to preserve evidence, how to interpret changes, and when Search Console or a third-party tracker is a better fit. It also shows how to capture the pages with a browser and how to automate screenshots with ScreenshotNeo.

1. What a search screenshot can and cannot tell you

Google says search relevance can involve factors such as a searcher’s location, language, and device, and the visible result features vary with the query. A screenshot therefore documents a particular observed results page. It does not establish the one position a competitor holds for everyone in India. [Google explains how Search works](https://www.google.com/search/howsearchworks/how-search-works/).

A screenshot can show It cannot establish on its own
Which pages and domains appeared in the captured results, and their visible order A location-independent or permanent rank
Visible result features such as local, image, video, or other modules Why Google showed those results or whether a change was caused by an algorithm update
What a chosen search setup returned at a recorded date and time How often all users see the same page, or a competitor’s traffic and conversions

Use language such as “observed in this capture” and “appeared above” in your notes. Avoid labels such as “the India ranking” unless you explain the precise location, language, device, and capture method behind the observation.

2. Choose queries and define the comparison conditions

Build a fixed query set

Start with the exact searches that matter to your business: product categories, service-plus-city terms, brand comparisons, and questions where competitors appear. Preserve the exact spelling and language. Treat English, Hindi, and transliterated forms as separate queries; they are not interchangeable observations.

Keep a query sheet with one row per exact query. Include a stable identifier, the query text, language, the competitor domains or pages you want to observe, and any reason the query matters. Do not quietly rewrite a query between runs; create a new row when wording changes.

Record a condition profile for each run

Condition What to record Why it matters
Date and time Local date and time, plus timezone Results are an observation at a moment, not a timeless report.
Query Exact spelling, punctuation, and script Small wording or language changes can change the result page.
Location City or region intended and the method used to set it Google documents location as a relevance factor. A chosen setting or tool does not prove every searcher in that city sees the same page.
Language Query language and search interface language, where available Do not merge language variants into a single measurement.
Device Desktop or mobile; record viewport or device profile if automated Device can affect relevance and page layout.
Capture method Browser, screenshot API, or tracker; note settings that affect output Different capture paths may produce different pages or evidence.
Result features Visible local pack, images, videos, other modules, and ads if relevant Search pages are not always ten standard links; compare like with like.

For India, choose the cities, languages, and device classes that fit your audience. A search from one location is not proof of what appears throughout the country. Google’s international guidance recommends making country and language versions explicit for site owners, using approaches such as separate locale URLs and hreflang where appropriate. It also warns that locale-adaptive pages may not all be crawled, indexed, or ranked. These recommendations concern how sites expose their localized content; they do not certify that a manual setting or external tool reproduces every Indian user’s results. See [Google’s guidance on multi-regional and multilingual sites](https://developers.google.com/search/docs/specialty/international) and [locale-adaptive pages](https://developers.google.com/search/docs/crawling-indexing/locale-adaptive-pages).

3. Capture and log results manually

  1. Choose a query and its saved condition profile. Use the same location approach, language, and device class on each comparison run.
  2. Open Google Search and enter the exact query. Note any localization setting or other method used to set the intended location.
  3. Capture a full-page screenshot if available. If the page cannot be captured in one image, take sequential screenshots with enough overlap to preserve order. Make sure the query and the relevant results are identifiable.
  4. Save the original image with a filename that includes a date, query identifier, location, language, and device. For example: 2026-10-04_q07_mumbai_en_mobile.png.
  5. In a log, record the capture time and conditions, visible competitor URLs and their observed order, and notable result features. Keep the image itself; a written rank alone is harder to audit.
  6. Repeat on a schedule that fits the decision you are making. Weekly or monthly checks are workflow choices, not a cadence prescribed by Google. Keep the interval and conditions consistent.

Do not infer a cause from a difference between two captures. A changed order is an observed difference. It does not by itself show that a competitor made a change, that Google updated its systems, or that the change will persist.

4. Browser automation with Playwright

For a small set of repeatable captures, browser automation can save dated screenshots locally. This example uses Node.js and Playwright to open a Google results URL and capture the rendered page. It records the URL and run time alongside the image. Google may present consent, bot-check, or other interstitial pages; automation is not guaranteed to return ordinary results. Use this only in a way that complies with applicable terms and policies, and inspect the saved image before treating it as an observation.

npm install playwright
npx playwright install chromium
// capture.mjs
import { chromium } from 'playwright';
import { mkdir, writeFile } from 'node:fs/promises';

const query = process.argv[2];
if (!query) throw new Error('Usage: node capture.mjs "search query"');

const city = process.env.CITY ?? 'Mumbai';
const language = process.env.LANGUAGE ?? 'en';
const device = process.env.DEVICE ?? 'desktop';
const viewport = device === 'mobile'
  ? { width: 390, height: 844 }
  : { width: 1365, height: 900 };
const runAt = new Date();
const stamp = runAt.toISOString().replaceAll(':', '-').replaceAll('.', '-');
const slug = query.toLowerCase().replace(/[^a-z0-9]+/g, '-').replace(/^-|-$/g, '').slice(0, 50) || 'query';
const outDir = 'captures';
await mkdir(outDir, { recursive: true });

const browser = await chromium.launch({ headless: true });
try {
  const context = await browser.newContext({
    viewport,
    locale: language === 'hi' ? 'hi-IN' : 'en-IN',
    timezoneId: 'Asia/Kolkata',
    deviceScaleFactor: device === 'mobile' ? 2 : 1,
  });
  const page = await context.newPage();
  const url = new URL('https://www.google.com/search');
  url.searchParams.set('q', query);
  url.searchParams.set('hl', language);
  await page.goto(url.toString(), { waitUntil: 'domcontentloaded', timeout: 60000 });
  await page.screenshot({ path: `${outDir}/${stamp}_${slug}_${city}_${language}_${device}.png`, fullPage: true });
  const metadata = {
    capturedAt: runAt.toISOString(),
    query,
    city,
    language,
    device,
    viewport,
    timezone: 'Asia/Kolkata',
    requestedUrl: url.toString(),
    finalUrl: page.url(),
    title: await page.title(),
  };
  await writeFile(`${outDir}/${stamp}_${slug}_${city}_${language}_${device}.json`, JSON.stringify(metadata, null, 2));
  console.log(metadata);
} finally {
  await browser.close();
}

Run it with CITY=Mumbai LANGUAGE=en DEVICE=mobile node capture.mjs "best accounting software india". The city in this script is a label only: it does not geolocate the browser to Mumbai or guarantee Mumbai-specific results. The locale and timezone set browser preferences; they are not a substitute for a verified search location. For a location-sensitive comparison, document the actual location method and do not claim more precision than it provides. Save the original screenshot and metadata together.

Making the browser workflow more reliable

  • Use a consistent browser version, viewport, locale, and timezone for a series.
  • Inspect for consent screens, bot checks, network errors, or unusual page content. Mark these runs as unusable observations instead of recording a ranking.
  • Use a reasonable timeout and retain failures in the log. A failed capture is not evidence that a competitor disappeared.
  • Keep query strings exact and encode them through URLSearchParams, as in the example, instead of manually concatenating special characters.
  • Store screenshots with access controls suitable for your team. Search results can contain personalized or location-related context.

5. Compare observations without overclaiming

Compare captures only when their query and condition profiles match. A practical log can contain:

captured_at, query_id, query, location, location_method, language, device,
competitor_url, observed_order, result_features, screenshot_path, notes

Record both the URL and domain when possible: a competitor may have multiple pages for the same query. Note whether the result is an ordinary web listing or part of a visible feature. If a local result, image module, or video block shifts the layout, record that instead of treating every result as a position in a simple ten-link list.

When a competitor moves between captures, report the observation precisely: “The page appeared third in the October 4 Mumbai desktop capture and fifth in the October 11 capture.” Then investigate separately. A screenshot does not reveal indexing status, search demand, ranking factors, or the cause of a movement.

6. Screenshots, Search Console, and rank trackers

Method Useful for Limits
Manual or automated screenshots Keeping visual evidence of a particular results page under recorded conditions Each capture is one observation; conditions may not represent all searchers, and captures do not explain causes.
Google Search Console First-party information about your own verified site’s presence and performance in Google Search It is not a complete competitor feed and does not show a competitor’s private performance data.
Third-party rank trackers Repeating checks across query sets, locations, or devices when the tool supports the needed controls Outputs are tool observations or estimates. Google says third-party tools do not have access to its internal ranking data.

Google recommends its first-party Search Console for information and data directly from Google Search, while noting that third-party tools do not access Google’s internal ranking data. Use Search Console for your own site’s data, screenshots for auditable examples of visible pages, and external tracking tools when their repeatability and settings fit the job. Qualify competitor metrics as estimates or tool observations. See [Google’s guidance on third-party SEO tools](https://developers.google.com/search/docs/monitor-debug/third-party-tools).

When evaluating a rank tracker, check whether it exposes the location and language used, separates desktop and mobile, retains dated exports or screenshots, and makes its observation time visible. Verify current features and prices with the vendor; no vendor-specific terms are assumed here.

7. Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server for developers. One GET request returns an image or PDF. Its capture options include full-page screenshots, device and viewport settings, custom headers and cookies, wait conditions, and selector capture. See the ScreenshotNeo API documentation.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://www.google.com/search?q=competitor+query -o shot.webp

Python:

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={
        "access_key": "YOUR_API_KEY",
        "url": "https://www.google.com/search?q=competitor+query",
    },
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

Node.js:

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://www.google.com/search?q=competitor+query',
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await import('node:fs/promises').then(({ writeFile }) =>
  writeFile('shot.webp', Buffer.from(await res.arrayBuffer()))
);

Replace the example query with the exact query you are recording, and save the capture time, location method, language, and device separately. A screenshot API captures the requested page; it does not make a location label accurate or turn one observation into a universal ranking. Google may serve consent or bot-check pages, so inspect the output before logging a result.

ScreenshotNeo accepts cookie or consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each of those steps can be turned off. Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and responses report the page verdict and billing status in headers. Its MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 screenshots. Every feature is on every plan. Sign up for 1,000 free screenshots a month with no card.

8. Troubleshooting and edge cases

Symptom Likely cause What to do
Two captures of the same query differ Results can vary with time and search context; the location, language, or device may also differ. Compare metadata first. Mark the change as an observation and recapture under the saved profile if needed.
The screenshot shows a consent page, CAPTCHA, or bot check The search page presented an interstitial or blocked automated access. Do not log the page as ordinary search results. Mark the run unusable and use a permitted capture method.
The target city is in the filename but results look generic A city label, browser locale, or timezone does not itself establish the search location. Record the real location-setting method and its limits; do not describe the capture as city-specific without evidence.
Only part of the results page is visible The browser captured the viewport only, or a lazy-loaded section was not rendered. Use full-page capture or sequential screenshots, wait for the page to render, and inspect the image.
Comparison mixes Hindi and English queries Different language queries were treated as one measurement. Track each exact language and script as its own query series.
Observed positions shift because a result module appeared Local, image, video, or other features changed the layout. Log the feature and compare like-for-like pages; do not flatten every result into an assumed ten-link list.
Playwright times out or saves an error page Slow navigation, network trouble, or an interstitial prevented an ordinary result page. Keep a failure record, check the final URL and page title, use a suitable timeout, and retry later under the same conditions.
The competitor is absent from one capture The captured page may differ, the page may be below the captured area, or visibility may have changed for this observation. Check the full capture and conditions, then repeat. One absence does not prove deindexing or a lasting loss.

9. Performance, reliability, and cost

Manual capture is inexpensive in tooling but takes time as query, city, language, and device combinations grow. Browser automation reduces repeated clicking, while requiring a maintained browser environment and attention to failures and interstitials. Third-party trackers can reduce operational work for larger recurring sets, but their geographic controls, evidence retention, and pricing vary; verify current terms directly and treat their competitor metrics as observations or estimates.

For dependable comparisons, keep a run log, preserve the original capture, and separate successful result pages from failed or challenged requests. Schedule the work at a stable interval that matches your decision cycle; avoid interpreting noisy differences as trends until repeated observations support the pattern. Google Search Essentials also makes clear that meeting technical requirements and best practices does not guarantee crawling, indexing, or serving. See [Google Search Essentials](https://developers.google.com/search/docs/essentials).

10. Frequently asked questions

How do I check my competitor’s Google ranking in India?

Choose an exact query and a defined location, language, and device setup. Capture and date the results page, record the competitor URL and observed order, and repeat with the same conditions. Describe it as an observation for that setup, not a nationwide rank.

Can I track Google search results with screenshots?

Yes. Screenshots are useful evidence of what one captured results page displayed at a particular time. Keep metadata with each image and use repeated, like-for-like captures to compare changes.

Does Search Console show competitor rankings?

Search Console provides information about your own verified site’s performance and presence. It is not a complete source of competitor ranking data.

Should I track city and language variants separately?

Yes, when those variants matter to your audience. Keep each intended location and exact language query as a separately labeled series, and document how location was set.