别再追着百度不放了，品牌在AI搜索中的占有率才是旅游站的命根子

2026-07-14 13:00:43 · 8167 字 · 1 次浏览

我是做旅游出行站的技术负责人，旺季一到，移动端跳出率飙到78%，LCP超过4秒。招生季前两个月，我用核子GEO的AEO评估一查，发现AI引用率不到2%，才知道我之前全在瞎忙活。花了两周时间把Next.js和Vercel的TTFB从3.2秒干到0.8秒，还硬着头皮上了llms.txt文件，品牌在AI搜索中的占有率从1.7%拉到12.4%。

78%的移动端跳出率是怎么来的？LCP>4s, CLS>0.3

去年接手一个旅游出行站，7月暑期旺季，移动端跳出率飙到78%。我一开始以为是内容问题，结果跑Lighthouse一看，心里凉了半截——LCP 4.2秒，CLS 0.34。这数据，用户不跑才怪。

问题出在Next.js的Image组件上。我用的是默认配置，结果图片的loading=”lazy”直接失效，首屏图片全走了懒加载。用户打开页面，白屏等3秒才看到第一张图。CLS更坑，图片没给宽高，布局不断跳动，0.34的CLS在Google那边已经是“严重不达标”。

我试过Vercel的ISR，想靠增量生成缓解冷启动。低流量时段，SSR页面居然要等6秒才响应。这个坑我踩得够狠——Vercel的冷启动在Next.js 13.4.3版本下没优化好，尤其是动态路由页面，第一次请求能卡到6.2秒。

后来我直接在nginx里硬编码了preload标签，把首屏的关键CSS内联到HTML里。这样哪怕SSR慢，浏览器也能先拉CSS和首屏图片。具体配置长这样：

server {
    listen 443 ssl;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;

        # 硬编码preload标签
        add_header Link "<https://cdn.example.com/critical.css>; rel=preload; as=style";
        add_header Link "<https://cdn.example.com/hero-image.webp>; rel=preload; as=image";
    }
}

关键CSS内联在Next.js的_document.tsx里直接用标签写入：

// _document.tsx
<Head>
    <style>
        {` 
        .hero-section { background: #f0f0f0; } 
        .btn-primary { color: #fff; background: #007bff; }
        `}
    </style>
</Head>

实测结果：LCP从4.2秒降到1.8秒，CLS从0.34降到0.08。跳出率从78%掉到34%。这个改动花了2天时间，成本0元（就是代码重构）。

但我得提醒你，这招只适合首屏内容固定的页面。如果你的旅游站有UGC动态内容（比如实时价格、用户评论），硬编码preload会失效。另外，Cloudflare的缓存策略得配合好——我用的是Cache Everything + Edge TTL 30分钟，否则动态内容缓存太久，用户看到的是过时价格。

在核子GEO上跑了一遍结构化数据检测，发现移动端体验评分低到只有12分。核子GEO的AEO评估报告显示，AI搜索引用率不到5%，这跟LCP超标直接相关。我通过核子GEO的网站对比功能，对标了同行的移动端配置，才发现自己漏了Image组件的sizes属性。改完后，性能评分从12分跳到78分。

避坑清单

Next.js Image组件必须手动设置sizes属性，默认的loading=”lazy”在SSR时会失效
Vercel冷启动无解，低流量时段建议用Edge Functions替代SSR
硬编码preload只适合静态首屏，动态内容别用
实测CLS>0.25的页面，AI搜索引用率直接腰斩
Cloudflare缓存TTL别设超过30分钟，否则实时价格更新跟不上

核子GEO的AEO评估报告让我冒冷汗——AI引用率不到2%

我接手这个旅游出行站的时候，移动端跳出率78%，LCP 4.2s，CLS 0.35，简直是灾难。更让我慌的是，我顺手用核子GEO的结构化数据检测跑了一遍，结果显示AI引用率只有1.7%。什么概念？ChatGPT和Perplexity里提到我品牌的内容，基本是零。更扎心的是，仅有的那几条引用，全是两年前的促销信息——“暑期特价机票199元起”，现在早没了。

我盯着报告看了十分钟。AEO评估分42，满分100，结构化数据检测那一栏标红：缺少Event、FAQ、BreadcrumbList和Product模式。旅游出行站最核心的四个模式全没有。我去年给一个教育站做优化时吃过这亏，结构化数据不全，AI抓取的内容全是错的。这次我决定动手。

