SEO best practice that survives tool claims

SEO best practice survives tool claims when it is tied to primary evidence, not to whatever a platform needs to sell this quarter. The safest baseline is still simple: make pages that are useful, crawlable, understandable and worth indexing, then measure what search engines and users actually do with them. That is much closer to Google’s published fundamentals than to most dramatic claims about secret fixes, AI shortcuts or “must-have” audits (Google SEO Starter Guide).

At The SEO Blog, we find that most confusion starts when three different things get mixed together. First, what Google and other platforms have explicitly documented. Second, what practitioners infer from experience. Third, what vendors package as certainty. Good SEO work uses all three carefully, but it does not pretend they are equal. If you want a practical way to assess claims before buying software or hiring help, this is the distinction to keep in view.

What counts as SEO best practice and what is only interpretation

A sensible definition of SEO best practice starts with primary-source guidance that remains broadly stable even as tools change. Google’s own starter documentation is a useful baseline because it covers fundamentals rather than trends: help people and search engines understand your content, use descriptive links, make the site accessible to crawling, and avoid deceptive or manipulative tactics (Google SEO Starter Guide). Google’s documentation on AI features says the same fundamentals still apply, and that there is no special AI schema or special AI text file required for eligibility in Google’s AI search features (Google AI features).

That is established guidance.

Interpretation starts where documentation stops. For example:

• “This title format tends to improve click-through rate” is interpretation.
• “A topic cluster model is the only way to rank now” is vendor opinion.
• “This schema type always boosts visibility” is usually an overclaim unless the page qualifies for a documented search feature.
• “Publishing with AI is fine if quality is high” is broadly consistent with Google’s people-first direction, but the exact workflow is still an editorial choice, not a guaranteed ranking method.

This matters because many SEO recommendations are not false, they are just less certain than they sound. A consultant may have seen a pattern across dozens of sites. A software platform may have built a useful heuristic. But neither should be mistaken for platform policy.

A practical check is to ask, “What kind of claim is this?”

• If it is about crawling, indexing, eligibility or controls, there may be platform documentation.
• If it is about likely outcomes, it is usually interpretation.
• If it is about revenue, rankings or citations being guaranteed, it has probably gone beyond the evidence.

That approach also helps with AI search. We see frequent confusion between “can be crawled”, “can appear in search”, “can be summarised”, “can be cited” and “can be used for training”. Those are different questions with different controls. If you want a broader primer, our AI search and visibility guide sets those distinctions out in one place.

Content quality versus content volume

A common pitch is that you need more pages. Sometimes you do. Often you need better pages first.

Google’s starter guidance puts the emphasis on useful, reliable, people-first content and on helping users navigate it with clear, descriptive links (Google SEO Starter Guide). That does not mean scale is irrelevant. A larger site can cover more topics, answer more intents and earn more entry points from search. But adding volume to weak foundations usually multiplies the problems already present.

Before assuming scale will help, check three things.

First, usefulness. Does the page answer the question clearly, with enough detail to be genuinely helpful? If you remove the heading and brand name, would a reader still know what the page is for, who it is for and what action to take next? Thin pages often exist because a keyword list demanded them, not because a user needed them.

Second, descriptive links. Google explicitly recommends writing link text that gives readers and search engines a sense of what they will get next (Google SEO Starter Guide). If your internal links say “read more”, “click here” or repeat the same vague phrase across dozens of pages, then publishing more pages may simply create more weak pathways. Better internal linking often improves discovery and navigation without adding a single new URL.

Third, duplication. Duplication is not only about copied text. It can be duplicated intent, duplicated product variants, near-identical location pages, or blog posts that all answer the same question with minor wording changes. If several pages compete for the same purpose, publishing more can make the site harder to understand.

In practice, we would usually compare:

• pages with impressions but low clicks, which may need clearer titles, stronger intent match or better snippets
• pages with no impressions at all, which may have indexing, internal linking or relevance issues
• pages with some traction on a topic, where expanding and improving the existing page is often more sensible than creating another one

This is why “publish three times a week” is not SEO best practice by itself. It is a production target. Sometimes the best next move is to consolidate two weak pages into one stronger page, improve headings, add missing evidence, and fix internal links. If you need a structured way to review that, our content and measurement guide is designed for exactly that sort of evidence-led check.

Technical fixes versus indexing reality

Technical SEO tasks are often useful. They are just not useful in the abstract.

It is easy to build a long list of fixes: canonicals, XML sitemaps, robots directives, redirects, status codes, JavaScript rendering, duplicate titles, pagination, hreflang, structured data, trailing slash consistency. But the real question is usually simpler: should this URL be indexed, and if so, what evidence shows that indexing is blocked or delayed?

Google’s Page indexing report guidance is valuable here because it makes the distinction explicit. An excluded URL is not automatically a problem. Some pages should not be indexed at all, such as duplicates, filtered combinations, admin pages or thin utility URLs (Google Page indexing report).

So instead of treating every exclusion as an error, we should ask:

• Is this URL meant to appear in search?
• Is it unique and useful enough to deserve indexing?
• Is it linked internally in a way that signals importance?
• What reason does Google Search Console give for exclusion?
• Is the reason expected, accidental or ambiguous?

For example, “Crawled - currently not indexed” is not solved by pressing a resubmission button repeatedly. It may mean Googlebot has seen the page and decided not to index it yet, often because the page does not appear sufficiently distinct or valuable. “Discovered - currently not indexed” may point more towards crawl prioritisation, internal linking or site quality patterns. “Duplicate without user-selected canonical” suggests Google has found competing versions and made its own choice.

This is where many technical audits become noisy. They list symptoms without deciding which URLs matter commercially or editorially. A site can have hundreds of technical warnings and still have only a handful that affect important pages. Equally, a site can look “clean” in a crawler but still fail because its key pages are not being indexed.

