At the end of October we ran a title maintenance batch on our own English pages, pulling five older articles and rewriting each one. The review turned up four patterns. Some titles carried a specific date, so two weeks later they read like old news while the page sat at position six with zero clicks. Some ran past 100 characters, got truncated, and never put the core query in the first 30 characters. Some were noun piles that gave readers no reason to click. And one was the most frustrating of all, the metaTitle had been changed in code while the live <title> stayed old, which the team read as "the copy did not work" when the real problem was that nothing had been deployed.

Those four patterns map to the division of labor between three elements and one verification rule. The parent guide on page titles, structure, and internal links explains how a title system catches search intent. This article does not repeat that argument. It covers the specific rules for each element, how to rewrite, and how to verify that a change actually went live.

What Each Element Does

Title, meta description, and H1 are often treated as three slots for the same sentence. They do different jobs.

ElementQuestion it answersWhere it appearsCommon misuse
TitleWhat is this result, and why click itSearch title link, browser tabKeyword stuffing, hard dates, running past one line
Meta descriptionWhat extra value comes after the clickSearch snippet, possibly rewrittenRestating the title, one version sitewide
H1What is the main heading inside this pageTop of the page bodyLogo as H1, several H1s on one page

The title handles query match and click promise. Google's title documentation is direct. Title links should be unique, descriptive, and concise, without keyword stuffing or half-empty phrases. Google chooses from multiple sources on the page and may rewrite a title when it detects something obsolete or inaccurate. You can influence it, not dictate it.

The meta description adds value instead of repeating the title. Google's snippet documentation says Google primarily generates snippets from page content and uses the meta description only when it describes the page better than the content does. There is no length limit on the tag itself, but the snippet is truncated to fit the device width. Both points mean the description is written for people, not for a fixed character count.

The H1 is the single main heading inside the page. It is not the title, and it does not need to match word for word. Google's title documentation notes that when a page has several equally prominent headings, Google may use the first one as the title link source. A messy H1 does not hurt rankings first. It makes both machines and readers guess which heading is the main one.

Length Is Approximate

The widely repeated rules of 60 characters for a title and 160 for a description are rules of thumb, not limits. Search results truncate by pixel width and device, and Chinese and English carry different information density. The same character count occupies very different widths in the two languages.

A more practical approach is to remember three ranges and check an actual SERP preview.

ElementEnglish rangeChinese rangePurpose
TitleAbout 50 to 60 charactersAbout 25 to 30 charactersReduce truncation, keep the core query early
Meta descriptionAbout 140 to 160 charactersAbout 70 to 90 charactersLeave room for added value, no filler
H1No hard limitNo hard limitExplain the page, can be longer than the title

These numbers are reminders that truncation may happen, not budgets to hit. Two rules matter more. Put the core query within the first 30 English characters or the first 15 Chinese characters. Do not pad the title with adjectives.

One more point is easy to forget. Google rewrites titles and descriptions. The title you write may not be the one users see, so do not judge a change from a single day's SERP screenshot. Look at page-level CTR against the baseline. The parent guide already makes this argument. Here it becomes an operating rule.

Four Bad Title Patterns

The four patterns from our October batch each have a clear test and a clear fix.

| Pattern | Symptom | Test | Fix |
|---|---|---|---|
| Dead date | A specific date such as October 12 in the title | The date has passed, the content is still useful, but it reads as old news | Remove the date, keep the specific action, such as What to Check |
| Too long | English title over 100 characters, core term missing from the first 30 | The truncated result no longer makes sense | Cut to 65 characters, front-load the core query, keep the brand suffix |
| No promise | A noun pile such as Google Ads Automated Promotions | A reader cannot tell what the click delivers | Add a decision or action, such as What to Check |
| Not live | Code changed, live title unchanged | Live <title> differs from the repository | Check deployment and cache before rewriting again |

Dead dates are easy to miss because the date feels new on publish day. News, policy, and event pieces love putting dates in titles. It works at launch and turns into a staleness signal two weeks later. The fix is not replacing the date with "latest," which also expires. It is anchoring the title to an action that does not age, such as what to check or which terms changed.

Overlong titles are more common in English. Chinese packs more meaning into 30 characters, while a literal English translation often needs 90. Start with the core query, place it first, then cut modifiers. Keep the brand suffix consistent, but do not squeeze it out just to fit keywords.

The no-promise pattern is the most abstract. A simple test is to show the title to someone outside the business and ask what they would get from clicking. If they cannot answer, the promise is missing. Add a concrete outcome, not words like guide or explained, but what the page helps them diagnose, compare, or change.

The not-live pattern is a process problem, not a copy problem. Our own lesson was that the frontmatter changed in a commit and the build passed, but the live <title> stayed old. The cause could be a repository change that was never deployed, a deployment with a CDN still serving cached HTML, or a CMS field that the page does not actually read. Check in this order, live HTML, then dist, then repository, then CMS and cache. Reverse the order and a day disappears into rewriting copy that was never the issue.

Meta Descriptions Add Information

A usable description answers at least one question the title does not. Four patterns work.

PatternAnswersExample direction
OutcomeWhat the click deliversA checklist, a comparison table, a decision order
AudienceWho it fits and at what stageNew media buyers, teams entering a new market
DifferenceHow it differs from common practiceNot more budget, but separating four problem types
BoundaryWhat it does not do, where the limits areNo recovery timeline promises, not legal advice

Pick one or two. Do not stack all four. A description is not a keyword list. Repeating title terms adds nothing and wastes the space reserved for added value.