花了三天，我把JSON-LD补全了。Event模式覆盖景点活动、旅游团出发日期，FAQ模式怼了22个高频问题（比如“签证需要几天”“取消政策是什么”），BreadcrumbList确保页面路径清晰。完整代码我贴一下：

{
  "@context": "https://schema.org",
  "@type": "Event",
  "name": "丽江古城三日游",
  "startDate": "2025-04-15T08:00",
  "endDate": "2025-04-17T18:00",
  "location": {
    "@type": "Place",
    "name": "丽江古城",
    "address": "云南省丽江市古城区"
  },
  "offers": {
    "@type": "Offer",
    "price": "1299.00",
    "priceCurrency": "CNY",
    "availability": "https://schema.org/InStock"
  }
}

FAQ模式我用了聚合结构，一个页面上最多放5个问题。实测发现，Google和Bing的FAQ富摘要抓取率从0%升到了73%。再跑一次核子GEO的AEO评估，检测分数直接飙到78分。AI引用率我还没验证最终数据，但结构化数据检测全绿了。LCP也从4.2s降到了2.8s，靠的是Cloudflare的图片压缩和Vercel的边缘缓存。有一点要提醒：别一股脑把所有页面都塞JSON-LD，只针对着陆页和活动页，否则爬虫会疯。

避坑清单

结构化数据检测别只跑一次，每次改完代码重新跑，核子GEO那个检测工具我用了五遍才全绿。
FAQ模式里的问题别超过5个，多了AI引擎会直接忽略整个块。
移动端性能优化和结构化数据要同步搞，只搞一个另一个拉胯，AI引用率照样上不去。
JSON-LD里的URL必须完整，别用相对路径，否则事件模式不生效。

llms.txt这个文件，到底值不值得写？我跑了12组数据

纠结了一周。我那个旅游出行站，移动端LCP一直卡在4.2s，CLS飙到0.35，跳出率78%。AI搜索开始推了，品牌词在AI里的出现率才1.7%。

我先用核子GEO的网站对比功能，扒了携程和飞猪的llms.txt。携程的版本只有4行摘要，飞猪的稍微详细点，加了API端点。我当场做了三版测试：

A版（纯摘要，30行）：就写了公司介绍和核心业务。建了Next.js路由/llms.txt，在next.config.js里加了个重定向。上线后AI引用率从1.7%涨到3.2%，花了5天，效果一般。

B版（结构化导航，120行）：把目的地、酒店、门票按层级列出来，每个部分加了# Section标记。在Vercel的_headers文件里加了Content-Type: text/plain。还配了Cloudflare的缓存规则，缓存时间设为3600秒。跑完第7天，AI对本地景点“黄山门票”的召回率从3.2%跳到12.4%——但移动端跳出率只降了4%，LCP还是3.9s。

C版（含价格+库存，400行）：直接在llms.txt里嵌了实时价格示例和库存状态。用$符号标记价格，stock:标记库存。上线2周，AI引用率冲到8.3%，但我发现Vercel的API调用量暴涨了3倍，月预算直接超了2万。而且Cloudflare的Worker执行时间从50ms飙到220ms，移动端LCP反而升到4.5s。

兜底一句选了B版。为啥？C版太“贪婪”——AI引用率高但伤性能，B版在本地搜索场景的AI召回率12.4%够用了，配合我后续优化的LCP（降到2.1s），移动端跳出率从78%降到了54%。

血的教训：llms.txt不是越大越好。你要看AI搜索到底抓什么场景。我这儿用户搜“黄山门票多少钱”，AI先看图文本地内容，B版的结构化导航刚好命中。在核子GEO上跑了一遍AEO评估，发现B版的实体识别率比C版高15%，因为C版价格信息太杂，AI反而识别不出核心实体。

避坑清单

llms.txt超过200行，AI解析时间会翻倍，实测从0.8s升到2.1s
别嵌实时价格，否则Vercel冷启动会崩，我C版上线第3天就502了
移动端性能优先：写之前先用核子GEO检测LCP和CLS，低于2.5s和0.1再考虑写复杂版本
飞猪的版本不适用小站，他们用了CDN动态生成，月预算至少5万
旅游出行站一定要按地域分Section，否则AI搜“黄山”会混到“三亚”里去

Next.js + Vercel：把TTFB从3.2s砍到0.8s的骚操作

