Back to Details

identify-search-maintenance

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Identify Search Maintenance

识别搜索维护

Find pages that merit search-maintenance work, with evidence that separates rank-driven losses from changes in demand. The deliverable is a ranked investigation backlog and diagnosis; it is never an article rewrite or publishing task.
找出值得开展搜索维护工作的页面，并以证据区分排名导致的损失与需求变化。交付物是按优先级排列的调查待办清单和诊断结果；它绝不是文章改写或发布任务。

Scope and guardrails

范围与护栏

  • Confirm the property, traffic channel, dates, locale/device, and whether Google must be inspected through the user's signed-in Chrome session.
  • Use both recent comparison (normally the latest 3 months vs. the preceding 3 months) and a year-over-year comparison (normally the same recent 3 months one year earlier). End periods on the latest Search Console date that is complete enough to compare, use equal day counts and comparable weekday mix, and state any unavailable baseline as 
    N/A
    , never as zero.
  • Fix the Search Console search type, country, device, property scope, canonical-URL handling, and any brand-query exclusion across each comparison. Record GA4 timezone, Organic Search channel definition, and landing-page URL normalization.
  • Treat a page as a candidate only after checking page-level and query-level Search Console data. GA4 is corroborating traffic evidence, not a substitute for query and rank data.
  • Do not attribute a loss to rankings from clicks alone. URL-filtered and property-wide Search Console impressions are affected by the site's own visibility and are not standalone demand measures. Check an independent demand proxy (for example Google Trends for the query/topic, Keyword Planner where available, or a documented market-data source), then use property-wide query data only as corroboration. Also check URL/query rank changes, cannibalization, and live SERP composition.
  • Do not alter CMS content, metadata, internal links, or publish settings. If the user asks for changes, finish this investigation first and obtain a separate article-update scope.
  • 确认 property、流量渠道、日期、区域设置/设备，以及是否必须通过用户已登录的 Chrome 会话检查 Google。
  • 同时使用近期对比（通常为最近 3 个月与前 3 个月）和同比对比（通常为最近 3 个月与一年前的相同 3 个月）。以 Search Console 中足够完整、可用于比较的最新日期作为各周期的结束日期，使用相同天数和可比的星期构成；任何不可用的基线均标为 
    N/A
    ，绝不能标为零。
  • 统一每组对比中的 Search Console 搜索类型、国家/地区、设备、property 范围、canonical URL 处理方式以及品牌查询排除设置。记录 GA4 时区、Organic Search 渠道定义和落地页 URL 标准化方式。
  • 只有在检查了页面级和查询级 Search Console 数据后，才能将页面视为候选。GA4 只是佐证流量的证据，不能替代查询和排名数据。
  • 不能仅凭点击次数下降就把损失归因于排名。经过 URL 筛选和 property 级的 Search Console 展示次数都会受网站自身可见度影响，不能单独作为需求衡量指标。检查独立的需求代理数据源（例如，针对查询/主题的 Google Trends、可用的 Keyword Planner，或有据可查的市场数据来源），然后才能将 property 级查询数据作为佐证。同时检查 URL/查询排名变化、关键词蚕食和实时 SERP 构成。
  • 不得修改 CMS 内容、元数据、内部链接或发布设置。如果用户要求进行更改，请先完成本次调查，并另行取得文章更新的工作范围。

Workflow

工作流

1. Collect comparable evidence

1. 收集可比较的证据

  1. Export Search Console performance by page for the two period pairs. Prefer an export/CSV over manually paging a truncated table.
  2. Retain clicks, impressions, CTR, and average position for each period. Record filters, property, and export dates.
  3. Obtain GA4 organic-search landing-page sessions or views for the same dates when available. Note that GA4 and Search Console count different things.
  4. Normalize both the recent-pair and year-over-year page exports to the columns in selection-rubric.md. Run the bundled filter on each, take the union of the two candidate lists, and label the comparison(s) that surfaced each URL. A page that only passes one comparison still needs the full evidence checks in both.
