Tackling 8,000 Title Tag Rewrites: A Case Study

  • Post author:
  • Post category:SEO

I recently dug into over 50,000 title tags to understand the impact of Googleโ€™s rewrite update. As an SEO, this naturally got me wondering how the update impacted Moz, specifically. So, this post will be a more focused examination of a site I have deep familiarity with, including three case studies where we managed to fix bad rewrites.

As an author, I take titles pretty personally. Imagine if you wrote this masterpiece:

โ€ฆ and then you ended up with a Google result that looked like this:

Sure, Google didnโ€™t do anything wrong here, and itโ€™s not their fault that thereโ€™s an upper limit on what they can display, but it still feels like something was lost. Itโ€™s one thing to do a study across a neutral data set, but itโ€™s quite another when youโ€™re trying to understand the impact on your own site, including articles you spent hours, days, or weeks writing.

Moz rewrites by the numbers

Iโ€™m not going to dig deep into the methodology, but I collected the full set of ranking keywords from Mozโ€™s Keyword Explorer (data is from late August) and scraped the relevant URLs to pull the current <title> tags. Here are a few of the numbers:

  • 74,810 ranking keywords

  • 10,370 unique URLs

  • 8,646 rewrites

Note that just under 2,000 of these โ€œrewritesโ€ were really pre-update (…) truncation. The majority of the rest were brand rewrites or removals, which Iโ€™ll cover a bit in the examples. The number of significant, impactful rewrites is hard to measure, but was much smaller.

Where did Google get it right?

While I have reservations about Google rewriting title tags (more on that at the end of this post), I tried to go into this analysis with an open mind. So, letโ€™s look at what Google got right, at least in the context of Moz.com.

(1) Removing double-ups

Our CMS automatically appends our brand (โ€œ – Mozโ€) to most of our pages, a situation thatโ€™s hardly unique to our site. In some cases, this leads to an odd doubling-up of the brand, and Google seems to be removing these fairly effectively. For example:

While the CMS is doing its job, โ€œMoz – Mozโ€ is repetitive, and I think Google got this one right. Note that this is not simple truncation โ€” the additional text would have easily fit.

(2) Those darned SEOs!

Okay, Iโ€™m not sure I want to admit this one, but occasionally we test title variations, and we still live with some of the legacy of rebranding from โ€œSEOmozโ€ to โ€œMozโ€ in 2013. So, some areas of our site have variations of โ€œ | SEO | Mozโ€. Hereโ€™s how Google handled one variety:

While itโ€™s a bit longer, I suspect this is a better extension for our Q&A pages, both for us and for our visitors from search. Iโ€™m going to call this a win for Google.

(3) Whatever this isโ€ฆ

I have no idea what the original intent of this <title> tag was (possibly an experiment):

While thereโ€™s nothing terribly wrong with the original <title> tag, itโ€™s probably trying too hard to front-load specific keywords and itโ€™s not very readable. In this case, Google opted to use the blog post title (from the <H1>), and itโ€™s probably a good choice.

Where did Google get it so-so?

It may seem strange to cover examples where Google did an okay job, but in some ways these bother me the most, if simply because they seem unnecessary. I feel like the bar for a rewrite should be higher, and that makes the gray areas worth studying.

(4) Shuffling the brand

For some of our more evergreen pieces, we put the Moz brand front-and-center. In a number of cases, Google shuffled that to the back of the title. Hereโ€™s just one example:

Thereโ€™s nothing inherently wrong with this rewrite, but why do it? We made a conscious choice here and โ€” while the rewrite might be more consistent with our other content โ€” Iโ€™m not sure this is Googleโ€™s decision to make.

(5) Double-brand trouble

This is a variation on #4, conceptually. Some of our Whiteboard Friday video titles end in โ€œ- Whiteboard Friday – Mozโ€, and in this example Google has split that and relocated half of it to the front of the display title:

Whiteboard Friday is a brand in and of itself, but I have a feeling that #4 and #5 are really more about delimiters in the title than the brand text. Again, why did this trigger a rewrite?

You might be thinking something along the lines of โ€œGoogle has all the data, and maybe they know more than we do.โ€ Put that thought on hold until the end of the post.