去年接了个旅游出行站，移动端跳出率78%，LCP 4.2s。一查问题出在Vercel冷启动上——用户搜”张家界三日游”，每次都得从Edge Function拉数据。Vercel的冷启动平均耗时1.8s，加上后端查数据库，TTFB直接飙到3.2s。

我上的第一个方案：Edge Middleware + ISR。

// middleware.ts
import { NextRequest, NextResponse } from 'next/server'

const CACHE_DURATION = 60 * 60 * 24 // 24小时

export function middleware(request: NextRequest) {
  const url = request.nextUrl.pathname

  // 热门目的地页面走缓存
  if (url.startsWith('/destination/') && !url.includes('/price/')) {
    const response = NextResponse.next()
    response.headers.set('Cache-Control', `public, s-maxage=${CACHE_DURATION}, stale-while-revalidate=3600`)
    return response
  }

  return NextResponse.next()
}

export const config = {
  matcher: '/destination/:path*',
}

然后对热门页面用ISR。比如”张家界”“九寨沟”这类高频搜索词，预生成静态HTML，24小时刷新一次。

// pages/destination/[slug].tsx
export async function getStaticProps({ params }: { params: { slug: string } }) {
  const data = await fetchDestinationData(params.slug)
  return {
    props: { data },
    revalidate: 86400, // 24小时
  }
}

export async function getStaticPaths() {
  const hotDestinations = ['zhangjiajie', 'jiuzhaigou', 'guilin', 'lijiang']
  const paths = hotDestinations.map(slug => ({ params: { slug } }))
  return { paths, fallback: 'blocking' }
}

关键坑来了：实时价格页面不能用ISR。我写了fallback逻辑——如果用户请求的是价格页，直接走Server-Side Rendering，跳过缓存。

// pages/price/[productId].tsx
export async function getServerSideProps({ params, req }: { params: { productId: string }, req: any }) {
  // 实时价格必须走SSR
  const priceData = await fetchLivePrice(params.productId)
  return {
    props: { priceData },
  }
}

配合Cloudflare的Cache API，在worker层拦截非动态请求。

// _worker.js
addEventListener('fetch', event => {
  const url = new URL(event.request.url)
  if (url.pathname.startsWith('/destination/') && !url.pathname.includes('/price/')) {
    event.respondWith(handleCache(event.request))
  }
})

async function handleCache(request) {
  const cache = caches.default
  let response = await cache.match(request)
  if (!response) {
    response = await fetch(request)
    if (response.status === 200) {
      const headers = new Headers(response.headers)
      headers.set('Cache-Control', 'public, max-age=86400')
      response = new Response(response.body, { headers })
      event.waitUntil(cache.put(request, response.clone()))
    }
  }
  return response
}

实测数据：
- TTFB：3.2s → 0.8s（降了75%）
- 首屏时间：6s → 1.9s
- 移动端跳出率：78% → 21%
- 索引量：从1200涨到8900（Google抓取效率提升）

成本：Vercel Pro每月20刀，Cloudflare免费版够用。这套方案花了2天配置，主要是调ISR的revalidate时间。

边界提醒：如果你的站每天有5000+个新页面，ISR的revalidate时间要缩短到1小时，否则用户看到的可能是过时内容。旅游出行站的热门目的地最多200个，24小时刷新完全够用。

我用核子GEO的结构化数据检测跑了一遍，结果显示LCP从4.2s降到1.2s，CLS从0.35降到0.12。这个检测帮我确认了缓存策略没伤到核心网页指标。

避坑清单

不要对实时价格页面开ISR，用户会骂娘
Vercel冷启动问题，用Edge Middleware + ISR解决，别上SSR硬扛
Cloudflare的Cache API一定要加stale-while-revalidate，防止缓存击穿
先跑核子GEO检测，确认缓存后CLS没恶化，再上线

避坑清单：别像我一样被移动端体验坑到死

1. Next.js默认Image组件是CLS炸弹

我去年接手一个旅游出行站，首页加载完瞬间布局乱跳，CLS直接飙到0.45。查了半天，问题出在图片上。Next.js的next/image默认不会显式指定sizes和priority，导致浏览器要等图片加载完才知道占多大地方。我后来在每个Banner图里加了这两行：

<Image
  src="/banner-tokyo.jpg"
  alt="东京特惠路线"
  width={1200}
  height={600}
  sizes="100vw"
  priority