powershell
python "<skill-directory>/scripts/select_rank_led_candidates.py" normalized-pages.csv --format markdown
Replace 
<skill-directory>
with the directory containing this 
SKILL.md
. Use the script to screen candidates, not to make the final decision. Tune its thresholds only if the report explains why.
  1. 针对两组周期组合，按页面导出 Search Console 表现数据。优先使用导出/CSV，避免手动翻阅被截断的表格。
  2. 保留每个周期的 clicks、impressions、CTR 和 average position。记录筛选条件、property 和导出日期。
  3. 在可用时，获取相同日期范围内 GA4 中 Organic Search 落地页的 sessions 或 views。注意，GA4 与 Search Console 的统计口径不同。
  4. 将近期周期组合和同比周期组合的页面导出数据都规范化为 selection-rubric.md 中指定的列。对每份数据运行自带筛选器，合并两个候选清单，并标注每个 URL 是由哪一项（或哪些）对比发现的。即使某个页面仅通过了一项对比，仍需在两项对比中完成全部证据检查。
powershell
python "<skill-directory>/scripts/select_rank_led_candidates.py" normalized-pages.csv --format markdown
将 
<skill-directory>
替换为包含此 
SKILL.md
的目录。使用该脚本筛选候选页面，而不是直接作出最终决定。只有在报告中说明原因时，才能调整其阈值。

2. Separate causes before selecting pages

2. 选择页面前先区分原因

Classify each materially declining page into one of these mutually exclusive buckets:
BucketEvidenceAction
Rank-led maintenance candidateClicks materially down; impressions broadly stable; average position/query ranks worsenInvestigate and prioritize
Demand/obsolescence declineImpressions and clicks fall together, or the task/query has endedExclude from the rank-led list
CTR/SERP changePosition broadly stable but CTR falls; SERP features or title/snippet changes explain itKeep separate; do not call it rank-led
Technical/indexing issueIndexing, canonical, rendering, or availability evidenceEscalate separately
Cannibalization/internal competitionAnother site URL gained the same query or intentExclude from this content-maintenance list; route for consolidation/targeting decision
Insufficient evidenceLow volume or no comparable baselineDo not force into the top 10
For every selected URL, verify at least three previously valuable declined queries. For each query, collect three views with identical search type/country/device/date filters: (a) the target URL's query metrics and position, (b) the whole property query metrics without a page filter, and (c) an independent demand proxy. Treat (c) as the demand evidence; use (b) only to understand the site's overall visibility. Use year-over-year data to catch longer-running changes. Check whether another URL in the property gained the same query; classify confirmed cannibalization in its own exclusion bucket. If the query mix changed, say so.
Before retaining a content-maintenance candidate, perform a minimum health check: URL Inspection/index status, user-selected canonical, HTTP availability, and rendered-page accessibility. Classify a failing page as a technical/indexing issue instead of diagnosing an editorial gap.
将每个出现实质性下降的页面归入以下互斥分类之一：
分类证据处理方式
排名主导的维护候选页面点击次数显著下降；展示次数大体稳定；average position/查询排名恶化调查并确定优先级
需求下降/内容过时展示次数与点击次数同步下降，或任务/查询已经结束从排名主导清单中排除
CTR/SERP 变化排名大体稳定但 CTR 下降；SERP 特征或标题/摘要变化可以解释这一情况单独保留；不要归为排名主导
技术/索引问题存在索引、canonical、渲染或可访问性方面的证据单独升级处理
关键词蚕食/内部竞争网站中的另一个 URL 获得了相同查询或搜索意图从内容维护清单中排除；转交进行整合/定向决策
证据不足流量低或没有可比较的基线不要强行纳入前 10
对于每个入选 URL，至少验证 3 个此前有价值但出现下降的查询。对于每个查询，使用完全相同的搜索类型、国家/地区、设备和日期筛选条件收集三种视图：(a) 目标 URL 的查询指标和排名；(b) 未使用页面筛选器时整个 property 的查询指标；(c) 独立需求代理数据源。将 (c) 视为需求证据；仅使用 (b) 了解网站的整体可见度。使用同比数据发现长期变化。检查 property 中是否有另一个 URL 获得了相同查询；确认存在关键词蚕食时，将其归入对应的排除分类。如果查询组合发生变化，请明确说明。
在保留内容维护候选页面前，执行最低限度的健康检查：URL Inspection/索引状态、用户选择的 canonical、HTTP 可用性以及渲染页面的可访问性。检查失败的页面应归类为技术/索引问题，而不是诊断为编辑内容缺口。

3. Diagnose each selected page in Google

3. 在 Google 中诊断每个入选页面