(6) The old switcheroo

Hereโ€™s an example where Google opted for the post title (in the <H1>) instead of the <title> tag, with the end result being that they swapped โ€œremoveโ€ for โ€œdeleteโ€:

This isnโ€™t really a single-word substitution (so much as a total swap), and I donโ€™t know why we ended up with two different words here, but what about the original title โ€” which is extremely similar to the post title โ€” triggered the need for a rewrite?

One quick side note โ€” remember that Featured Snippets are organic results, too, and so rewrites will also impact your Featured Snippets. Hereโ€™s that same post/rewrite for another query, appearing as a Featured Snippet:

Again, thereโ€™s nothing really wrong or inaccurate about the rewrite, other than a lack of clarity about why it happened. In the context of a Featured Snippet, though, rewrites have a greater possibility of impacting the intent of the original author(s).

Where did Google get it wrong?

Itโ€™s the moment youโ€™ve been waiting for โ€” the examples where Google made a mess of things. I want to be clear that these, at least in our data set, are few and far between. Itโ€™s easy to cherry-pick the worst of the worst, but the three examples Iโ€™ve chosen here have a common theme, and I think they represent a broader problem.

(7) Last things first

Hereโ€™s an example of rewrite truncation, where Google seems to have selected the parenthetical over the main portion of the title:

Many of the bad examples (or good examples of badness) seem to be where Google split a title based on delimiters and then reconstructed what was left in a way that makes no sense. It seems especially odd in the case of a parenthetical statement, which is supposed to be an aside and less important than what precedes it.

(8) Half the conversation

In other cases, Google uses delimiters as a cutting-off point, displaying whatโ€™s before or after them. Hereโ€™s a case where the โ€œafterโ€ approach didnโ€™t work so well:

This is user-generated content and, granted, itโ€™s a long title, but the resulting cutoff makes no sense out of context. Standard (…) truncation wouldโ€™ve been a better route here.

(9) And another thing…

Hereโ€™s a similar example, but where the cutoff happened at a hyphen (-). The title style is a bit unusual (especially starting the sub-title with โ€œAndโ€), but the cutoff turns it from unusual to outright ridiculous:

Again, simple truncation wouldโ€™ve been a better bet here.

I get what Googleโ€™s trying to do โ€” theyโ€™re trying to use delimiters (including pipes, hyphens, colons, parentheses, and brackets) to find natural-language breaks, and split titles at those breaks. Unfortunately, the examples demonstrate how precarious this approach can be. Even the classic โ€œTitle: Sub-titleโ€ format is often reversed by writers, with the (arguably) less-important portion sometimes being used first.

Three case studies (& three wins)

Ultimately, some rewrites will be good-to-okay and most of these rewrites arenโ€™t worth the time and effort to fix. Over half of the Moz <title> rewrites were minor brand modifications or brand removal (with the latter usually being due to length limits).

What about the objectively bad rewrites, though? I decided to pick three case studies and see if I could get Google to take my suggestions. The process was relatively simple:

  1. Update the <title> tag, trying to keep it under the length limit

  2. Submit the page for reindexing in Google Search Console

  3. If the rewrite didnโ€™t take, update the <H1> or relevant on-page text

Here are the results of the three case studies (with before and after screenshots):

(1) A shady character

This one was really our fault and was an easy choice to fix. Long story short, a data migration led to a special character being corrupted, which resulted in this:

Iโ€™m not blaming Google for this one, but the end result was a strange form of truncation that made โ€œGoogle Wonโ€™tโ€ look like โ€œGoogle Wonโ€, and made it appear that this was the end of the title. I fixed and shortened the <title> tag, and hereโ€™s what happened:

Interestingly, Google opted to use the <H1> here instead of the shortened <title> version, but since it fixed the main issue, Iโ€™m going to call this a win and move on.

(2) Change isnโ€™t easy

Hereโ€™s another one where Google got it wrong, breaking the <title> tag at a parenthetical that didnโ€™t really make any sense (similarly to the examples above):

Since this was a recent and still-relevant post, we were eager to fix it. Interestingly, the first fix didnโ€™t take. I had to resort to changing the post title (<H1>) as well, and removed the parentheses from that title. After that, Google opted for the <title> tag:

This process may require some trial-and-error and patience, especially since the GSC reindexing timeline can vary quite a bit. Most of these updates took about a day to kick in, but Iโ€™ve recently heard anywhere from an hour to never.

(3) Donโ€™t ditch Moz!

Our final case study is a complex, multi-delimiter title where Google decided to split the title based on a phrase in quotation marks and then truncate it (without the โ€œ…โ€):

Although the main portion of the rewrite is okay, unfortunately the cutoff makes it look like the author is telling readers to ditch Moz. (Marketing wasnโ€™t thrilled about that). I opted to simplify the <title> tag, removing the quote and the parentheses. Hereโ€™s the end result:

I managed to sneak in all of the relevant portion of the title by switching โ€œAndโ€ out with an ampersand (&), and now itโ€™s clear what we should be ditching. Cue the sigh of relief.

While thereโ€™s potentially a lot more to be done, there are two takeaways here:

  1. You need to prioritize โ€” donโ€™t sweat the small rewrites, especially when Google might change/adjust them at any time.

  2. The bad rewrites can be fixed with a little time and patience, if you understand why Google is doing what theyโ€™re doing.

I donโ€™t think this update is cause for panic, but itโ€™s definitely worth getting a sense of your own rewrites โ€” and especially patterns of rewrites โ€” to make sure they reflect the intent of your content. What I found, even across 8,000 rewrites, is that there were only a handful of patterns with maybe a few dozen examples that didnโ€™t fit any one pattern. Separating the signal from the noise takes work, but itโ€™s definitely achievable.

Are rewrites good or bad?

This is an incredibly subjective question. I purposely structured this post into right/so-so/wrong to keep myself from cherry-picking bad examples, and my observations are that most rewrites (even on a site that I take pretty personally) are minor and harmless. That said, I have some misgivings. If youโ€™re happy with the analysis and donโ€™t need the editorializing, youโ€™re welcome to go make a sandwich or take a nap.

Itโ€™s important to note that this is a dynamic situation. Some of the rewrites my research flagged had changed when I went back to check them by hand, including quite a few that had reverted to simple truncation. It appears that Google is adjusting to feedback.

This research and post left me the most uncomfortable with the โ€œso-soโ€ examples. Many of the bad examples can be fixed with better algorithms, but ultimately I believe that the bar for rewriting titles should be relatively high. Thereโ€™s nothing wrong with most of the original <title> tags in the so-so examples, and it appears Google has set the rewrite threshold pretty low.

You might argue that Google has all of the data (and that I donโ€™t), so maybe they know what theyโ€™re doing. Maybe so, but I have two problems with this argument.

First, as a data scientist, I worry about the scale of Googleโ€™s data. Letโ€™s assume that Google A/B tests rewrites against some kind of engagement metric or metrics. At Google scale (i.e. massive data), itโ€™s possible to reach statistical significance with very small differences. The problem is that statistics donโ€™t tell us anything about whether that change is meaningful enough to offset the consequences of making it. Is a 1% lift in some engagement metric worth it when a rewrite might alter the authorโ€™s original intent or even pose branding or legal problems for companies in limited cases?

If youโ€™re comparing two machine learning models to each other, then it makes sense to go with the one that performs better on average, even if the difference is small. Presumably, in that case, both models have access to the same data. With title rewrites, though, weโ€™re comparing the performance of a model to millions of conscious, human decisions that may have a great deal of context Google has no access to. The risk of rewriting is reasonably high, IMO, and that means that small differences in performance may not be enough.

Second โ€” and this is a more philosophical point โ€” if Google has found that certain patterns or title styles result in better performance, then why not be transparent and publish that data? I understand why Google wants to veil the algorithm in secrecy, but theyโ€™ve already told us that title rewrites donโ€™t impact rankings. If the goal is to create better titles across the web, then empower writers and content creators to do that. Donโ€™t make those decisions for us.

Ultimately, I think Google moved too far, too fast with this update. I believe they could have communicated (and still could communicate) the reasons more openly without risk to any major secrets and be more conservative about when and if to make changes, at least until these systems have been improved.