A counterexample is "Learn about Google Ads automated promotions and how they work." It carries no information and no promise, and the reader still does not know what the page delivers. A better version says that automated promotions default on for Search and PMax campaigns with location assets, pulling coupons and deals into ads, and that the page covers scope, opt-out, and watchpoints. That gives three concrete facts.

Descriptions also need to be unique per page. Google explicitly says identical or similar descriptions across a site are not helpful. Template output such as "professional team with years of experience" gives up the slot.

H1, One Main Heading per Page

The three common H1 problems are using a logo as the H1, having several H1s on one page, and writing an H1 that does not match the body.

Use one H1 per page, near the top of the body, stating what the page covers. Use H2 and H3 for sections. Do not turn every section heading into an H1 for styling convenience. The H1 can differ from the title. The title serves the click from search, while the H1 orients the reader who already arrived, so it can be more complete and specific.

The H1 should not be a keyword pile. Stuffing the main term, region, year, and selling points into one heading makes it unreadable and muddles the page structure. A practical test is whether a reader scanning the H1 can confirm they are on the right page.

For multilingual sites, rewrite the H1 in the target language instead of translating it from Chinese. Site-level language handling and hreflang belong to the international and local SEO guide. This section only flags language consistency between title and H1.

Chinese and English Write Differently

A Chinese title can fit topic, scope, and promise into 30 characters. A literal English translation often becomes a long, flat sentence. A few comparisons.

Literal translation (avoid)Rewrite (prefer)
Keyword Research Full Process, Seed Words, Expansion and CleaningKeyword Research Workflow - Seeds, Expansion, and Cleanup
Google Ads Ad Disapproval and Restricted Industry ComplianceGoogle Ads Disapprovals and Restricted Verticals - What to Fix
Overseas Social Media Compliance, Copyright, Ad Disclosure, Privacy and Regional LimitsGlobal Social Media Compliance - Copyright, Disclosure, and Privacy

Three rewrite principles. Use verbs or concrete actions in English, not empty words such as full process or comprehensive. Put the core query first and the brand suffix last. Do not translate word for word to mirror Chinese structure. English readers do not care about the symmetry of the Chinese title.

Judge years and dates separately. A year helps annual reviews and policy effective dates. In evergreen tutorials it mostly accelerates aging. Dates are stricter. Unless a policy piece has a real effective date, keep them out of the title.

Rewrite Process, One Element at a Time

The most common mistake is changing title, description, and H1 together, then having no idea which change did anything. A steadier process changes one element at a time and writes the criteria down first.

StepActionOutput
1 BaselinePull the last 28 days of impressions, clicks, CTR, and average position, split by query and deviceA baseline table
2 DiagnoseCheck the actual SERP preview and classify the problemProblem type and target title
3 RewriteChange only the title, or only the description, or only the H1One new version
4 PredefineWrite the observation window, comparison basis, success and rollback conditionsA criteria table
5 PublishBuild, deploy, purge cache, inspect live HTMLEvidence that the change is live
6 ReviewCompare against baseline after 28 days, keep, iterate, or roll backOne conclusion

The baseline needs four numbers, impressions, clicks, CTR, and average position. Looking at CTR without impressions mistakes a drop in impressions for a rise in CTR. Split brand and non-brand queries. Brand terms usually carry higher CTR, and blending them hides changes on non-brand pages.

Use a 28-day window that matches the baseline period. Write the criteria before the change. For example, passing means CTR improves and average position does not fall by more than one place. Rolling back means CTR is flat or lower. Do not define the standard after seeing the data, because you will always find a reason to keep the change.

Changing one element at a time protects attribution. If the title and description both change and CTR moves, you do not know which one to keep. If several pages must change together, at least keep one element per page so variables do not stack on the same URL. For general experiment design, single variables, preset windows, and criteria first, see the AI-era content strategy piece. Length experiments and differentiated A/B tests belong to a child node that will be linked once published.

Verify It Is Live Before Discussing Results

This is the most valuable lesson from the October batch. Changed is not the same as live, and live is not the same as effective. The order matters.

The verification checklist.

First, inspect the live HTML for <title>, meta name="description", and <h1>. Use curl against the public page, not a local preview.

Second, compare dist with production. If dist has the new title and production has the old one, deployment or cache is the problem, not the copy.

Third, purge the CDN cache and check again. HTML cache lifetimes can be long. If it still does not change, check the origin.

Fourth, confirm you edited the source the page actually reads. Local MDX, CMS fields, and a Payload content source can coexist. Know which one feeds the page before changing anything.

Fifth, request a recrawl in Search Console and watch indexing and impressions. Index updates take time, so do not judge on the same day.

Sixth, review against the preset criteria after 28 days. CTR up with position down may mean the title is more clickable but less relevant. CTR flat with position up may come from another change. Write the possible factors into the review instead of forcing attribution.

One useful habit is to save the live evidence, a screenshot or HTML fragment, next to the change record. The next time a change appears not to work, check the record first. It saves hours.

Common Misconceptions

Sixty characters is a hard rule. Results truncate by pixel width and Google rewrites titles. Character counts only reduce risk.

Stuff the title with keywords. More keywords weaken the click promise and raise the chance of a rewrite.

Repeat the title in the description. The description should answer what the title did not.

Use a logo or several H1s. A page with no clear main heading makes machines and readers work harder.

Change the copy and skip the live check. A successful commit is not a successful deployment, and a deployment is not a cache purge.

Change three elements at once. Attribution disappears, and the review becomes guesswork.

Promise a CTR lift. Titles influence clicks, but the size depends on query, competition, brand, and position. Nobody can guarantee a percentage in advance.