When the user specifies Chrome or Google, use the Chrome browser, not a general web-search backend. For each selected URL:
  1. Search at least three declined, historically valuable queries in Google, using the required locale/device context where possible.
  2. Capture the target URL's visible rank or absence, the top competing URLs, and material SERP features (AI Overview, official result, video carousel, PAA, news, forums, etc.). Use fresh tabs and do not change account or site settings.
  3. Compare the target and the leading pages on search intent, freshness, direct answer quality, task completion, factual completeness, first-party evidence, visual/media support, structure, and trust signals. Base observations on actual page content; distinguish observed facts from inference.
  4. Identify the gap to investigate, not the edit itself. Examples: outdated UI steps, missing current constraints, poor intent match, weak original evidence, or a SERP now dominated by official sources.
If parallel agents are available, assign no more than two pages to each agent. Require each agent to return the period metrics, three or more queries, Google competitors, SERP features, observed content gaps, exclusions, and source URLs. Consolidate only after all agents return evidence.
当用户指定 Chrome 或 Google 时，使用 Chrome 浏览器，而不是通用网络搜索后端。对于每个入选 URL：
  1. 在 Google 中搜索至少 3 个已下降且过去有价值的查询；尽可能使用所需的区域设置/设备环境。
  2. 记录目标 URL 的可见排名或未出现情况、排名靠前的竞争 URL，以及重要的 SERP 特征（AI Overview、官方结果、视频轮播、PAA、新闻、论坛等）。使用新标签页，且不要更改账户或网站设置。
  3. 从搜索意图、新鲜度、直接答案质量、任务完成度、事实完整性、第一方证据、视觉/媒体支持、结构和信任信号等方面比较目标页面与领先页面。以实际页面内容为依据进行观察；区分观察到的事实与推断。
  4. 确定需要调查的差距，而不是具体编辑操作。例如，过时的 UI 操作步骤、缺失当前约束、搜索意图匹配不佳、原始证据薄弱，或 SERP 现在由官方来源主导。
如果可以使用并行 Agent，则每个 Agent 最多分配两个页面。要求每个 Agent 返回周期指标、至少 3 个查询、Google 竞争页面、SERP 特征、观察到的内容差距、排除项和来源 URL。仅在所有 Agent 返回证据后进行汇总。

4. Produce the maintenance report

4. 生成维护报告

Create or append to 
report.md
; preserve earlier findings unless the user asks to replace them. Use this structure:
  1. Scope, dates, data sources, filters, and limitations.
  2. Selection method and explicit rank-led thresholds.
  3. A prioritized table of up to the requested number of rank-led pages (default 10): URL, recent metrics, year-over-year metrics, property-wide query-demand evidence, ranking evidence, priority, and confidence. If fewer pages meet the evidence threshold, report fewer and explain the shortfall.
  4. Per-page diagnosis: three or more declined queries, current Google competitors/SERP observations, and content gaps to investigate.
  5. Excluded near-misses with the evidence for demand decline, obsolete intent, CTR-only loss, technical issue, cannibalization, or insufficient data.
  6. A separate follow-up queue for work that needs a technical or editorial decision.
Before delivery, verify that every page in the final rank-led list has stable-enough independent demand evidence, a documented query-level rank deterioration, and a passing health check. Never fill a quota with demand-led losses.
创建或追加到 
report.md
；除非用户要求替换，否则保留之前的发现。使用以下结构：
  1. 范围、日期、数据源、筛选条件和限制。
  2. 选择方法和明确的排名主导阈值。
  3. 一张按优先级排列的表格，最多包含用户要求的页面数量（默认 10）：URL、近期指标、同比指标、property 级查询需求证据、排名证据、优先级和置信度。如果达到证据阈值的页面不足，则只报告实际数量并说明不足原因。
  4. 逐页诊断：至少 3 个下降的查询、当前 Google 竞争页面/SERP 观察结果，以及需要调查的内容差距。
  5. 被排除的临界页面，并附上需求下降、过时意图、仅 CTR 损失、技术问题、关键词蚕食或数据不足的证据。
  6. 单独列出需要技术或编辑决策的后续工作队列。
交付前，验证最终排名主导清单中的每个页面都具有足够稳定的独立需求证据、有据可查的查询级排名恶化，并且健康检查通过。绝不能用需求主导的损失凑足名额。

Resources

资源

  • selection-rubric.md: normalization schema, default thresholds, and report checklist.
  • scripts/select_rank_led_candidates.py
    : deterministic first-pass filter for normalized Search Console page exports.
  • selection-rubric.md：标准化 schema、默认阈值和报告检查清单。
  • scripts/select_rank_led_candidates.py
    ：用于标准化 Search Console 页面导出数据的确定性首轮筛选器。