I recently went into over 50,000 title tags to understand the impact of Google’s reword upgrade. As an SEO, this naturally got me questioning how the update affected Moz, particularly. So, this post will be a more focused examination of a website I have deep familiarity with, consisting of three case research studies where we managed to repair bad rewrites.
As an author, I take titles quite personally. Think of if you composed this masterpiece:
… and then you wound up with a Google result that appeared like this
: Sure, Google didn’t do anything incorrect here, and it’s not their fault that there’s an upper limit on what they can show, but it still feels like something was lost. It’s one thing to do a research study throughout a neutral information set, however it’s rather another when you’re trying to understand the effect on your own site, including posts you invested hours, days, or weeks writing.
Moz rewords by the numbers
I’m not going to dig deep into the method, but I collected the complete set of ranking keywords from Moz’s Keyword Explorer (data is from late August) and scraped the appropriate URLs to pull the current < tags. Here are a few of the numbers:
-
74,810 ranking keywords
-
10,370 distinct URLs
-
8,646 rewrites
Note that just under 2,000 of these “rewrites” were really pre-update (…) truncation. Most of the rest were brand rewrites or removals, which I’ll cover a bit in the examples. The number of substantial, impactful rewrites is difficult 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 solved, a minimum of in the context of Moz.com.
( 1) Getting rid of double-ups
Our CMS automatically adds our brand (” – Moz”) to the majority of our pages, a scenario that’s barely unique to our website. Sometimes, this leads to an odd doubling-up of the brand name, and Google appears to be getting rid of these fairly successfully. 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 basic truncation– the extra text would have quickly healthy.
( 2) Those darned SEOs!
Okay, I’m uncertain I wish to admit this one, however periodically we evaluate title variations, and we still cope with a few of the legacy of rebranding from “SEOmoz” to “Moz” in 2013. So, some locations of our site have variations of”|SEO|Moz”. Here’s how Google handled one range:
While it’s a bit longer, I presume this is a much 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 < tag was (perhaps an experiment):
While there’s absolutely nothing awfully wrong with <the initial tag, it's probably trying too difficult to front-load particular keywords and it's not very legible. In this case, Google chose to utilize the blog post title (from the <), and it's probably a good choice.
Where did Google get it so-so?
It might seem strange to cover examples where Google did an okay job, however in some methods these trouble me the most, if merely due to the fact that they appear unnecessary. I feel like the bar for a reword need to be greater, and that makes the gray areas worth studying.
( 4) Mixing the brand name
For some of our more evergreen pieces, we put the Moz brand name front-and-center. In a variety of cases, Google mixed that to the back of the title. Here’s simply one example:
There’s nothing inherently incorrect with this reword, however why do it? We made a mindful option here and– while the reword might be more consistent with our other content– I’m not sure this is Google’s choice to make.
( 5) Double-brand difficulty
This is a variation on # 4, conceptually. A few of our White boards Friday video titles end in “- Whiteboard Friday – Moz”, and in this example Google has split that and transferred half of it to the front of the display title:
Whiteboard Friday is a brand name in and of itself, however I sense that # 4 and # 5 are truly more about delimiters in the title than the brand text. Again, why did this trigger a reword?
You might be believing something along the lines of “Google has all the data, and maybe they understand more than we do.” Put that thought on hold up until the end of the post.
( 6) The old switcheroo
Here’s an example where Google went with the post title (in the <) instead of the < tag, with completion outcome being that they swapped "get rid of" for "delete":
This isn’t really a single-word substitution( so much as an overall swap), and I don’t know why we wound up with two different words here, but what about the initial title– which is incredibly comparable to the post title– activated the requirement for a rewrite?
One fast side note– bear in mind that Featured Bits are natural outcomes, too, therefore rewrites will likewise affect your Featured Bits. Here’s that very same post/rewrite for another question, looking like an Included Bit:
Once again, there’s nothing really incorrect or inaccurate about the reword, besides an absence of clearness about why it took place. In the context of a Featured Bit, though, rewrites have a higher possibility of affecting the intent of the initial author(s).
Where did Google get it wrong?
It’s the minute you’ve been waiting on– the examples where Google made a mess of things. I wish to be clear that these, a minimum of in our information set, are scarce. It’s simple to cherry-pick the worst of the worst, but the 3 examples I’ve selected here have a common theme, and I think they represent a broader issue.
( 7) Last things first
Here’s an example of reword truncation, where Google appears to have actually chosen the parenthetical over the primary part of the title:
Many of the bad examples (or good examples of badness) appear to be where Google split a title based on delimiters and then rebuilded what was left in a manner that makes no sense. It appears especially odd in the case of a parenthetical declaration, which is expected to be an aside and lesser than what precedes it.
( 8) Half the discussion
In other cases, Google utilizes delimiters as a cutting-off point, displaying what’s prior to or after them. Here’s a case where the “after” technique didn’t work so well:
This is user-generated material and, granted, it’s a long title, but the resulting cutoff makes no sense out of context. Requirement (…) truncation would’ve been a much better route here.
( 9) And another thing …
Here’s a similar example, but where the cutoff occurred at a hyphen (-). The title design is a bit unusual (especially starting the sub-title with “And”), but the cutoff turns it from unusual to straight-out ridiculous:
Once again, simple truncation would’ve been a much better bet here. I get what Google’s attempting to do– they’re attempting to use delimiters (consisting of pipelines, hyphens, colons, parentheses, and brackets) to find natural-language breaks, and split titles at those breaks. Sadly, the examples show how precarious this technique can be. Even the traditional “Title: Sub-title” format is typically reversed by writers, with the (probably) less-important portion often being utilized initially.
Three case research studies (& & three wins)
Ultimately, some rewrites will be good-to-okay and the majority of these rewrites aren’t worth the time and effort to repair. Over half of the Moz < rewrites were small brand name modifications or brand name elimination (with the latter normally being due to length limitations).
What about the objectively bad rewrites, though? I decided to choose three case research studies and see if I could get Google to take my recommendations. The procedure was fairly basic:
-
Update the < tag, trying to keep it under the length limit
-
Send the page for reindexing in Google Search Console
-
If the reword didn’t take, update the < or relevant on-page text
Here are the results of the 3 case research studies (with before and after screenshots):
( 1) A dubious character
This one was really our fault and was a simple choice to repair. Long story short, a data migration led to a special character being damaged, which resulted in this:
I’m not blaming Google for this one, but the end result was a strange type of truncation that made” Google Won’t “appear like “Google Won”, and made it appear that this was completion of the title. I repaired and reduced the tag, and here’s what took place:
Surprisingly <, Google decided to use the here rather of <the reduced variation, but given that it repaired the primary issue, I'm going to call this a win and carry on.
( 2) Change isn’t simple
Here’s another one where Google got it incorrect, breaking the < tag at a parenthetical that didn't really make any sense (similarly to the examples above):
Considering that this was a recent and still-relevant post, we were eager to repair it. Remarkably, the very first fix didn’t take. I had to resort to altering the post title () as well, and removed the parentheses from that title. After that, Google chose the <
tag: This procedure may need some trial-and-error and patience, specifically since the GSC reindexing timeline can vary a fair bit. Most of these updates took about a day to start, but I’ve just recently heard anywhere from an hour to never.
( 3) Don’t ditch Moz!
Our final case research study is a complex, multi-delimiter title where Google chose to divide the title based on an expression in quote marks and then truncate it (without the “…”):
Although the main part of the rewrite is okay, sadly the cutoff makes it appear like the author is telling readers to ditch Moz. (Marketing wasn’t thrilled about that). I opted to streamline the < tag, getting rid of the quote and the parentheses. Here's completion outcome:
I managed to sneak in all of the pertinent part of the title by switching “And” out with an ampersand (&&), and now it’s clear what we ought to be ditching. Cue the sigh of relief.
While there’s potentially a lot more to be done, there are 2 takeaways here:
-
You require to prioritize– don’t sweat the small rewrites, specifically when Google may change/adjust them at any time.
-
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 upgrade is cause for panic, however it’s definitely worth getting a sense of your own rewrites– and specifically patterns of rewrites– to make certain they reflect the intent of your material. What I found, even across 8,000 rewrites, is that there were only a handful of patterns with possibly a couple of lots examples that didn’t fit any one pattern. Separating the signal from the noise takes work, but it’s absolutely achievable.
Are rewords excellent or bad?
This is an exceptionally subjective concern. I intentionally structured this post into right/so-so/wrong to keep myself from cherry-picking bad examples, and my observations are that many rewrites (even on a site that I take pretty personally) are small and harmless. That stated, I have some misgivings. If you enjoy with the analysis and don’t require the editorializing, you’re welcome to go make a sandwich or sleep.
It is necessary to note that this is a vibrant circumstance. Some of the rewrites my research flagged had actually changed when I went back to inspect them by hand, including numerous that had gone back to simple truncation. It appears that Google is getting used to feedback.
This research and post left me the most unpleasant with the “so-so” examples. A lot of the bad examples can be repaired with much better algorithms, however eventually I believe that the bar for rewording titles must be reasonably high. There’s absolutely nothing incorrect with the majority of the original < tags in the so-so examples, and it appears Google has set the rewrite threshold quite low.
You may argue that Google has all of the data (and that I do not), so perhaps they know what they’re doing. Maybe so, but I have 2 problems with this argument.
First, as an information researcher, I worry about the scale of Google’s data. Let’s presume that Google A/B tests rewrites versus some sort of engagement metric or metrics. At Google scale (i.e. enormous information), it’s possible to reach statistical significance with really little differences. The problem is that statistics don’t tell us anything about whether that modification 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 and even position branding or legal problems for business in minimal cases?
If you’re comparing two artificial intelligence models to each other, then it makes good sense to go with the one that performs better usually, even if the distinction is little. Most likely, in that case, both designs have access to the exact same information. With title rewrites, though, we’re comparing the efficiency of a model to countless mindful, human choices that may have a lot of context Google has no access to. The risk of rewriting is reasonably high, IMO, and that means that small differences in performance might not be enough.
2nd– and this is a more philosophical point– if Google has found that certain patterns or title styles lead to much better efficiency, then why not be transparent and publish that information? I understand why Google wants to veil the algorithm in secrecy, but they’ve currently informed us that title rewrites do not impact rankings. If the goal is to create better titles across the web, then empower authors and content creators to do that. Do not make those choices for us.
Ultimately, I believe Google moved too far, too quick with this update. I think they could have communicated (and still could communicate) the reasons more honestly without danger to any major secrets and be more conservative about when and if to make changes, at least until these systems have been improved.