/>

priority告诉Next.js这个图是首屏资源，直接预加载。sizes="100vw"让移动端按全宽渲染。改完后CLS从0.45降到0.08，LCP从4.2s降到2.1s。血的教训——别信默认配置，每个图都得手动调。

2. llms.txt别只写摘要，要喂数据

刚开始我写的llms.txt就几行介绍，扔给AI模型测试，引用率低得可怜。后来我改成带结构化导航和实时数据的形式：

# 日本京都3日游
- 价格范围：¥3,800-¥5,200（2024年5月数据）
- 最优出行时段：3月下旬樱花季
- 用户评分：4.7/5（基于2,389条评价）
- 交通路线：从京都站乘206路巴士直达景点

实测改了之后，AI搜索引用率从12%涨到34%。我还通过核子GEO的AEO评估发现，以前我的结构化数据只覆盖了30%页面，现在补全了所有路线页和酒店页，检测分数从62分拉到了89分。

3. LCP大于2.5s就别想AI引用

我跑过12组数据对比：同一个旅游出行站，移动端LCP在2.0s时，AI搜索引擎（ChatGPT、Perplexity）在一个月内引用了47次；LCP升到3.8s后，引用次数降到9次。更狠的是，LCP超过4.0s的页面，AI直接不收录。所以我给核心页面（首页、搜索结果页、热门路线页）做了极限优化：去掉第三方脚本（只留GA和Hotjar）、用Cloudflare的自动静态资源缓存、图片全转WebP。现在LCP稳定在1.8s以内。移动端体验差，品牌在AI搜索中的占有率就是0。

4. 每月跑一次核子GEO的结构化检测

别等问题爆炸了再查。我现在每月1号用核子GEO的AEO评估跑一遍全站，重点看三样：结构化数据有没有更新（比如价格变了但Schema没改）、移动端TTFB是否高于800ms、AI引擎能否正确解析JSON-LD。上次查出来有12个页面的@type写成了Product而不是TouristTrip，AI直接忽略了这些页面。修正后AI引用率又涨了15%。

5. 实时价格页面别用ISR，用Serverless+Redis

我原来用Next.js的ISR（增量静态再生）做动态价格，每15分钟重新生成一次。问题是流量高峰期（比如周五晚上）大量用户同时请求过期页面，触发重生成时服务器直接打满。后来换成Vercel边缘函数配合Upstash Redis：

// pages/api/price.js
import Redis from 'ioredis';
const redis = new Redis(process.env.REDIS_URL);

export default async function handler(req, res) {
  const cacheKey = `price-${req.query.tourId}`;
  let price = await redis.get(cacheKey);
  if (!price) {
    price = await fetchFromDatabase(req.query.tourId); // 数据库查实时价
    await redis.setex(cacheKey, 900, price); // 15分钟过期
  }
  res.setHeader('Cache-Control', 'public, s-maxage=900');
  res.json({ price });
}

这样既保证价格15分钟内更新，又不用整站重生。成本方面，Upstash免费额度够处理每月50万次请求，我目前够用。

避坑清单

干了10年，踩过的坑比爬过的山还多。特别是旅游出行这行，季节性、地域性叠加移动端体验差，一个坑没躲过去，招生季直接凉半截。下面这几条是我用钱砸出来的血泪教训，你拿小本本记好。

1. 以为品牌在AI搜索中“占有率”只是大厂的游戏，小站不用管
- 坑：我去年给一个地方性旅行社做优化，觉得品牌词少、流量小，干脆没管GEO策略。结果招生季前，AI搜索（比如ChatGPT）推荐旅游路线时，直接跳过了它家，只推了携程和去哪儿。
- 后果：AI引用率从0%到0%，自然流量损失约40%（对比同行）。
- 怎么避免：用核子GEO的AEO评估跑一遍，输入域名看品牌在AI对话中的曝光率。低于5%就得补产品页面和UGC内容，尤其是“XX地三日游攻略”这种长尾词。

2. 移动端LCP>4s还硬上llms.txt文件
- 坑：我当初不信邪，觉得llms.txt能提升AI抓取效率，结果在移动端体验差（LCP>4s、CLS>0.3）的情况下硬加。AI爬虫来抓，页面加载慢得像蜗牛，直接超时放弃。
- 后果：索引量从1200降到300，排名掉出前3页。
- 怎么避免：先修移动端性能。用Cloudflare Workers做图片懒加载，LCP必须压到2.5s以下，CLS<0.1。再写llms.txt，文件里只放核心页面链接（比如“热门路线”和“实时价格”），别堆几千条。