Google Search Console is the place to start because it shows what Google reports about actual URLs, not what a third-party crawler assumes. We have covered some of the strengths and limits of that evidence in our guide to Search Console evidence and limitations.

Speed, accessibility and user experience compared

Speed, accessibility and user experience are often lumped together, but they are not the same thing.

Core Web Vitals describe aspects of loading performance, responsiveness and visual stability (Core Web Vitals). They are useful because they focus attention on user experience at page level, not just on synthetic speed scores. But a Core Web Vitals score is not a guarantee of rankings or sales. It tells us something important about page experience, not everything important about commercial performance.

Accessibility guidance from W3C covers broader design practices such as sufficient colour contrast, clear focus states, understandable forms, readable text and predictable navigation (W3C accessibility design tips). These support real users directly, including people using keyboards, screen readers or magnification. In the UK, accessibility also has a practical compliance dimension for some organisations, especially in the public sector, so it should not be treated as a cosmetic extra.

Readable design and clear navigation often matter more to outcomes than tiny speed gains. A page that loads slightly faster but remains confusing, cluttered or hard to use is not a success. Equally, a visually elegant page that hides key information behind tabs, accordions or weak contrast may test well in a design review and still fail users.

The evidence-led position is this:

• Better speed can support a better user experience.
• Better accessibility can make content usable for more people.
• Clearer navigation can improve discovery, task completion and internal search pathways.
• None of those points lets us promise rankings, conversions or revenue uplift from one isolated change.

If someone claims that a new theme, a JavaScript reduction, or a green Lighthouse score will “unlock sales”, they are moving beyond what the evidence can support. We should improve these areas because they are good web practice and because poor execution can hold pages back. We should not turn them into magical levers.

Search visibility versus AI crawler controls

This is one of the most muddled areas in current SEO discussions.

Google Search access and Google’s AI-related controls are not the same thing. Google says its existing search fundamentals apply to AI features, and it does not require a special AI schema file or a special text file for inclusion (Google AI features). Access for Google Search is still fundamentally about crawlability, indexability and content quality as understood through Google’s normal systems.

Google-Extended is a separate control. It is not the same as allowing or blocking Googlebot for Search. A publisher can make choices here without confusing them with standard search crawling, and many people do confuse them.

The same separation matters for OpenAI crawlers. According to OpenAI’s crawler documentation, OAI-SearchBot and GPTBot serve different purposes, and search access and model-training controls are separate choices (OpenAI crawler documentation). That means:

• OAI-SearchBot relates to search discovery and retrieval for OpenAI search experiences.
• GPTBot relates to training controls.
• Allowing one does not automatically imply allowing the other.
• Blocking training does not automatically block search access.
• A crawl, a citation and a training use are different events.

That distinction matters if you are setting robots.txt rules or discussing AI visibility with stakeholders. We still see people say “we blocked GPTBot so we cannot appear in AI search” or “we allowed OAI-SearchBot so we must be in model training”. Those are category errors.

It also matters when interpreting outcomes. A bot visit is evidence of access. It is not evidence of citation. A citation is not evidence of traffic. And traffic is not evidence of commercial success. If AI search is part of your decision-making, our article on AI search citations and their limits goes into what can and cannot be inferred from those signals.

How to choose the next SEO task without buying hype

When budgets are limited, the best next SEO task is the one with the strongest evidence of being both important and fixable.

We use a simple decision framework.

First, business relevance. Which pages, topics or journeys matter to the organisation? Not every indexed URL deserves equal effort. A contact page, a key service page and a high-intent guide may matter more than dozens of low-value archive pages.

Second, search evidence. In Google Search Console, look at impressions, clicks, average position and page-level patterns over a meaningful period. We are not looking for vanity metrics. We are looking for signs such as:

• high impressions with low clicks, which may suggest snippet or intent issues
• low impressions on important pages, which may point to weak demand, weak relevance or indexing problems
• sudden changes, which need investigation before action
• query patterns that show users want something slightly different from what the page currently offers

Third, indexing evidence. Check the Page indexing report and inspect important URLs individually. Are key pages indexed? If not, what reason is given? Are excluded URLs intentionally excluded? Has Googlebot reached the pages you care about?

Fourth, user experience evidence. Review the page as a user would. Is the answer visible quickly? Is the design readable? Are calls to action clear? Does mobile use feel straightforward? If there is field data for Core Web Vitals, use it. If there are accessibility issues, fix obvious barriers. But do not prioritise lab-score perfection over obvious content and navigation problems.

Fifth, effort versus certainty. Some tasks are cheap and clear, such as fixing a broken internal link path to an important page. Some are large and uncertain, such as rebuilding the whole site because a tool said the theme is “not SEO friendly”. Prefer work where the problem is evidenced and the route to improvement is plausible.

A useful order of operations is often:

1. Confirm whether the right pages are indexable and indexed.
2. Improve pages that already show demand or partial traction.
3. Fix internal linking and navigation to support discovery.
4. Address obvious UX and accessibility barriers.
5. Use technical work to support those priorities, not to replace them.

If performance has changed and you are not sure why, start with diagnosis rather than remedies. Our guide on how to investigate a change in search performance is built for that situation.

The broader point is simple. SEO best practice is not a list of fashionable tasks. It is a way of making decisions under uncertainty, using platform guidance where it exists, using measurement where it is available, and refusing to confuse a vendor promise with a documented fact. That is the standard we try to keep at The SEO Blog, published by Fleeta Limited in Ipswich. Where practical services are needed, Suffolk Web, which shares the same owner, handles that side separately. Here, our job is to help readers assess the evidence before they buy into the claim.