On Google Search Results Pages (SERP), a webpage’s visibility is determined by over 200 algorithmic indicators.
Data shows that optimized meta descriptions can increase search result click-through rate (CTR) by 15%-30%—users often decide whether to click within 0.5 seconds based on the title and description.
If the viewport tag (mobile adaptation tag) is set incorrectly, mobile rankings may drop directly by 15%-20%, and mobile search accounts for over 60% of global searches (StatCounter 2024).
This article focuses on the 14 most critical meta tags in Google SEO, breaking down “what happens when set incorrectly” and “how to verify correct写法,” using real cases and Google’s official guidelines to help you avoid 90% of ineffective operations.

Core SEO Meta Tags
On Google Search Results Pages (SERP), users spend an average of only 0.8 seconds deciding whether to click a link (Google User Behavior Research, 2023).
In those 0.8 seconds, the title (
Meta tags also directly affect Google’s crawling and indexing. For example, incorrect use of the noindex directive in may cause a page to never be indexed, even if the content is referenced by other pages.
<title>
Although
The first line users see in search results is the title, which directly determines whether they “click or not.”
Key setup rules (based on Ahrefs statistics of 100,000 high-click pages):
Length: 50-60 characters (approximately 25-35 Chinese characters). Characters exceeding 60 will be truncated (shorter on mobile, approximately 50 characters).
- Negative example: An education website homepage title reads “2024 Latest Elementary to High School All-Subject Learning Materials Download, Covering Math, Chinese, English, Physics, Chemistry, Free Download with No Hidden Conditions”—98 characters, displayed as “2024 Latest Elementary to High School All-Subject Learning Materials Download, Co…” on mobile, so users can’t see the core selling point “Free Download.”
- Positive example: A parenting blog article title “2-Year-Old Baby Food Introduction Schedule (with 10 Easy Recipes)”—42 characters, fully displayed, containing specific age and “recipe” keywords, CTR 22% higher than similar pages.
Keyword placement: Place core keywords in the front section. Users pay more attention to words at the beginning of titles (eye-tracking research shows users’ gaze is 70% concentrated on the first 30 characters of titles).
- Incorrect example: “[New] 2024 Beijing Renovation Company Rankings, Professional Services for Villas, Apartments, Second-Hand Housing Renovation Design”—keyword “Beijing Renovation Company” is in 6th position.
- Correct example: “Beijing Renovation Companies 2024 Latest Rankings: Villa/Apartment/Second-Hand Housing Renovation Design Services Recommendation”—keywords placed in front, CTR increased by 18%.
Uniqueness: Each page title must be different. Google will lower rankings for pages with duplicate titles (Moz crawler data from 500 websites shows pages with duplicate titles rank an average of 1.2 positions lower than pages with unique titles).
The core of
is “letting users understand at a glance what problem the page can solve,” not keyword stuffing.
<meta name=”description”>
The description tag is the “persuasive text” second only to the title in search results, and high-quality descriptions can increase CTR by 15%-30% (Moz 2023 test data for 1,000 keywords).
Three key points for writing good descriptions:
Length control: 150-160 characters (approximately 75-80 Chinese characters). Characters exceeding 160 will be truncated (Google truncates by default, some devices display shorter).
- Negative example: A travel website page description reads “Provide strategies for globally popular travel destinations, including Southeast Asian islands, European ancient towns, domestic water towns, plus hotel booking, airfare comparison, local food recommendations, one-stop solution for your travel needs”—210 characters, displayed as “Provide strategies for globally popular travel destinations, including Southeast Asian is…” on mobile, so users can’t see the key value “one-stop solution.”
- Positive example: A food blog page description “10 Homemade Dishes Even Beginners Can Make, Detailed Steps, Common Ingredients, Ready in 30 Minutes, with Ingredient List and Failure Analysis”—142 characters, fully displaying pain points like “beginner-friendly,” “30 minutes,” “failure analysis,” CTR 28% higher than ordinary descriptions.
Accurate content match: Descriptions must truthfully reflect page content, otherwise users will quickly bounce after clicking (Google will lower rankings for such pages).
- Incorrect example: A beauty page title is “2024 Summer Sunscreen Recommendations,” but the description reads “Winter Skincare Strategies: Moisturizing Mask, Body Lotion Selection Guide”—users find content mismatch after clicking, bounce rate as high as 75% (Google Search Console data).
- Correct example: Title “2024 Summer Sunscreen Recommendations: List for Oily/Dry/Sensitive Skin,” Description “Tested 15 summer sunscreens, recommended by skin type, with comparison of film-forming time, waterproof performance, ingredient safety, helping you choose sunscreen that won’t cause acne or sunburn”—description highly consistent with content, bounce rate only 32%.
Include call-to-action: Use words like “recommended,” “including,” “view” to guide user clicks (not mandatory, but effective).
- Ordinary description: “This article introduces Python basic syntax.”
- Optimized description: “Must-see for Python beginners! From variables and loops to functions, master basic syntax through 10 cases, including practice problems and answer downloads.”—Latter CTR 20% higher than former (A/B test data).
Descriptions are not “keyword lists,” but “previews of solutions to user problems.”
<meta name=”robots”>
The robots tag is Google’s crawler “action guide,” and incorrect settings may cause pages to never be indexed (such as accidentally adding noindex).
Common directives and usage scenarios (based on Google official documentation):
| Directive Combination | Meaning | Applicable Scenarios |
|---|---|---|
| index, follow | Allow crawling page, allow tracking links on page (default value) | All normal pages that need to be indexed and pass link equity (such as homepage, product pages) |
| noindex, follow | Allow crawling page, but disallow indexing (page won’t appear in search results) | Temporary test pages, duplicate campaign pages (such as “Double 11 warm-up pages,” will later be replaced with official pages) |
| index, nofollow | Allow indexing page, but disallow tracking links on page (link equity won’t pass) | Pages with many external links (such as industry navigation pages), but don’t want links to dilute equity |
| noindex, nofollow | Disallow crawling and disallow tracking links (both page and links are “invalid”) | Sensitive pages (such as internal data reports), dead link pages (deleted but 404 not set) |
Common errors:
- Duplicate noindex settings: A corporate official website had a technical issue adding noindex directives in both the page header and HTTP header, causing the website to not be indexed for half a year (Google Search Console shows “discovered – not indexed”).
- Misusing nofollow to restrict internal links: An e-commerce website added nofollow to all “product detail page” links to prevent equity loss, causing newly listed products to be undiscoverable by crawlers, indexing decreased by 40%.
Verification method: Use Google Search Console’s “URL Inspection” tool, enter page URL, check if “indexing status” and “robots tag” are correctly recognized.
The core of the robots tag is “clearly telling Google the ‘purpose’ of the page”—if it needs to be indexed, don’t add noindex; if it needs to pass equity, don’t add nofollow.
<meta name=”viewport”>
Global mobile search has reached 62% (StatCounter 2024), and viewport settings errors are one of the main causes of mobile ranking drops (Google Mobile-First Indexing Guidelines).
Core parameters and functions:
width=device-width: Set page width equal to device screen width (avoid layout chaos from default scaling).initial-scale=1.0: Initial zoom ratio is 1:1 (avoid automatic page minimization by phone, causing unreadable text).maximum-scale=1.0, user-scalable=no(optional): Disable manual zooming (suitable for pure mobile pages, but use with caution, may affect accessibility).
Consequences of incorrect settings:
- A news APP official website once set viewport to
width=1024(fixed PC width), mobile users had to manually zoom to read, causing mobile bounce rate to reach 85%, and mobile ranking dropped from page 3 to page 10 (Google Search Console data). - An e-commerce mini-program official website didn’t set
initial-scale=1.0, default scaling was 0.5, users saw blurry page text, CTR 35% lower than similar pages.
Verification method: Open page in Chrome browser, press F12 to open developer tools, select “Device Mode,” check if page adapts to screen width and text is clear.
The essence of viewport is “letting mobile users read comfortably without zooming,” which is Google’s basic metric for evaluating mobile experience.
<meta charset=”UTF-8″>
Character encoding determines whether page text displays correctly. Over 90% of websites globally use UTF-8 (W3Techs 2024), which is Google’s only recommended encoding.
Why must you use UTF-8?
- Avoid garbled text: If a page uses GBK encoding but declares UTF-8, Chinese will display as “口口口”; conversely, UTF-8 pages parsed with GBK will also be garbled.
- Affected crawling: Google’s crawler success rate for garbled pages is only 30% (normal pages are 95%), which may cause content to not be correctly indexed.
Common errors:
- An overseas trade website mistakenly declared
charset=ISO-8859-1for “compatibility with foreign users,” causing Chinese product descriptions to display as garbled text, and Chinese region search rankings disappeared entirely (Google Search Console shows “content could not be parsed”). - A blog platform defaults to UTF-8 encoding, but the editor accidentally saved articles as GBK, causing garbled display on the frontend, user complaints increased by 60%.
Verification method: Check page source code to see if <meta charset> tag exists and is “UTF-8”; visit page with phone to confirm no garbled text.
UTF-8 is a “universal translation” that lets both Google and users “understand” your page.
Canonical URL Declaration, Deduplication of Multiple Version Content
Google crawls trillions of web pages daily, and approximately 30% of web pages have duplicate content (Google Search Central 2023 data).
Duplicate content confuses Google: “Which version is most needed by users?” Improper handling can cause all related page rankings to drop.
A real example: An e-commerce website once failed to standardize URL parameters for “product detail pages” (such as “?from=home” and “?from=search”), causing the same product to appear under more than 20 different URLs.
Google crawlers viewed these as independent pages, ultimately causing the entire product category ranking to drop from page 2 to page 10, with monthly traffic decreasing by 45% (Google Search Console backend data).
Canonical URL declarations (<link rel="canonical">) and multi-version content markup (<link rel="alternate" hreflang>) are precisely the solutions to such problems.
<link rel=”canonical”>
The canonical tag’s (abbreviated as “canonical tag”) role is to specify the “official representative URL” of the current page.
Google will prioritize crawling and indexing this URL, and the equity from other duplicate pages will also concentrate on it.
Three standards for choosing the correct canonical URL (based on Google official guidelines):
| Standard | Description | Example |
|---|---|---|
| Simplicity | Avoid redundant parameters (such as tracking parameters “?utm_source=xxx”) | Choose “https://www.example.com/product” instead of “https://www.example.com/product?utm_source=weibo” |
| Stability | Permanently existing URL (not frequently changing over time) | Prefer “https://www.example.com/blog/seo-guide” instead of “https://www.example.com/blog/seo-2023” |
| Content match | URL that exactly matches current page content | If current page is “2024 iPhone 16 Review,” canonical URL should point to the same review’s permanent address, not “2023 iPhone 15 Review” |
Common application scenarios and operations:
1. PC version and mobile version pages:
A news website once set separate URLs for PC and mobile (PC version “https://www.news.com/article,” mobile version “https://m.news.com/article”).
Without canonical tags, Google viewed both as duplicate content, and mobile page ranking was only 1/3 of PC version (Ahrefs data).
Correct approach: Add canonical tag in mobile version page header pointing to PC version URL (or vice versa, based on users’ primary access device):
<<link rel="canonical" href="https://www.news.com/article">
2. URLs with parameters (such as filtering, sorting):
An e-commerce platform’s product pages have parameters like “sort by price” and “sort by sales” (such as “https://shop.example.com/shoes?sort=price” and “https://shop.example.com/shoes?sort=sales”).
These pages have highly similar content, without standardization Google may randomly index one, causing users searching for “cheap sports shoes” to possibly not get precise matches.
Correct approach: Choose the base URL without parameters as the canonical address (such as “https://shop.example.com/shoes”), add canonical tags on other parameterized pages pointing to it:
<<link rel="canonical" href="https://shop.example.com/shoes">
3. Paginated content (such as article list page 2, page 3):
A blog’s article list has 10 pages of pagination (such as “https://blog.example.com/page/2,” “https://blog.example.com/page/3”). Without standardization, Google may only index page 1, subsequent paginated content cannot be indexed, and users searching for “latest 10 technical articles” can only see page 1.
Correct approach: Add canonical tags on all paginated pages pointing to page 1 (or select the main page based on content importance):
<<link rel="canonical" href="https://blog.example.com/page/1">
Common errors:
- Conflicting multiple canonical tags: A corporate official website had a technical failure adding two different canonical tags on the same page (such as simultaneously pointing to “https://www.example.com” and “https://www.example.com/home”). Google couldn’t recognize this, and the page was not indexed for half a year (Google Search Console shows “discovered – not indexed”).
- Canonical tag pointing to irrelevant page: An education website incorrectly pointed the course detail page’s canonical tag to the homepage, causing course page ranking to drop from page 5 to page 20 (A/B test data).
Verification method: Use Google Search Console’s “URL Inspection” tool, enter page URL, check if “canonical tag” displays as the URL you set.
<link rel=”alternate” hreflang>
The hreflang tag is used to mark different language or region versions of the same content (such as Chinese version, English version, US version, UK version).
Its core function is to let Google serve the most relevant version to users in different regions, avoiding problems like “Chinese users seeing English pages” or “US users seeing Australian versions.”
Core format and rules:
- Must include the hreflang attribute (value is language-region code, such as “zh-cn” for Simplified Chinese China version, “en-us” for American English US version).
- Must point to absolute URL of corresponding version (including “https://”).
- All associated pages must mark each other (page A marks page B, page B marks page A).
Example: Correct markup for multilingual website
A multinational company’s official website has Chinese, English, and Japanese versions:
- Chinese version:
https://www.global.com/cn - English version:
https://www.global.com/en - Japanese version:
https://www.global.com/jp
Each page needs to add the following tags in the header (using Chinese version as example):
<link rel=”alternate” hreflang=”zh-cn” href=”https://www.global.com/cn”>
<link rel=”alternate” hreflang=”en-us” href=”https://www.global.com/en”>
<link rel=”alternate” hreflang=”ja-jp” href=”https://www.global.com/jp”>
Common errors and consequences:
- Language code error: A travel website incorrectly marked “Simplified Chinese China version” as “zh-ch” (correct should be “zh-cn”). Google couldn’t recognize this, and Chinese users may have been served the English version when searching, with bounce rate as high as 65% (Google Analytics data).
- Missing mutual marking: A cross-border e-commerce only marked the English version link on product pages, but the English version page didn’t mark the Chinese version link. Google determined “insufficient correlation” between the two, and both versions’ rankings dropped by 20% (Moz test data).
- Redundant region codes: A company created separate pages for “American English” and “British English,” but incorrectly marked both “en-us” and “en-gb” as “en” (too broad). Google couldn’t distinguish, and users may receive mismatched versions (such as British users seeing American-spelled pages).
Verification method: Use Google’s “hreflang testing tool” (https://technicalseo.com/tools/hreflang/) to enter page URL and check if all associated pages are correctly marked.
Coordination of Canonical Tags and Hreflang
In practice, canonical tags and hreflang often need to be used together.
First use canonical to determine the “main version,” then use hreflang to mark multilingual/region versions—this is key to avoiding confusion.
Case: Optimization process of an international education institution
The institution’s official website has 3 language versions (Chinese, English, Spanish) and PC/mobile version pages, with no prior standardization:
- Chinese version has two URLs: “https://edu.example.com/cn” and “https://edu.example.com/cn?source=wechat”.
- English version PC page is “https://edu.example.com/en,” mobile version is “https://m.edu.example.com/en”.
Problems before optimization:
- Google viewed “https://edu.example.com/cn?source=wechat” as an independent page, causing duplicate Chinese version content, and the main version ranking was diluted.
- Mobile and PC versions were treated as different pages, and mobile users saw content mismatched with PC (such as button positions misaligned).
Optimization steps:
- Set canonical tags:
- Add canonical tags on all Chinese version pages (with parameters) pointing to “https://edu.example.com/cn”.
- Add canonical tag on mobile English page pointing to PC version “https://edu.example.com/en”.
- Set hreflang tags:
- Mark Chinese version page “zh-cn” pointing to itself, while associating English and Spanish versions.
- Mark English version PC page “en-us” pointing to itself, while associating Chinese and Spanish versions.
Post-optimization effects (after 3 months):
- Chinese main page ranking rose from page 5 to page 1, and organic traffic increased by 80%.
- Mobile user bounce rate decreased from 70% to 45%, and mobile ranking improved by 12 positions.
Optimization for Mobile Display
StatCounter 2024 data shows global mobile search has reached 62%, surpassing PC as users’ primary search scenario.
However, Google’s 2023 analysis of crawl logs from 100,000 websites found that 70% of mobile pages have “display chaos” problems—text overlapping, button overlapping, image overflow—causing user bounce rate to increase by 30% (Google User Behavior Research Report).
A real example: A local life service platform once didn’t correctly set mobile viewport, so mobile users visiting had page text compressed to “tiny ants,” and buttons required zooming in 3 times to click.
The page’s mobile bounce rate was as high as 82%, and monthly mobile traffic was 55% less than similar pages with proper adaptation (Google Search Console backend data).
viewport tag
The viewport tag (<meta name="viewport">) is the core configuration for mobile display, and its role is to tell the browser “how to scale the page to fit phone screens.”
Incorrect settings cause page text to blur, buttons to overlap, directly reducing user dwell time.
Core parameters and functions (based on W3C standards):
| Parameter | Recommended Value | Function | Error Examples and Consequences |
|---|---|---|---|
width |
device-width |
Set page width equal to phone screen width (avoid default scaling) | Set to fixed value (such as width=1024): Phone requires manual zooming to read, bounce rate increases by 40% (A/B test) |
initial-scale |
1.0 |
Initial zoom ratio is 1:1 (avoid default page minimization) | Set to 0.5: Text too small requires zooming, user click conversion rate decreases by 25% (Google Analytics) |
maximum-scale |
1.0 (optional) |
Disable user manual page zooming (suitable for pure mobile-designed pages) | Set to 5.0: Users may accidentally zoom causing layout chaos, affecting reading experience |
user-scalable |
no (optional) |
Disable user manual zooming (use with caution, may affect accessibility) | Set to yes: Some users may zoom pages, breaking design consistency |
Practical suggestions:
- Beginners can directly use universal configuration:
<meta name="viewport" content="width=device-width, initial-scale=1.0">. - If page contains many images or charts, add
maximum-scale=1.0to prevent accidental zooming from deforming images.
Flexible Layout is Safer than “Fixed Pixels”
Phone screen sizes vary greatly (from 4 inches to 7 inches), using “fixed pixels” (such as width: 300px) to define container width will cause small-screen phones to have content overflow and large-screen phones to have excessive white space.
Flexible layouts (Flexbox) or percentage layouts can automatically adapt to different screens, and are the core solution for mobile layout.
Comparative test data (Ahrefs statistics of 200 mobile pages):
| Layout Method | Text Overlap Rate | User Dwell Time | Bounce Rate |
|---|---|---|---|
| Fixed pixel layout | 42% | 12 seconds | 78% |
| Flexible layout (Flexbox) | 8% | 28 seconds | 35% |
Specific operational methods:
- Use
max-width: 100%for container width instead of fixed values (such aswidth: 600px), ensuring it doesn’t exceed screen width. - Set text line height to
1.5emor above (such asline-height: 1.6), avoiding cramped text on small screens. - Use
width: 100%; height: autofor images, letting images automatically scale with container width (avoid overflow).
Negative example: A food blog article list used fixed pixel width (width: 700px), when displayed on a 5-inch phone, text was compressed to a single line, and users had to swipe left and right to read, with bounce rate as high as 85% (Google Search Console).
Correct example: An e-commerce APP product detail page used flexible layout (display: flex), with images and text automatically adapting to screen, and user dwell time extended from 15 seconds to 40 seconds, with conversion rate improving by 22%.
Click Areas Should Be at Least 48×48 Pixels
Mobile users operate by tapping with fingers. If buttons are too small (such as 30×30 pixels), users easily tap the wrong empty areas or adjacent buttons, causing operation failures and poor experience.
Google recommends minimum click area of 48×48 pixels for mobile interactive elements (based on human-computer interaction research).
Correlation data between click area and user behavior (Google User Research Lab):
| Button Size (pixels) | Misclick Rate | Time to Complete Operation | User Satisfaction Score (1-5) |
|---|---|---|---|
| 30×30 | 35% | 8 seconds | 2.1 |
| 48×48 | 8% | 3 seconds | 4.5 |
| 60×60 | 3% | 2 seconds | 4.8 |
Practical suggestions:
- Set navigation bar buttons and form submission buttons to at least
48px×48px(can control with CSSmin-widthandmin-height). - Keep at least
16pxspacing between buttons (avoid accidentally touching adjacent buttons). - Text button font size (such as “Buy Now”) should be at least
16px(easier to identify on small screens).
Case: A bank APP login page had original “Login” button size of 36px×36px, with 40% probability of users accidentally tapping the “Forgot Password” button.
After optimization, button size was changed to 48px×48px, with 16px spacing added, misclick rate dropped to 5%, and login success rate improved by 28%.
“Slow Image Loading” Requires Coordination of Viewport and Lazy Loading
Mobile network environments are unstable (weak 4G/5G signals, high Wi-Fi latency). If page images aren’t adapted for mobile size or load too slowly, it will cause user churn.
Coordination of viewport settings and image lazy loading can significantly improve loading speed.
Specific impact of slow image loading (Akamai 2024 Mobile User Experience Report):
| Loading Time (seconds) | Bounce Rate | Conversion Rate |
|---|---|---|
| ≤2 seconds | 18% | 5.2% |
| 3-5 seconds | 45% | 2.1% |
| ≥6 seconds | 72% | 0.8% |
Optimization methods:
- Use viewport to control image width: Add
width=device-widthattribute to image tags (or set via CSSmax-width: 100%), avoiding loading PC high-resolution images (such as1920px×1080px). - Enable lazy loading: Load images only when they enter the user’s visible area (Google supports native
loading="lazy"attribute).
Example code:
<img src="product.jpg" alt="Product Image" loading="lazy" width="600" height="400">.
Case: A travel website originally loaded PC high-resolution images (2000px×1500px), with mobile loading time as long as 8 seconds, bounce rate 75%. After optimization:
- Used viewport to limit image width to
100%(phone screen width). - Replaced with mobile-specific smaller images (
600px×450px). - Enabled lazy loading.
Post-optimization loading time reduced to 2 seconds, bounce rate dropped to 20%, and mobile traffic increased by 60%.
Testing Tools Help Quickly Identify Problems
Mobile adaptation issues (such as text overlapping, button misalignment) may be missed by visual observation, and professional tools can quickly locate and resolve problems.
Recommended testing tools and usage methods:
| Tool Name | Function | Operation Steps |
|---|---|---|
| Chrome Developer Tools | Simulate different phone models (such as iPhone 15, Samsung S24), view page adaptation effects in real-time | 1. Right-click page → “Inspect” → Open developer tools; 2. Click “Toggle Device Toolbar” (Ctrl+Shift+M); 3. Select phone model, view page layout. |
| Lighthouse (Google Official) | Generate mobile performance report, including “Adaptability,” “Clickable Area” and other scores | 1. Open developer tools → Click “Lighthouse”; 2. Check “Mobile” → Generate report; 3. View specific issues in “Mobile Adaptation” section. |
| BrowserStack | Test pages on real phones (covering iOS, Android different models) | 1. Visit https://www.browserstack.com; 2. Select target phone model; 3. Enter page URL, view display effects in real-time. |
Case: An education platform official website simulated iPhone 15 in Chrome Developer Tools and found the “Course Category” button was blocked by images.
By adjusting CSS z-index property (raising button level), after solving the problem, mobile click conversion rate improved by 19%.
Control Social Platform Share Preview Effects
On social media, a content’s share preview (title + description + cover image) determines 80% of whether users click (Meta 2023 User Behavior Report).
For example, when an article from a tech blog was shared on Facebook, the original preview title was “2024 AI Development Trends” (12 characters), description was “This article discusses AI technology” (8 characters), and cover image was a blurry logo (100×100 pixels).
This share’s click rate was only 2%;
After optimization, title changed to “2024 AI Development Trends: Large Models, Multimodal, Complete Analysis of Industry Implementation” (28 characters)
Description supplemented with “Including 10 industry cases and 3 key technology predictions,” cover image replaced with 1200×630 pixel high-resolution image, and click rate directly increased to 12% (A/B test data).
Open Graph Tags
Open Graph (OG) tags were developed by Facebook and have become the universal preview standard for global mainstream social platforms (such as LinkedIn, Pinterest).
Its core function is to tell social platforms: “What should this link’s title, description, and cover image look like?”
Four required OG attributes and optimization rules (based on Meta official guidelines):
| Attribute Name | Function | Recommended Settings | Common Errors and Consequences |
|---|---|---|---|
og:title |
Share preview title (displayed at top) | Length ≤60 characters (approximately 30 Chinese characters), include core keywords, avoid stuffing. | Title too long and truncated (such as original “2024 AI Development Trends: Large Models, Multimodal, Complete Analysis of Industry Implementation” truncated to “2024 AI Development Trends: Large Models, Multimodal…”), click rate decreased by 25% (Facebook internal test). |
og:description |
Share preview description (below title, supplementary content explanation) | Length ≤160 characters (approximately 80 Chinese characters), use specific numbers/pain points to attract clicks (such as “Including 10 industry cases”). | Vague description (such as “This article discusses AI technology”), users cannot judge value, click rate only 1.5% (control group data). |
og:image |
Share preview cover image (most eye-catching element) | Size ≥1200×630 pixels (square or 1.91:1 aspect ratio), file size ≤5MB, format JPG/PNG. | Image size too small (such as 100×100 pixels): Preview displays blurry, user skip rate as high as 70% (LinkedIn data). |
og:url |
Share target URL (needs to match current page URL) | Use absolute path (including “https://”), avoid redirects (such as redirecting to “https://www.example.com” instead of “https://example.com”). | URL error (pointing to deleted page): Users see 404 after clicking, damaging social account credibility (Meta user feedback). |
Practical case: Optimization of an education institution course page
Original OG tag settings:
<meta property=”og:title” content=”Programming Course”>
<meta property=”og:description” content=”Learn Programming”>
<meta property=”og:image” content=”logo.png”>
<meta property=”og:url” content=”https://edu.example.com/course”>
After optimization:
<meta property=”og:title” content=”2024 Python Beginner Course: From Zero Basics to Independent Projects (Including 10 Practice Sets)”> (52 characters)
<meta property=”og:description” content=”Python course suitable for zero basics, including 30 video lessons + 10 practical exercise sets + mentor Q&A, able to independently do data scraping and automated office work after completion.”> (148 characters)
<meta property=”og:image” content=”python-course-preview.jpg”> (1200×630 pixels, file size 3.2MB)
<meta property=”og:url” content=”https://edu.example.com/python-course”> (absolute path, no redirects)
Post-optimization effects (Facebook share test):
- Title fully displayed, description supplemented pain points like “zero basics” and “including practice problems,” click rate increased from 2% to 10%.
- Cover image clearly displays course interface, users commented “looks very practical,” engagement (likes/comments) increased 3 times.
Twitter Cards
Twitter Cards is a meta tag system specifically designed by Twitter for social sharing, lighter-weight than Open Graph (suitable for short text + image scenarios).
Its core function is to control how title, description, image, and link display when sharing on Twitter.
Three required Twitter Card attributes and optimization rules (based on Twitter official documentation):
| Attribute Name | Function | Recommended Settings | Common Errors and Consequences |
|---|---|---|---|
twitter:card |
Define card type (determines preview style) | Common types: summary (basic version: title + description + small image), summary_large_image (large image version: title + description + large image). |
Type error (such as using summary but adding large image): Twitter automatically degrades to summary, large image cannot display (Twitter test data). |
twitter:title |
Share preview title | Length ≤70 characters (approximately 35 Chinese characters), slightly longer than OG title (Twitter display area is wider). | Title contains too many symbols (such as “!!!” “【】”): Visual interference for users, click rate decreased by 18% (A/B test). |
twitter:image |
Share preview cover image | Size ≥1200×675 pixels (16:9 aspect ratio), file size ≤5MB, format JPG/PNG. | Image aspect ratio incorrect (such as 4:3): Twitter automatically crops, key content may be cut off (such as person’s head cut off). |
Advanced tips: twitter:site and twitter:creator
twitter:site: Mark the official account publishing content (such as @ExampleEdu), Twitter will display “via @ExampleEdu” below the preview, increasing credibility.twitter:creator: Mark the content creator account (such as @TeacherLi), suitable for multi-person collaborative content (such as column articles).
Case: Twitter share optimization of a tech media article
Original Twitter Card settings:
<meta name=”twitter:card” content=”summary”>
<meta name=”twitter:title” content=”AI New Breakthrough”>
<meta name=”twitter:image” content=”ai-logo.jpg”>
After optimization:
<meta name=”twitter:card” content=”summary_large_image”> (switched to large image version)
<meta name=”twitter:title” content=”2024 AI New Breakthrough: Multimodal Large Models Implementation, These 3 Industries Will Benefit First”> (68 characters)
<meta name=”twitter:image” content=”ai-breakthrough.jpg”> (1200×675 pixels, file size 4.1MB)
<meta name=”twitter:site” content=”@TechNewsOfficial”> (official account)
Post-optimization effects (Twitter share test):
- Large image version card displays 20% more content area than basic version, click rate increased from 1.2% to 5.8%.
- Official account marking makes users more trusting of share source, retweet count increased by 40% (Twitter Analytics data).
Testing is More Important Than Setting
Even if OG and Twitter tags are set according to rules, actual sharing effects may still have problems due to platform differences, caching, or code errors.
Recommended testing tools and operation methods:
| Tool Name | Supported Platforms | Function | Operation Steps |
|---|---|---|---|
| Facebook Sharing Debugger | Facebook, LinkedIn, etc. | Detect if OG tags are correct, preview sharing effects, clear platform cache | 1. Visit https://developers.facebook.com/tools/debug; 2. Enter page URL → Click “Debug”; 3. Check if “OG tags” match, click “Scrape Again” to update cache. |
| Twitter Card Validator | Detect if Twitter Card tags are correct, preview sharing effects | 1. Visit https://cards-dev.twitter.com/validator; 2. Enter page URL → Click “Validate”; 3. Check if “Card type” and “Preview image” match expectations. |
|
| Caoliao QR Code | All platforms | Generate share QR codes with parameters, quickly test mobile display effects | 1. Visit https://cli.im/; 2. Enter page URL → Generate QR code; 3. Scan with phone, view actual share preview. |
Common testing problems and solutions:
- Image fails to load: Check if URLs for
og:imageortwitter:imageare correct (whether there are spelling errors, whether login is required). - Title/description truncated: Shorten title/description length (OG title ≤60 characters, Twitter title ≤70 characters).
- Preview shows old content: Use Facebook Debugger or Twitter Validator’s “Scrape Again” function to clear platform cache.
“SEO Value” of Social Share Preview
Many people think social share tags only affect sharing effects and have nothing to do with SEO.
But data shows that high-engagement social shares can indirectly improve page rankings in search results (Google Search Central 2024 research).
Specific logic:
- High social share count → More users click → Google crawler finds page “popular with users” → Improve ranking weight.
- Share preview title/description highly consistent with page content → Long user dwell time → Google determines “strong content relevance” → Improve ranking.
Case: The “Unintentional Benefit” Effect of a Parenting Blog
A parenting blogger published an article about “2-Year-Old Baby Food Recipes,” casually added OG tags:
og:title: “2-Year-Old Baby Food Recipes: 10 Easy, Nutritious Homemade Dishes” (46 characters)og:description: “Including ingredient list, step photos, and allergy tips, even new moms can easily make them” (58 characters)og:image: “baby-food.jpg” (1200×630 pixels, showing cute photo of baby eating solid food)
This share was forwarded many times in mom groups, Facebook share clicks reached 5,000 times, with 80% of users staying over 2 minutes (viewing recipes).
Three months later, the page’s search ranking for “2-year-old baby food” keyword rose from page 10 to page 1, with monthly search traffic increasing by 200% (Google Search Console data).
Other Functional Meta Tags
Functional meta tags don’t directly affect click rate or ranking like description or viewport.
But they handle character encoding, browser compatibility, automatic redirects… these seemingly “secondary” operations affect whether Google can correctly crawl content
W3Techs 2024 data shows 92% of websites globally use <meta charset> tags, but 8% of websites still have character set errors causing garbled text (such as writing UTF-8 as GB2312);
Another analysis of crawl logs from 100,000 websites found that due to X-UA-Compatible setting errors, old IE users saw page chaos at a rate as high as 15%, directly causing bounce rate to increase by 25% (Google Search Console data).
<meta charset=”UTF-8″>
Character encoding determines whether page text can be correctly displayed and crawled. Over 90% of websites globally use UTF-8 (W3Techs 2024), which is Google’s only recommended encoding and the “universal translation” for multilingual websites including Chinese, English, Japanese, and more.
Why must you use UTF-8?
- Avoid garbled text: If a page uses
GBKencoding but declaresUTF-8, Chinese will display as “口口口”; conversely, UTF-8 pages parsed withGBKwill also be garbled. - Affected crawling: Google’s crawler success rate for garbled pages is only 30% (normal pages are 95%), which may cause content to not be correctly indexed (Google Search Central 2023).
Common errors and consequences:
- Incorrect encoding declaration: An overseas trade website mistakenly declared
charset=ISO-8859-1(European language encoding) for “compatibility with foreign users,” causing Chinese product descriptions to display as garbled text, and Chinese region search rankings disappeared entirely (Google Search Console shows “content could not be parsed”). - Missing encoding declaration: A blog platform defaults to
UTF-8, but the editor accidentally saved articles asGBKwithout declaringcharset, causing garbled display on the frontend, user complaints increased by 60%.
Verification methods:
- Check page source code to confirm
<meta charset>tag exists and is “UTF-8” (correct writing:<meta charset="UTF-8">). - Visit page with phone or old computer to check if text is clear and without garbled text.
<meta http-equiv=”X-UA-Compatible”>
The X-UA-Compatible tag tells IE browsers “which rendering engine to use for the page.”
Although IE is being phased out (StatCounter 2024 data shows IE’s global market share is only 1.2%), some enterprise users or government websites still need to support old IE versions (such as IE9 and below).
Core rules:
- If old IE support is needed, set
content="IE=edge"to force use of IE’s latest rendering engine (such as IE9+). - If old IE support is not needed (such as websites targeting young users), this tag can be omitted (modern browsers will ignore it).
Consequences of incorrect settings:
A government website once didn’t set X-UA-Compatible, so old IE users visiting had page elements misaligned (such as button overlapping, text overflow), user complaints increased by 40% (internal customer service data).
Correct example:
<!– Force IE to use latest rendering engine –>
<meta http-equiv=”X-UA-Compatible” content=”IE=edge”>
Verification method:
Open page with IE9 or below version to check if elements display normally (such as button alignment, text without overflow).
<meta http-equiv=”refresh”>
The refresh tag sets “automatic redirects” (such as redirecting to new page after 3 seconds).
Its core function is “guiding users to quickly leave the current page,” but Google clearly states it does not recommend using this method for redirects (may be considered “spam behavior”).
Applicable scenarios and risks:
- Usable scenarios: Only when page has permanently expired (such as old campaign page) and there are no other repair methods, can
refreshtemporarily be used to redirect to new page. - Risks: Abuse of
refresh(such as frequent redirects, redirecting to unrelated pages) will be judged by Google as “low-quality content,” lowering page rankings (Moz 2023 test data).
Correct and incorrect comparison:
- Incorrect example: An e-commerce product page set
<meta http-equiv="refresh" content="3;url=https://shop.example.com/new-page">, users were forcibly redirected right after opening the page, bounce rate as high as 90% (Google Analytics data). - Alternative solution: If users need to be guided to a new page, prioritize using buttons or text links (such as “Click here to view latest promotions”), and user-initiated clicks are more recognized by Google.
Verification method:
Use Chrome Developer Tools “Network” panel to check if there are 301/302 redirects (recommended) or refresh tags (not recommended).
<meta name=”referrer”>
The referrer tag controls the Referer header information sent by the browser (meaning “which page the user navigated from”).
Its core function is to protect user privacy or meet data analysis needs.
Common strategies and applicable scenarios:
| Strategy Value | Meaning | Applicable Scenarios |
|---|---|---|
no-referrer |
Don’t send any source information | Privacy-sensitive pages (such as medical consultation pages), avoid user source being tracked. |
origin |
Only send source domain (such as “https://www.example.com”), without specific path | Track which website users come from, but don’t need specific page information (such as advertising effectiveness analysis). |
strict-origin |
Only send source domain when current page is HTTPS; HTTP pages don’t send | Mixed content pages (partially HTTPS, partially HTTP), balancing privacy and data analysis. |
Actual impact:
A medical consultation website set referrer="no-referrer" and lost user source data, but privacy complaints decreased by 70% (internal compliance report);
An advertising platform didn’t set referrer strategy, so advertisers couldn’t accurately track “which websites brought effective clicks,” and ad ROI decreased by 25% (advertising backend data).
Verification method:
Use Chrome Developer Tools “Network” panel to check if the Referer field in request headers matches expectations.
In the end, the existence of SEO meta tags is not to “flatter algorithms,” but to let both Google and users “smoothly use your website.”



