Google uses many ranking systems, factors, and signals, but it does not publish a complete fixed inventory of SEO ranking factors or an official table of their weights. A useful SEO program therefore starts with documented guidance and an observed page problem, not a checklist that labels hundreds of debated signals as confirmed.
If clicks fall while average position appears stable, do not assume that a ranking factor changed. Compare the queries, devices, countries, and search appearances behind the totals. Then check whether the page still serves its intended audience and whether Google can access the relevant content on mobile.
This guide separates documented Google systems from operational recommendations, practitioner hypotheses, and unsupported precision. It also provides an editorial workflow, a careful Search Console measurement model, and a separate architecture for observing AI answers. The implementation patterns are proposed designs, not Google-provided integrations.
SEO ranking factors: what Google confirms
Google’s ranking systems guide describes notable systems, including link analysis, PageRank, freshness systems, and spam systems. It is not a complete recipe. Google says its systems primarily evaluate pages while also using some site-wide signals and classifiers. PageRank and link analysis remain part of the documented picture, but that does not confirm every detailed backlink claim found in industry lists.
Use this evidence ladder before assigning work:
- Documented system or policy: Google explicitly describes it, such as link analysis, freshness systems, mobile-first indexing guidance, or scaled content abuse.
- Guidance-based action: Google recommends it to help users or Search, such as keeping primary content available on mobile.
- Practitioner hypothesis: A plausible industry claim that is not confirmed by the cited Google guidance, such as a particular engagement metric directly affecting rankings.
- Unsupported precision: An exact universal score, weight, word count, backlink number, or promised result without reliable evidence.
Helpful, reliable, people-first content is an important quality principle, but Google does not identify one universal top ranking factor. E-E-A-T describes qualities that Google wants its systems to identify. Google does not describe E-E-A-T itself as a standalone ranking factor. The questions in its people-first content guidance are review prompts, not a ranking formula.
A practitioner checklist is not a Google specification. Label the evidence behind a claim before assigning work, and never present an editorial priority as Google’s weighting.
Prioritize relevance, access, and usability
Start with the actual page and query, not a generic factor inventory. Identify the failure you can observe, choose a change that addresses it, and state the expected user or search outcome. Do not begin with a universal word-count target, keyword-density rule, or assumption that one signal outweighs all others.
1. Check query fit and content quality
Compare the page with the audience and query it is meant to serve. Review intent, accuracy, originality, completeness, clarity, and whether the page adds useful information or experience. A byline can help readers understand accountability, especially on sensitive topics, but a byline or author schema should not be presented as a direct ranking boost or universal requirement.
Internal links can help users and crawlers discover related content and clarify relationships between pages. Use them where they genuinely support navigation and understanding. Do not claim that a particular internal-link pattern guarantees a ranking improvement or that it signals engagement.
2. Confirm access and mobile equivalence
Review crawl and index status, canonical choice, internal discovery, and whether the intended page is available to Google. Google’s mobile-first indexing guidance says Google uses the mobile version for indexing and ranking. Mobile and desktop versions should expose equivalent primary content, metadata, and structured data. This does not mean that every mobile design choice creates a separate ranking penalty.
3. Fix material usability problems
Google’s page experience guidance covers Core Web Vitals, secure delivery, mobile presentation, intrusive interstitials, excessive ads, and distinguishable main content. Treat these as ways to find and fix user problems. Google says there is no single page-experience signal, and good Core Web Vitals do not guarantee a top position.
4. Use freshness, structured data, and links in context
Use freshness when a query reasonably calls for current information. Make substantive updates when facts or recommendations change rather than changing a date alone. Google documents link analysis, but not every claimed link sub-signal, dofollow ratio, sitewide-link treatment, or link weight. Prioritize relevant editorial references and avoid manipulative link schemes.
Use structured data to describe visible page content and meet feature requirements. Valid markup may make a page eligible for a rich result, but it does not guarantee display or an ordinary ranking improvement. Follow Google’s structured data policies.
AI-assisted writing is not categorically prohibited. Google’s spam policies address scaled content abuse: producing content at scale primarily to manipulate Search when it offers little or no value. The policy applies whether material is produced by AI, people, or both.
Choose the intervention from the observed failure. A page with poor query fit needs a content decision; a page that cannot be indexed needs an access decision; a slow page needs a user-impact diagnosis. The evidence tier explains confidence in the recommendation, but the page problem determines the work.
Turn content review into a bounded editorial workflow
AI can help an editor inspect a draft, but it should not decide whether a page will rank, invent evidence, or publish changes. Start with an intended audience, search intent, approved sources, and the draft. Limit the model’s task to identifying apparent unanswered questions, grouping claims that need source checks, or suggesting clarity edits.
For example, an editor reviewing a Search Console guide could supply its URL, audience, draft, and approved API documentation. The model might flag a statement about data completeness for verification. The editor checks the statement against the source, asks a subject-matter owner to resolve a factual dispute, and then approves or rejects the edit. The draft and review notes remain in the editorial record, while publication remains a human decision. Teams formalizing bounded AI agent workflows should preserve that approval gate.
A proposed review record could contain page_url, unanswered_questions, claims_for_review, approved_source_url, and editor_decision. Reject a cited URL outside the approved source set before a person spends time reviewing it. This allowed-value check is deterministic, not an AI classification task.
Measure Google Search changes without overstating the data
Search Console reports clicks, impressions, click-through rate, and average position. Its reporting dimensions include page, query, country, device, date, and search appearance. The Search Analytics API returns aggregates for the dimensions requested, not a log of individual impressions. Google documents row limits and other data constraints. Detailed page-and-query results may omit rows, and recent data can be incomplete. A missing detailed row is not automatically zero.
For a defined investigation, authorize the API for a verified property, select the date range and search type, then request only the dimensions needed to answer the question. Preserve the raw response and request parameters before normalizing rows. Keep property totals separate from page-and-query detail because those aggregations are not interchangeable.
If a page’s average position is stable but clicks change, compare query mix, device, country, and search appearance before proposing a cause. A change in the queries contributing to the average or in the result layout can change clicks without proving that a particular ranking signal changed.
{
"property_id": "sc-domain:example.com",
"date_start": "2026-09-01",
"date_end": "2026-09-30",
"search_type": "web",
"dimensions": [
"page",
"query",
"device",
"country"
],
"data_state": "complete, incomplete, or unknown",
"retrieved_at": "illustrative timestamp",
"aggregation_type": "label the requested aggregation"
}This is an illustrative reporting contract, not a ready-made connector. A reporting store should retain the property, date range, search type, dimensions, aggregation semantics, data state, retrieval timestamp, and raw response. An analyst owns interpretation. If authorization, quota, schema, or partial-data checks fail, resolve those issues before reporting a trend.
- Confirm the authorized property and requested date range.
- Record search type and every requested dimension.
- Label whether results are property-level or grouped detail.
- Check incomplete-data status and mark recent results provisional when needed.
- Preserve the raw response and retrieval timestamp.
- Validate dates, HTTPS URLs, canonical URL equality, and CTR calculations with deterministic checks.
Track AI answers separately from Google rankings
Google says AI Overviews and AI Mode use core quality and ranking systems alongside AI-specific approaches. Its product description of AI Mode discusses query fan-out and links to web content. This does not disclose a complete citation-selection formula. Search Console is not a comprehensive report of citations across AI products, and Google’s statements should not be applied to ChatGPT or other answer engines.
If a team manually observes an answer, or uses a separately verified collection method, treat each prompt run as one observation. Store individual citations separately because one response can cite several URLs. Store period-level visibility summaries in a third aggregate record. These grains answer different questions and must not share a key such as date plus domain.
- Prompt-run record: one request and observed response, identified by a unique run ID. Include engine, product surface, model or variant when known, prompt version or hash, locale, device, timestamp, and evidence location.
- Citation record: one cited URL in one run. Link it to the run ID and store citation position, resolved URL, entity-match status, and validation evidence.
- Aggregate record: a defined period, engine, market, prompt-set version, and entity or domain, with run counts and share-of-runs measures. It is a report grain, not a prompt-run row.
Validate whether a cited URL resolves and whether the response actually refers to the intended brand. If collection can run concurrently or replay the same job, enforce a database uniqueness constraint and use a transactional upsert. A read-then-insert check can race. Send ambiguous entity matches or consequential classifications to a human reviewer.
A proposed observation design might use prompt_run_id for the prompt-run row, a separate citation_id linked to that run, and an aggregate key composed of period, engine, product surface, prompt-set version, market, and entity or domain. Do not use the same identifier for raw observations and reported summaries. Only after verification might selected observations be routed to appropriate CRM systems. A CRM contact or deal event is a separate destination record, not a substitute for the raw observation or citation evidence.
A practical prioritization sequence
When capacity is limited, work down this sequence and record one principal outcome for each change:
- Confirm access: Check whether Google can crawl and index the intended URL, whether its canonical is correct, and whether primary content is available on mobile. Outcome: resolve a specific access or indexing problem.
- Check query fit: Compare the page with the audience and query it is meant to serve. Outcome: answer an identified question more accurately or usefully.
- Improve substance: Add original analysis, correct outdated information, or remove unsupported material. Outcome: address a documented content gap, not an arbitrary word count.
- Fix material usability issues: Prioritize mobile presentation, Core Web Vitals, secure delivery, or intrusive elements according to user impact. Outcome: resolve a defined friction point.
- Improve discovery and authority: Strengthen relevant internal links and earn appropriate editorial references without manipulative link schemes. Outcome: improve discovery or support a useful resource.
- Measure against a baseline: Define property, dates, search type, dimensions, aggregation, and data state before evaluating the result. Outcome: determine whether the intended measure changed, then investigate rather than claiming causation from correlation alone.
A simple backlog can hold page_url, observed_issue, evidence_tier, proposed_change, owner, baseline_window, success_measure, and review_date. If the result does not support the original diagnosis, revise or stop the work instead of turning one observation into a new universal ranking rule.
Use evidence without turning it into a checklist
Google does not publish a confirmed list of more than 200 factors, official importance labels, or a universal word count. Domain Authority is a third-party metric, not a Google score. Bounce rate, dwell time, bookmarks, comments, direct traffic, repeat visits, and pogo-sticking may be useful business or UX diagnostics, but the reviewed Google sources do not establish them as confirmed direct ranking factors.
Likewise, do not treat the 2024 Google documentation leak as proof of current ranking weights. Do not describe HTTPS, Core Web Vitals, author schema, structured data, backlinks, featured snippets, or AI citations as guaranteed sources of ranking or traffic gains. Their practical value depends on context, implementation, query, platform, and measurement.
The useful question is not which item sits highest on an unofficial list. It is which documented or clearly labeled intervention best addresses the page’s observed problem, and what evidence will show whether that problem changed.