There’s no built-in Google Search Console report that flags title rewrites directly, so the methodology has to be built manually: crawl the site to capture every declared <title> tag, compare that declared title against what Google is actually displaying in search results at scale (via the URL Inspection tool, manual SERP sampling, or third-party rank-tracking tools that capture live SERP titles), flag the mismatches, and then cross-reference Search Console Performance data (impressions, clicks, CTR) for those specific URLs to estimate what the rewrite is doing to traffic. This is a crawl-versus-SERP comparison exercise stitched together from several tools, not a single report you pull.
Step 1: capture the declared title at scale
Run a full site crawl (Screaming Frog, Sitebulb, or an equivalent crawler capable of handling the site’s URL count) and export the <title> element for every indexable URL. This is your baseline, “what we’re asking Google to display.” For a large site this export can run into the tens or hundreds of thousands of rows, so this step is really about generating a clean, complete dataset to compare against, not about reading titles one at a time.
Step 2: capture what Google is actually displaying
This is the part with no single authoritative source, so it has to be triangulated:
URL Inspection tool (in Search Console, or via the Search Console API for bulk checks) shows how a specific URL is currently indexed, though checking this one URL at a time doesn’t scale to a large site without API access and scripting.
Manual SERP sampling for a representative set of URLs and their target queries, checking what title actually displays for each, is a reasonable way to spot-check patterns without instrumenting the whole site.
Third-party rank-tracking tools that log SERP titles as part of their regular tracking runs are the most practical way to do this at scale for a large site, since many of them already store the displayed title alongside the ranking position and can be exported in bulk. If the site already has keyword tracking set up across a large URL set, this is usually the fastest path to a bulk “displayed title” dataset without building custom scraping.
Whichever combination you use, the goal is a dataset of “declared title” and “displayed title” pairs at the URL level, covering as much of the site as is practical to check.
Step 3: flag the mismatches and classify the rewrite pattern
Join the two datasets on URL and flag every row where the displayed title differs meaningfully from the declared title (minor differences like appended brand names or truncation for length aren’t the same signal as a substantively rewritten title). Once you have the flagged set, it’s worth classifying what kind of rewrite is happening, since the fix differs depending on the pattern:
Titles being truncated because they exceed practical display length.
Titles being rewritten because the declared title doesn’t closely match the page’s actual on-page H1 or primary content focus (Google has explained that title rewrites often happen when the declared title doesn’t accurately or clearly represent page content, is stuffed with keywords, is boilerplate repeated site-wide, or otherwise appears not to serve the user well in context).
Titles being rewritten to better match the specific query the result is being served for (Google can select different title-like text depending on the query, sometimes pulling from on-page headings or anchor text pointing to the page).
This classification step matters because “my titles are being rewritten” isn’t a uniform problem with one fix. A site with a majority of boilerplate, templated titles will show a very different rewrite pattern (and a different fix) than a site with genuinely well-written, unique titles being rewritten per-query.
Step 4: quantify the traffic impact
Once you have the flagged URL list, pull Search Console Performance data (filtered to those specific URLs) for CTR, clicks, and impressions. There are two practical ways to estimate impact:
Before/after comparison, if you have a known date when a title was changed (either your own edit or a point where you first noticed the rewrite via historical crawl/tracking data), compare CTR and click trends for that URL immediately before and after.
Cohort comparison, comparing CTR for the set of URLs with rewritten titles against a comparable set of URLs on the site whose titles are not being rewritten, controlling as best as possible for ranking position and query type, since CTR is heavily influenced by position regardless of title quality.
Neither method produces a definitive causal number, since organic CTR is noisy and influenced by many factors beyond the title itself (ranking fluctuation, SERP feature presence, seasonality). What this gives you instead is a defensible, directional estimate: whether the rewritten-title URLs are underperforming their expected CTR for their ranking position relative to the site’s own baseline, which is enough to prioritize which pages are worth rewriting the source title for and to make the case that title rewrites are a real, measurable traffic issue rather than a cosmetic one.
What this methodology deliberately doesn’t claim
It’s worth being explicit that this process is an approximation built from several imperfect data sources, not a report Google provides. There is no Search Console view labeled “titles Google has rewritten,” and no tool guarantees complete coverage of every URL’s currently displayed title at every point in time, since SERP titles can vary by query and can change over time without a corresponding site change. The value of the methodology is in surfacing the pattern and its rough scale reliably enough to act on, not in producing an exact, guaranteed-accurate count.
A worked example of the classification step
Say the crawl-versus-SERP comparison on a large ecommerce site flags eleven thousand product URLs where the displayed title differs from the declared title. Treating this as one undifferentiated problem would be a mistake, so the next step is sampling a few hundred of these across different product categories and actually looking at the pairs side by side. One recognizable pattern that often emerges: the declared titles were generated from a template that appends the same boilerplate suffix to every product (“Buy [Product Name] Online | Free Shipping | BrandName”), and Google is consistently dropping the repeated boilerplate and instead pulling a title-like string closer to the product’s actual H1 or a more specific on-page descriptor. This is a template problem affecting the whole category, not eleven thousand individual issues, and the fix is changing the title template’s logic, not editing pages one at a time. A second pattern might show up on a smaller subset, a few hundred URLs where the rewritten title actually varies by the query being served, sometimes showing the product name alone, sometimes showing a category-plus-product combination, depending on what was searched. That pattern indicates Google is dynamically selecting among reasonable options rather than rejecting the declared title outright, which is a lower-priority fix, if it’s a fix at all, since the underlying title still gets used, just supplemented differently depending on context.
Handling the scale problem on very large sites
On sites with hundreds of thousands or millions of indexed URLs, checking “what Google displays” for every single one isn’t practical even with API access, since URL Inspection API quotas are limited and third-party tracking tools are typically only configured for a tracked keyword set, not full site coverage. The realistic approach is stratified sampling rather than full coverage: group URLs by template or page type (product pages, category pages, blog posts, and so on), pull a statistically reasonable sample from each group (large enough to be representative, not so large it’s unmanageable to review), and treat the rewrite rate and pattern found in each sample as representative of that template’s behavior sitewide. This makes the exercise tractable on a site of any size, at the cost of precision on any individual URL outside the sample, which is an acceptable tradeoff given that the goal is prioritizing which templates need title work, not auditing every single page.
A caution on over-attributing CTR changes to title rewrites alone
One mistake worth flagging explicitly: once a set of rewritten-title URLs is identified and a CTR dip is observed on them, it’s tempting to conclude the rewrite caused the dip. That conclusion needs the same skepticism applied earlier to URL-keyword correlation. Ranking position changes, seasonal demand shifts, and SERP feature changes (a new featured snippet, a shopping carousel, an AI-generated overview appearing above the result) can all suppress CTR independently of the title, and any of these can coincide with a period where a title happens to also be rewritten. The cohort comparison against non-rewritten URLs on the same site helps control for this, but it doesn’t eliminate it entirely, particularly if the rewritten set and the non-rewritten set skew toward different query types or ranking positions. Treat the resulting number as a reasonable basis for prioritization, not as a precise causal estimate to report upward without caveats.