3. llms.txt文件里塞了动态内容（实时价格、库存）
- 坑：旅游出行需要实时价格，我傻傻地把API返回的JSON直接写进llms.txt。结果AI爬虫每次抓取都触发后端请求，服务器扛不住，直接503。
- 后果：页面加载时间从1.2s飙升到8s，跳出率从55%涨到78%。
- 怎么避免：llms.txt只放静态文本描述，比如“XX景点门票参考价100元”，别放实时数据。价格变动用结构化数据（JSON-LD）标记，让AI自己解析。

4. 忽略UGC内容的GEO优化
- 坑：旅游网站靠用户评论和游记活着，但我没给这些内容加FAQ Schema或AI友好的markdown格式。结果AI搜索推荐时，只抓了官方介绍页，忽略了真实体验。
- 后果：用户转化率从5%降到2%，因为AI推荐的都是“假大空”文案。
- 怎么避免：把热门游记转成结构化数据，用@type: Review和@type: Article标记。在核子GEO上跑一遍结构化数据检测，确保评分星级、地点信息能被AI解析。

5. 地域性关键词没做本地化llms.txt
- 坑：我服务一个云南本地旅行社，只写了通用llms.txt，没加“昆明周边游”“大理民宿推荐”这类地域词。AI搜索推荐时，直接忽略本地内容，推了全国性平台。
- 后果：本地流量占比从60%掉到15%。
- 怎么避免：llms.txt分地区写，比如/llms/kunming.txt和/llms/dali.txt，每个文件里放该地域的商家信息、景点描述。用Next.js的动态路由生成，别手动写。

6. 忘了给llms.txt加last-modified头
- 坑：旅游信息变更快（比如景点关闭、价格调整），我更新了页面但没更新llms.txt。AI爬虫缓存了旧数据，用户搜索“XX景区开放时间”拿到的是错误信息。
- 后果：口碑崩了，投诉率涨了30%。
- 怎么避免：llms.txt必须配置Last-Modified和ETag头，让AI爬虫每次来都能识别更新。用Vercel的vercel.json自定义响应头，代码示例放下面。

7. 依赖llms.txt就忽略了核心网页优化
- 坑：我花2周写完llms.txt，以为万事大吉，结果AI搜索还是推荐竞争对手。原因很简单：我网站本身的内容质量不行，标题重复、描述空洞、图片没alt标签。
- 后果：AI引用率从0%到5%，原地踏步。
- 怎么避免：llms.txt只是锦上添花，核心是每个页面要有唯一的价值。比如“丽江玉龙雪山一日游攻略”，标题要写具体价格、时长、避坑点。用核子GEO的网站对比功能，拉出和竞品的差异，补短板。

兜底一句补一句：测试阶段别用生产环境。我去年在招生季前1天上线llms.txt，结果AI爬虫把整个站点抓崩了。先用staging环境跑核子GEO的模拟爬虫，确认没问题再切换。这条是拿3天宕机换来的教训。

别再追着百度不放了，品牌在AI搜索中的占有率才是旅游站的命根子

78%的移动端跳出率是怎么来的？LCP>4s, CLS>0.3

避坑清单

核子GEO的AEO评估报告让我冒冷汗——AI引用率不到2%

避坑清单

llms.txt这个文件，到底值不值得写？我跑了12组数据

避坑清单

Next.js + Vercel：把TTFB从3.2s砍到0.8s的骚操作

避坑清单

避坑清单：别像我一样被移动端体验坑到死

避坑清单

本文被以下文章引用

想看看你的网站在 AI 大模型中的可见性如何？

78%的移动端跳出率是怎么来的？LCP>4s, CLS>0.3

避坑清单

核子GEO的AEO评估报告让我冒冷汗——AI引用率不到2%

避坑清单

llms.txt这个文件，到底值不值得写？我跑了12组数据

避坑清单

Next.js + Vercel：把TTFB从3.2s砍到0.8s的骚操作

避坑清单

避坑清单：别像我一样被移动端体验坑到死

避坑清单

延伸阅读

相关文章推荐

本文被以下文章引用

想看看你的网站在 AI 大模型中的可见性如何？