Nafil Shareef — SEO Expert, Google & Bing Search Researcher
Nafil Shareef • SEO expert • Google & Bing search research

I study how search engines work and publish what I find.

NafilShareef.com is my public SEO research library and living search-engine bible. I document how Google and Bing discover, crawl, render, canonicalise, index, retrieve, rank and present information so students, entrepreneurs and marketers can understand Search beyond surface-level tactics.

I am Nafil Shareef, an SEO expert and search researcher. I learn deeply, read documentation and patents, analyse real websites, test hypotheses, record outcomes and turn what survives the evidence into practical SEO knowledge.

Technical SEOGoogle algorithmsCrawl engineeringIndexationInformation retrievalGoogle patentsBing & IndexNowSearch experiments
Nafil Shareef, SEO expert and Google and Bing search researcher
SEO expert · Google & Bing search researcher

Nafil Shareef

I investigate how Search behaves, why websites gain or lose visibility, and which explanations survive documentation, data and controlled testing.

+91 90374 23769 Google · Bing · technical SEO
SEARCHdiscover • retrieve • rank
EligibilityCrawlCan the engine discover and fetch the resource?
RepresentationIndexWhich URL and content representation enters the index?
SelectionRankWhich candidate best satisfies the query and context?
PresentationSERPWhich result types and features serve the searcher?
Why NafilShareef.com exists

To make deep search-engine knowledge easier to study, question and apply.

This website is where I organise what I learn from Google and Microsoft documentation, patents, information-retrieval concepts, crawl data, Search Console, server logs, rendered-page analysis and real SEO experiments.

It is not a list of shortcuts or a fixed “ranking-factor formula.” It is an evidence-labelled learning system that separates what search engines confirm, what can be repeatedly observed, what patents merely suggest and what still remains uncertain.

Research principle: this library separates official documentation, repeatable field observations, patent-derived hypotheses and diagnostic mental models. It does not present patents or correlation studies as confirmed ranking factors.
01

For students

Build strong foundations in crawling, rendering, indexing, query understanding, link graphs, ranking systems, structured data and technical diagnostics.

02

For entrepreneurs

Understand what search engines can access, how website decisions affect visibility, and how to evaluate SEO recommendations with better questions.

03

For marketers

Go beyond keyword checklists by connecting search demand with architecture, content quality, crawl behaviour, index selection, measurement and experiments.

SERP investigation desk

Found something strange in Google or Bing?

Send me the evidence—not only the conclusion. The form builds a structured WhatsApp message so I can understand the query, affected URL, date window, observed change and possible confounding factors.

  • A page disappeared, changed canonical or stopped being indexed.
  • Rankings moved without an obvious website change.
  • Google and Bing show very different results for the same query.
  • A local pack, Maps result, AI answer or rich result changed unexpectedly.
  • You found a patent, crawler behaviour or SERP feature worth analysing.
Connect on LinkedIn

Please remove passwords, private customer information and confidential analytics before sending. A message starts a research discussion; it does not guarantee that every case can be fully diagnosed.

Search every chapter
Confirmed: official documentationObserved: repeatable field evidencePatent hypothesis: possible mechanismMental model: diagnostic framework
01Search system architecture
How search engines work

Search is a pipeline of decisions—not a single algorithm.

A useful SEO diagnosis follows the same route as the document: discovery, scheduling, fetching, rendering, extraction, consolidation, indexing, retrieval, ranking and result composition.

01

Discover

A URL becomes known through crawlable links, sitemaps, feeds, prior crawls, redirects, submissions and external references.

02

Schedule

The crawler decides whether, when and how often to fetch the URL based on demand, capacity, change expectations and known importance.

03

Fetch

DNS, TLS, robots rules, HTTP status, response headers, content type and server reliability determine what the bot can retrieve.

04

Render

HTML is parsed, resources are requested and JavaScript may be executed so the system can inspect the rendered document.

05

Extract

Text, links, media, metadata, structured data, language, entities and document relationships are extracted.

06

Canonicalise

Duplicate and near-duplicate URLs are clustered; one representative URL may be selected as canonical.

07

Index

Eligible information is transformed into searchable representations and stored in retrieval structures.

08

Understand query

Spelling, language, location, freshness, entities, intent and concepts influence how the query is interpreted.

09

Retrieve and rank

Candidate documents are retrieved, scored and re-ranked through multiple systems and constraints.

10

Compose results

The engine chooses result types, snippets, rich features, local/image/video elements and AI-assisted experiences.

02URL discovery
How URLs enter the known web

Before a page can rank, the engine must know that the URL exists.

Discovery is an inventory problem. Search engines learn addresses from links, sitemaps, redirects, prior crawls and submission systems, then decide whether the URL deserves a fetch.

URL sourceConfirmed

Crawlable internal links

A normal HTML anchor with an href is the most dependable discovery path. Links also communicate context, hierarchy and relative importance. Pages with no crawlable path are operationally orphaned even when they exist in a CMS.

URL sourceConfirmed

XML sitemaps

Sitemaps advertise canonical URLs and modification information. They improve discovery and monitoring, but they do not guarantee crawling, indexing or ranking. Keep only clean, indexable, canonical 200-status URLs.

URL sourceConfirmed

External links and references

Links from other sites can reveal URLs and contribute context and link analysis signals. Discovery and ranking value are separate questions: a URL can be discovered through a weak link without receiving meaningful authority.

URL sourceConfirmed

Redirect targets

When a crawler follows a redirect, the destination becomes a known URL. Permanent redirects are stronger canonical signals than temporary redirects, but long chains waste time and increase failure risk.

BingConfirmed

IndexNow notifications

IndexNow lets participating engines know that a URL was added, updated or deleted. A successful response confirms receipt, not inclusion. It complements links and sitemaps; it does not replace quality or index eligibility.

ArchitectureObserved

Navigation and hub pages

Category, topic, brand, location and index pages create durable discovery paths. Good hubs reduce click depth, explain relationships and make large inventories legible to users and crawlers.

What belongs in an XML sitemap?Confirmed

Only URLs you prefer as canonical and want indexed. Exclude redirects, errors, blocked URLs, noindex pages, parameter duplicates and alternate URLs that point elsewhere with canonical tags. Separate sitemaps by template or business area when that improves diagnosis.

Sitemap limits and segmentationConfirmed

A single sitemap is limited to 50,000 URLs or 50 MB uncompressed. Larger sites use sitemap index files. Segmenting by page type, market or freshness allows indexation and crawl patterns to be compared more precisely.

lastmod: useful only when truthfulConfirmed

Use lastmod when the primary content changed materially. Updating every timestamp on every deployment destroys the signal. A date change should correspond to a meaningful document change, not a header, tracking script or footer edit.

Feeds, APIs and CMS records are not crawl pathsConfirmed

A record in a database or a URL visible only inside an admin panel is not automatically discoverable. Search engines need a public URL source such as a link, sitemap, submission mechanism or previously known address.

Fragments are not separate documentsConfirmed

Hash fragments normally identify a location or client-side state within a URL; they are not a dependable way to create independently indexable pages. Use real URLs and the History API for distinct content states.

Orphan-page testObserved

Start from the homepage and crawl only standard links. Any important indexable URL absent from that graph needs a deliberate internal link. Sitemap-only discovery may work, but it leaves hierarchy and context weak.

03Crawl engineering
Scheduling, capacity and waste

Crawling is resource allocation across an almost infinite URL space.

The practical goal is not to make bots request everything. It is to help them spend time on valuable canonical pages while protecting the server and closing wasteful URL paths.

CapacityConfirmed

Crawl capacity limit

Search engines attempt to avoid overloading a host. Response time, connection failures, 429 responses and 5xx errors can reduce crawling. Healthy, consistent serving makes more efficient crawling possible.

DemandConfirmed

Crawl demand

Known importance, expected change, staleness, duplicate patterns and overall usefulness influence demand. Search engines do not need to refetch every known URL at the same frequency.

Large sitesConfirmed

Crawl budget is an advanced concern

Google frames crawl-budget work mainly for very large or rapidly changing sites, or sites with many discovered-but-not-indexed URLs. Most smaller sites gain more from clean architecture and accurate sitemaps.

ServerConfirmed

HTTP caching and 304

ETag and Last-Modified can help a crawler validate whether a resource changed. A 304 response communicates that the existing representation is still current and avoids resending the full body.

WasteObserved

Infinite URL spaces

Facets, calendars, internal searches, session IDs and arbitrary parameter combinations can create effectively endless crawl paths. Control generation, linking and index eligibility before the crawler learns millions of low-value variants.

LogsObserved

Server-log evidence

Logs reveal which bots request which URLs, response codes, bytes, timing and frequency. They show crawler behaviour directly, but not why a ranking system chose a page or whether every fetch entered the index.

Conceptual crawl-priority modelMental model

A useful mental model is: crawl priority rises with known importance, expected change and retrieval value, and falls with duplication, low demand and serving cost. This is not Google’s formula; it is an engineering framework for diagnosing crawl allocation.

429 and 5xx responsesConfirmed

Google treats 429 and server errors as overload signals and reduces crawling. Persistent errors can eventually remove already indexed URLs. Use 503 for genuine temporary outages, with Retry-After when appropriate, and avoid returning 200 for broken pages.

404 versus 410Confirmed

Both indicate that a resource is unavailable and can lead to removal. A 410 is more explicit, but architecture, links and continued references still matter. Do not redirect every removed URL to the homepage; that can become a soft 404.

Redirect chains and loopsConfirmed

Googlebot can follow multiple hops, but every hop adds latency and a failure point. Update internal links and sitemaps to the final destination, and keep migrations as close to one hop as possible.

Crawl traps from faceted navigationObserved

Prevent links from generating combinations that have no search or user value. Normalize parameter order, cap combinations, avoid crawlable empty results, and decide which facet intersections deserve stable indexable landing pages.

Crawl-rate mythsConfirmed

More crawling does not automatically produce better rankings. A crawler can fetch low-value duplicates repeatedly. The goal is not maximum requests; it is efficient discovery and refresh of useful canonical pages.

04Crawl and index controls
Robots, directives and canonical signals

Every control answers a different question.

robots.txt controls access. noindex controls index eligibility. canonical signals select representatives. Redirects move users and crawlers. Preview directives control how much may be shown.

robots.txtConfirmed

Crawl control, not secrecy

robots.txt controls crawler access. A disallowed URL can still be known and may appear without a snippet if other pages link to it. Sensitive content needs authentication or access control.

Meta robotsConfirmed

noindex requires crawling

A crawler must fetch the page to see a noindex tag or X-Robots-Tag. Blocking the URL in robots.txt can prevent the engine from seeing the noindex instruction.

CanonicalConfirmed

Canonical is a preference signal

Redirects and rel=canonical are strong signals; sitemap inclusion is weaker. Signals can be combined, but the engine can select a different canonical when evidence conflicts.

LinksConfirmed

nofollow, sponsored and ugc

Qualify paid links with sponsored, user-created links with ugc, and untrusted links with nofollow when appropriate. These attributes do not make the destination undiscoverable through other sources.

SnippetsConfirmed

nosnippet and max-snippet

Preview controls influence how much page content can appear in search snippets and AI features. They do not replace noindex and they do not guarantee a particular result layout.

SecurityConfirmed

Authentication beats indexing directives

Robots and meta directives are voluntary search controls, not security boundaries. Private dashboards, customer data and staging systems should require authentication and avoid public links.

Minimal robots.txt exampleConfirmed

Use the smallest rule set that achieves the goal. Blocking CSS or JavaScript can prevent accurate rendering. A sitemap declaration can be included at the end.

User-agent: *
Disallow: /internal-search/
Disallow: /cart/

Sitemap: https://example.com/sitemap.xml
Meta robots and X-Robots-TagConfirmed

HTML pages can use a meta tag; PDFs and other files can use the X-Robots-Tag response header. Bot-specific directives can target googlebot or bingbot, but broad robots directives are easier to maintain unless a real difference is required.

<meta name="robots" content="index,follow,max-image-preview:large">

X-Robots-Tag: noindex, noarchive
Canonical signal orderConfirmed

A practical hierarchy is permanent redirect, rel=canonical and then sitemap inclusion. Internal links to the preferred URL and consistent hreflang reinforce the cluster. Conflicting signals make selection less predictable.

Self-referencing canonicalsConfirmed

A canonical page can point to itself. This makes the preferred absolute URL explicit and reduces accidental ambiguity from parameters, protocol variants or copied templates.

robots.txt status-code edge casesConfirmed

A successful response is parsed. Redirects are followed only to a limit. Many 4xx responses are treated as no robots file, while server errors can temporarily cause conservative crawling behaviour. Monitor the actual robots response.

Do not use robots.txt for canonicalisationConfirmed

Disallowing duplicates hides their content and canonical hints from the crawler. Consolidate with redirects or canonical annotations, and limit crawl generation at the source when possible.

05Rendering and JavaScript SEO
From response HTML to interpreted document

JavaScript is not invisible—but dependence creates more failure modes.

Rendering can reveal content that is absent from the initial response, yet crawlers still need stable URLs, accessible resources, meaningful status codes and a document that survives script or API failure.

RenderingObserved

HTML first is the safest baseline

Important text, links, titles, canonicals and directives are most robust when present in the initial response. Server rendering and static generation reduce dependence on later JavaScript execution.

GooglebotConfirmed

Modern Chrome rendering

Google renders JavaScript with a recent Chrome version, but rendering still consumes resources and can fail when scripts, APIs or assets are blocked, slow or error-prone.

ArchitectureObserved

SSR, SSG and hydration

Server-side rendering and static generation provide complete initial HTML. Hydration can add interactivity without making discovery and content extraction depend entirely on client execution.

SPAConfirmed

Unique URLs and real status codes

Client-side applications need stable URLs, crawlable href links, meaningful server responses and error routes that return 404 or noindex instead of a universal 200 shell.

ResourcesConfirmed

Do not block critical assets

Blocked CSS, JavaScript, images or API calls may prevent the crawler from understanding layout and content. Test rendered HTML and screenshots, not only source HTML.

FallbackConfirmed

Dynamic rendering is a workaround

Google recommends server-side rendering, static rendering or hydration as durable solutions. Bot-specific dynamic rendering adds maintenance and parity risks.

Two-wave indexing is an oversimplificationObserved

SEOs often describe separate HTML and rendering waves. Operationally, fetching, rendering and indexing can be decoupled, but there is no fixed public schedule. Diagnose with rendered HTML and crawl evidence rather than assuming a universal delay.

JavaScript-injected canonical tagsConfirmed

A canonical can be injected with JavaScript, but the clearest implementation is in the original head. Never output one canonical in HTML and replace it with a conflicting value after rendering.

Client-side linksConfirmed

Use actual anchor elements with href values. Click handlers on spans, buttons or anchors without href are unreliable discovery paths and weaken expected browser behaviour.

Lazy loadingObserved

Content should load when it approaches the viewport without requiring user-only actions such as clicking, swiping or typing. Use native loading patterns where possible and ensure rendered HTML contains the content.

Infinite scrollObserved

Create paginated component URLs with stable links and server-renderable content. Infinite scrolling can enhance the interface, but crawlers need a finite, navigable sequence.

Rendered-page QAConfirmed

Compare response HTML, rendered DOM, network requests, status codes, console errors, blocked resources and visible text. Google Search Console URL Inspection and Rich Results Test are useful, but server logs and browser tests add different evidence.

06Canonicalisation and indexing
Which representation enters the index?

The index stores selected representations, not every fetched URL.

Search engines cluster duplicates, select canonicals, analyse primary content and decide whether the representation is useful enough to retain and refresh.

IndexingConfirmed

Crawled does not mean indexed

After fetching, a page is evaluated, consolidated and assessed for index suitability. Low-value, duplicate, inaccessible or policy-violating pages may be excluded even when crawling succeeds.

Duplicate clusterConfirmed

Primary content defines similarity

Canonicalisation groups URLs whose main content is duplicate or very similar. Headers, filters and minor template differences do not necessarily create independent documents.

SignalsConfirmed

Canonical consistency

Redirects, canonicals, sitemaps, internal links, hreflang and HTTPS preferences should point toward the same representative URL. Mixed signals create unstable clusters.

QualityConfirmed

Index selection is selective

An index is not a complete archive of everything crawled. Search engines choose which representations are worth retaining and refreshing for retrieval.

InternationalConfirmed

hreflang is not canonical

hreflang connects alternate language or regional pages. Each alternate should normally be indexable and self-canonical, with reciprocal annotations and valid language-region codes.

MonitoringObserved

Indexing reports need interpretation

Excluded, crawled-not-indexed and discovered-not-indexed are states, not diagnoses by themselves. Compare templates, internal links, content uniqueness, canonical clusters, logs and business value.

Canonical versus redirectConfirmed

Use a redirect when the old URL should no longer be used. Use rel=canonical when duplicate URLs must remain accessible but one should represent the cluster. A canonical is not a substitute for cleaning obsolete URLs.

Cross-domain canonicalConfirmed

Cross-domain canonical tags can consolidate syndicated duplicates toward the original, but they are signals rather than commands. Publishers need to implement them accurately and consistently.

PDF canonicalisationConfirmed

Non-HTML files can send a Link response header with rel=canonical. This is useful when a PDF or document duplicates an HTML page and you want one representative URL.

Near duplicates and localisationObserved

Pages with the same language and only small regional changes may be clustered if their primary content is effectively identical. Genuine localisation requires meaningful market-specific information, not only currency or country names.

Index bloatObserved

Index bloat describes a large inventory of low-value, duplicate or obsolete URLs competing for crawl and index resources. The cure is not mass noindex alone; fix generation, architecture, canonical signals and content purpose.

Soft 404 classificationConfirmed

A page can return 200 but look like an error, empty result or unavailable product. Search engines may classify it as a soft 404. Return appropriate status codes or provide a genuinely useful alternative page.

07Query understanding and retrieval
From words to candidate documents

The typed query is only the beginning of the retrieval problem.

Language models, concepts, entities, location, freshness and intent help search systems decide what the searcher may mean and which document representations should become candidates.

LanguageConfirmed

Tokenisation and linguistic analysis

Search systems break queries and documents into representations that account for words, subwords, morphology, language and context. Exact strings matter in some cases, but modern retrieval extends beyond literal matching.

IntentObserved

Query interpretation

The same terms can imply informational, navigational, transactional, local, visual, fresh or comparative needs. The result page itself reveals which interpretation the engine currently favours.

ConceptsConfirmed

Neural matching and RankBrain

Google documents neural matching and RankBrain as systems that connect words and concepts, helping retrieve relevant pages even when vocabulary differs.

ContextConfirmed

BERT and language understanding

BERT helps Google understand how combinations of words express meaning and intent. It is one component in a larger retrieval and ranking stack, not a standalone SEO factor to optimise directly.

FreshnessConfirmed

Query deserves freshness

Some queries require recent information; others reward stable evergreen sources. Update cadence should follow real information change, not a ritual of changing dates.

SERPConfirmed

Result-type selection

The engine can choose web results, local packs, images, videos, news, shopping, featured snippets or AI features based on query needs and available evidence. Ranking within one vertical is not the whole SERP.

Candidate generation versus final rankingMental model

Large retrieval systems first narrow an enormous index to plausible candidates, then apply increasingly expensive scoring and re-ranking. A page can fail because it was never retrieved, because it scored poorly, or because another result type displaced it.

Entity understandingObserved

Entities help connect names, attributes and relationships across documents and queries. Clear naming, consistent facts, authoritative references and structured data can reduce ambiguity, but entity recognition is not guaranteed.

Passage rankingConfirmed

Google can identify relevant sections within a page to better understand page relevance. This does not mean passages are indexed as independent URLs; coherent page structure and focused sections still matter.

Spelling and rewritingObserved

Search engines may correct spelling, expand terms, identify synonyms or reinterpret the query. Track the actual SERP and query variants rather than assuming the typed string is the only retrieval input.

Local and personal contextConfirmed

Language, location and device can affect relevance and presentation. Personalisation is often overclaimed in SEO explanations; test with controlled locations and logged-out conditions where possible.

SERP intent driftObserved

A query can change meaning over time as products, events and user behaviour evolve. Historical rankings may not be comparable when the result-type mix or dominant interpretation changed.

08Ranking systems and signal families
Eligibility × relevance × quality × context

Ranking is conditional, layered and query dependent.

There is no public universal weighting table. A robust model separates technical eligibility, retrieval relevance, document quality, link and reputation evidence, context, spam constraints and result presentation.

EligibilityConfirmed

Technical eligibility

The page must be accessible, return meaningful content, allow indexing, and avoid technical or policy barriers. Ranking work cannot rescue a page the engine cannot fetch, render or retain.

RelevanceConfirmed

Query and document fit

Words, concepts, entities, headings, surrounding context, media and structured information help systems judge whether a document answers the query and which part is relevant.

QualityConfirmed

Usefulness and source quality

Original information, completeness, accuracy, transparent sourcing, first-hand experience and a clear purpose help a document compete. Quality is evaluated through many signals, not one score exposed to site owners.

AuthorityConfirmed

Links and reputation

Links remain part of Google’s core systems, but value depends on context, source quality, placement, relevance and spam handling. Raw counts are a poor substitute for graph quality.

ContextConfirmed

Location, language, freshness and device

Ranking is conditional. A page can be strong for one place, language, time window or intent and weak for another. There is no universal position independent of context.

PresentationConfirmed

Result eligibility and appearance

Structured data, media quality, merchant feeds, business information and page formatting can make a URL eligible for richer presentations without guaranteeing that they appear.

There is no public complete list of 200 ranking factorsConfirmed

Google describes many systems and signal families, not a static checklist with universal weights. Weighting can vary by query, vertical, language, location and result type. Treat factor lists as models, not source code.

Page-level and site-wide signals coexistConfirmed

Google states that ranking systems primarily work at page level while also using site-wide signals and classifiers. A strong site does not make every page strong; a weak area does not doom every URL.

Core updates are broad system changesConfirmed

Core updates can alter how systems assess and combine signals across many queries. Recovery is rarely a single technical switch. Compare affected query groups, page types, intent and competitive changes over time.

E-E-A-T is not a single measurable factorConfirmed

Experience, expertise, authoritativeness and trust are useful quality concepts. Search systems may use many signals that align with those concepts, but there is no public E-E-A-T score that can be directly optimised.

Correlation is not causationResearch rule

Top-ranking pages often share features because successful pages, brands and sites invest in many things simultaneously. Controlled tests, before-and-after evidence and competing explanations are needed before claiming a factor.

Conceptual ranking equationMental model

A practical model is Eligibility × Relevance × Quality × Context × Presentation, constrained by spam and result diversity. It is not Google’s formula; it forces diagnosis across the full system instead of chasing one metric.

Documented Google systems

Named systems are components—not a checklist of levers.

SystemPurposeStatusWhat Google documents
BERTLanguage understandingCurrent core systemUnderstands how word combinations express meaning and intent.
Neural matchingConcept matchingCurrent core systemConnects conceptual representations in queries and pages.
RankBrainConcept relationshipsCurrent core systemHelps relate words to concepts and improve retrieval for unfamiliar phrasing.
Passage rankingSection relevanceCurrent systemUnderstands the relevance of individual passages within a page.
Freshness systemsTime sensitivityCurrent systemsPromote newer information when the query reasonably demands freshness.
PageRank and link analysisGraph importanceCurrent evolved systemsUse link relationships to understand pages and potential usefulness.
Original content systemsSource preferenceCurrent systemsSupport surfacing original reporting and primary sources ahead of copies.
Reviews systemReview qualityCurrent systemRewards insightful, original reviews created by people who know the subject.
Site diversityResult diversityCurrent systemUsually limits excessive results from the same site for a query.
SpamBrain and spam systemsAbuse preventionCurrent systemsDetect patterns that violate spam policies and adapt as abuse changes.
Reliable information systemsTrust and safetyCurrent systemsElevate reliable sources and add advisories when confidence is limited.
Deduplication systemsResult consolidationCurrent systemsReduce duplicate listings and repeated featured-snippet URLs.
Helpful contentHelpfulness signalsIntegrated into coreThe standalone system became part of core ranking systems in March 2024.
PandaContent qualityIntegrated into coreHistorical quality system incorporated into core systems.
PenguinLink spamIntegrated into coreHistorical link-spam system incorporated into core systems.
HummingbirdOverall ranking architectureHistorical milestoneMajor 2013 improvement whose concepts continued through later evolution.
10Content quality and usefulness
Original evidence, task completion and trust

Useful content changes the reader’s understanding or ability to act.

Quality is not a word count, keyword density or template score. It is the combination of purpose, originality, completeness, accuracy, source clarity and fit for the searcher’s task.

PurposeConfirmed

Clear primary purpose

A page should satisfy a real user need and have a reason to exist beyond capturing a keyword variation. Strong purpose guides scope, evidence, format and internal linking.

OriginalityObserved

Information gain

Original data, first-hand testing, unique examples, expert synthesis and clearer explanations give the document something the existing result set lacks. “Longer” is not the same as more informative.

CompletenessObserved

Task completion

Useful content anticipates the decisions and follow-up questions required to complete the task. A page can be concise and complete, or long and evasive.

TrustConfirmed

Evidence and transparency

Citations, dates, methods, limitations, author context and correction practices help readers assess reliability. Trust is especially important for topics that can affect health, safety, finances or wellbeing.

MaintenanceObserved

Freshness with substance

Update content when facts, products, laws, interfaces or evidence change. Preserve historical context and explain important revisions instead of changing a date without changing the information.

ScaleConfirmed

Programmatic value threshold

Templates can scale useful datasets and comparisons, but pages need distinct utility. Mass-producing interchangeable text with little value creates index bloat and scaled-content-abuse risk.

People-first does not mean “ignore search demand”Confirmed

Search demand reveals user language and recurring needs. The problem is content made primarily to manipulate rankings without satisfying those needs. Research demand, then create the best resource for the task.

Word count is not a ranking factor targetResearch rule

The correct length is the amount needed to answer the query well. Padding creates friction and can hide the useful section. Compare information coverage, not arbitrary word totals.

Author pages and bylinesObserved

Bylines and author profiles can help users understand responsibility and expertise. They are not magic markup. The content itself, its evidence and the site’s reputation still need to support the claim.

Duplicate content is usually a consolidation problemConfirmed

Normal duplicate content is not automatically a spam violation. It can dilute signals, waste crawl and create unstable canonical selection. Intentional deceptive duplication is a different policy issue.

AI-assisted contentConfirmed

Google’s policy focuses on purpose and value, not the mere use of automation. Scaled content produced primarily to manipulate rankings, whether by humans or machines, violates spam policy.

Content pruningObserved

Do not delete pages merely because traffic is low. Decide whether the page has unique value, links, conversions, seasonal demand or support purpose. Improve, consolidate, redirect or remove based on evidence.

11Page experience
Performance, responsiveness and stability

Page experience supports the task; it does not replace the answer.

Core Web Vitals provide field metrics for loading, interaction and stability. Use them as real-user quality measures, not as a promise that a fast irrelevant page outranks a useful result.

LCPConfirmed

Largest Contentful Paint

LCP measures loading performance of the largest visible content element. Google recommends aiming for 2.5 seconds or less at the 75th percentile of field visits.

INPConfirmed

Interaction to Next Paint

INP measures responsiveness across user interactions. A good threshold is under 200 milliseconds at the 75th percentile.

CLSConfirmed

Cumulative Layout Shift

CLS measures unexpected visual movement. A good threshold is below 0.1 at the 75th percentile.

Field dataConfirmed

Real-user data matters

Search Console Core Web Vitals is based on aggregated field data where available. Lab tools are diagnostic simulations; they do not replace actual user distributions.

ExperienceConfirmed

Page experience is broader than CWV

Mobile usability, security, intrusive interruptions, clarity and task completion affect users even when they are not represented by one ranking metric.

TradeoffsConfirmed

Relevance can outweigh speed differences

Core Web Vitals are not a universal tie-breaker that overrides content relevance and quality. Treat performance as user and technical quality, not a shortcut around weak information.

12Search appearance
Titles, snippets, rich results and media

The engine composes a result, not a mirror of your metadata.

Titles and snippets are generated. Structured data creates eligibility. Images, videos, merchant feeds and business information can change presentation when they are accurate and supported.

TitlesConfirmed

Title links are generated

Google can use the title element, visible headings, prominent text and link references to create a title link. Clear, concise, page-specific titles reduce rewriting risk but do not guarantee exact output.

SnippetsConfirmed

Snippets are query dependent

Google primarily builds snippets from page content and may use the meta description when it better summarises the page. Different queries can produce different snippets.

Structured dataConfirmed

Eligibility, not entitlement

Valid structured data can make content eligible for supported rich results. It must match visible content and follow feature-specific guidelines; appearance remains algorithmic.

Site structureConfirmed

Sitelinks are automated

Logical navigation, informative titles and relevant internal anchors help systems identify useful shortcuts. Site owners cannot directly choose sitelinks.

ImagesConfirmed

Image understanding

Descriptive filenames, alt text, nearby text, image quality and accessible pages help search engines understand images. Alt text should describe purpose, not repeat keyword lists.

FeedsConfirmed

Merchant and business data

For products and local entities, structured data, Merchant Center and Business Profile information can complement crawling with more explicit facts and eligibility signals.

13Specialised SEO systems
International, local, ecommerce and programmatic

Different inventories create different failure modes.

The fundamentals stay constant, but a multilingual site, local business, product catalogue and programmatic directory each require specialised architecture, data and quality controls.

InternationalConfirmed

Language and regional architecture

Use stable URLs for each version, translate primary content, add reciprocal hreflang and localise more than currency. Country folders, subdomains and country domains can all work when maintained consistently.

LocalObserved

Local search

Local visibility depends on relevance, distance, prominence and accurate business information. Website content, Business Profile data, reviews, citations and location context work together.

EcommerceObserved

Category and product roles

Category pages match browsing and comparison intent; product pages match specific item intent. Facets need intentional index rules, and availability, variants, reviews and merchant data should remain consistent.

ProgrammaticObserved

Template governance

Define a minimum value contract for every generated page: unique data, accurate intent, useful comparison or local information, crawl controls, QA and a retirement rule.

NewsConfirmed

Publication dates and updates

Show clear publication and modification dates when relevant. Do not repeatedly republish unchanged stories as new. News and Discover eligibility depend on broader quality and policy requirements.

VideoConfirmed

Dedicated watch pages

Important videos benefit from a stable page where the video is the main content, with a crawlable thumbnail, title, description and supporting transcript or context.

16Bing and Microsoft search
Bingbot, IndexNow, Copilot and grounding

Bing shares the search foundation but exposes different controls.

Microsoft’s current guidance connects traditional SEO with visibility and citations across Bing and Copilot. IndexNow and crawl-control features create operational differences worth understanding.

DiscoveryConfirmed

Links, sitemaps and IndexNow

Bing’s current guidelines emphasise crawlable internal links, external references, XML sitemaps and IndexNow notifications for added, changed or deleted URLs.

AIConfirmed

Search and Copilot share foundations

Bing states that discovery, indexing accuracy, content clarity, authority and trust support traditional results as well as grounding and citation eligibility in AI experiences.

CrawlConfirmed

Bing crawl control

Bing Webmaster Tools allows site owners to influence hourly crawl patterns, and Bing documents support for crawl-delay. This differs from Google’s crawl-control model.

DiagnosticsConfirmed

Site Explorer and URL Inspection

Bing exposes indexed, excluded, redirecting, robots-blocked, noindex and error states, along with crawl dates and performance data, through Webmaster Tools.

FreshnessConfirmed

Accurate lastmod and validators

Bing recommends accurate sitemap freshness signals and HTTP validators such as ETags to help detect changes reliably.

EligibilityConfirmed

Submission is not selection

Bing can discover a URL through IndexNow or URL submission and still decide not to index or rank it because of duplication, quality, policy or relevance.

Google versus Bing: common foundationConfirmed

Both engines need discoverable URLs, accessible responses, understandable content, coherent canonical signals, trustworthy sources and useful pages. Most durable SEO work improves eligibility across both.

Google versus Bing: important operational differencesConfirmed

Bing offers IndexNow and explicit crawl-control features. Google relies more on its own scheduling and supports recrawl requests and sitemaps rather than IndexNow for general web indexing.

Bingbot verificationConfirmed

Do not trust a user-agent string alone. Verify crawler IPs using Bing’s documented methods or Webmaster Tools, and apply the same principle to Googlebot verification.

Bing AI groundingConfirmed

Bing’s guidelines explicitly connect SEO fundamentals with eligibility for Copilot and grounding results. This increases the value of accurate, well-structured, source-clear documents.

IndexNow implementation disciplineConfirmed

Notify only URLs on the verified host, submit additions, updates and deletions, protect the key, and avoid excessive duplicate submissions. A 200 response means accepted by the endpoint, not ranked.

Why engines disagreeObserved

Google and Bing maintain different indexes, crawling priorities, language models, link graphs, policies and result layouts. A URL can be indexed or ranked differently without either engine being technically broken.

IndexNowConfirmed

Notification reduces discovery latency

IndexNow can notify participating engines that URLs were added, updated or deleted. Successful receipt does not guarantee crawling, indexing, grounding, citation or ranking.

FreshnessConfirmed

Bing documents accurate lastmod and HTTP validators

Current Bing guidance recommends accurate sitemap freshness signals and validators such as ETags so change detection is more reliable.

CopilotConfirmed

Search eligibility supports grounding eligibility

Bing states that crawl efficiency, indexing accuracy, URL consolidation, content clarity, authority and trust also support Copilot grounding and citation eligibility.

ControlsConfirmed

Bing supports engine-specific preview directives

Bing documents robots directives that affect indexing, snippets, caching and how content may be used in Copilot or grounding experiences.

DiagnosticsConfirmed

Search Performance combines search and crawl metrics

Bing Webmaster Tools reports impressions, clicks, CTR, position, crawl requests, crawl errors and indexed pages, including visibility from multiple Bing surfaces.

CrawlConfirmed

Crawl Control and crawl-delay are Bing-specific operational tools

Bing lets verified site owners influence hourly crawl patterns, and its documentation states that robots.txt crawl-delay can take precedence.

Bing Site ExplorerConfirmed

Use folder-level and URL-level information to study indexed, excluded, warning and error states, last crawl dates, HTTP codes, backlinks and performance.

Bing versus Google rendering riskConfirmed

Both engines need stable, accessible content. Bing explicitly warns against hiding critical content behind client-side rendering or requiring excessive requests to build the page.

Grounding controls require deliberate choicesConfirmed

Bing documents that NOARCHIVE, NOCACHE, NOSNIPPET and related controls can affect Copilot and grounding depth. Review them before using broad robots templates.

Bing index exclusion is still a quality decisionConfirmed

A URL can be technically crawlable and submitted yet excluded for duplication, low value, guideline issues, weak rank or other selection reasons.

Bing discovery and freshness controls

Bing exposes several operational levers that are more explicit than Google’s general web-indexing workflow.

IndexNow for additions, updates and deletions.
XML sitemaps with accurate canonical URLs and lastmod values.
Crawl Control and supported crawl-delay behaviour.
URL submission, URL inspection and Site Explorer diagnostics.

Bing, Copilot and grounded answers

Microsoft connects conventional SEO foundations with eligibility across search results, chat responses, knowledge panels and grounding systems.

Public, crawlable and indexable documents create the retrieval foundation.
Clear structure and source authority support citation usefulness.
Preview and cache directives can reduce answer or citation depth.
IndexNow notification still does not guarantee selection.
17Local and Maps SEO
Place entities, proximity, reputation and local intent

Local search ranks businesses and places—not only web documents.

Maps visibility combines business-entity data, geographic context, relevance, prominence, policy compliance and web evidence. The website and Business Profile must reinforce the same real-world entity.

Relevance

Does this business match the task?

Categories, services, attributes, content and profile information help the engine understand what the business offers.

Distance

How near is the business to the search context?

The user’s explicit or inferred location changes the candidate set and cannot be “optimised away” by keyword repetition.

Prominence

How established and trusted is the place?

Reviews, links, citations, brand recognition, real-world notability and corroborating sources contribute to the place representation.

EntityConfirmed

The business profile and the website describe one real entity

Names, categories, addresses, service areas, phone numbers, opening hours and official URLs should accurately represent the real-world business across profile, website and trusted sources.

RelevanceConfirmed

Local relevance begins with category and service clarity

Google says local ranking is mainly based on relevance, distance and prominence. Complete categories, services, attributes and location content help the system match a business to a query.

DistanceConfirmed

Proximity is a query-context constraint

Distance depends on the searcher’s known or inferred location. It cannot be replaced by repeating city names, creating doorway pages or changing the map pin dishonestly.

ProminenceConfirmed

Prominence combines web and place evidence

Google describes prominence as how well known a business is and references links and reviews among the information used. Offline notability and web corroboration can both matter.

ProfileConfirmed

Complete, verified and current information reduces ambiguity

Verification, accurate hours, special hours, phone, website, categories, attributes, photos and products improve user usefulness and entity confidence.

ReviewsConfirmed

Reviews are reputation evidence, not text inventory

Review quantity, rating and helpful owner responses can influence how a business stands out. Do not gate, buy, fabricate or selectively pressure customers for reviews.

WebsiteConfirmed

The linked website must support the local entity

Location pages should provide unique address or service-area information, contact details, directions, local proof, staff or facility details, services and a clear relationship to the main brand.

SchemaConfirmed

LocalBusiness structured data supports interpretation

Use the most specific valid subtype, accurate address and contact properties, and only claims visible on the page. Structured data creates eligibility and clarity, not guaranteed local rankings.

CitationsConfirmed

Consistency helps systems reconcile business records

Directories and third-party sources should describe the same business accurately. Perfect character-for-character NAP repetition is less important than avoiding contradictory identity data.

DuplicatesConfirmed

Duplicate profiles divide control and create risk

Merge or remove accidental duplicates where policy permits. Practitioner, department and location listings should follow Google’s representation rules.

TrackingConfirmed

Local rankings must be measured geographically

A single manual search is weak evidence. Track query, location, device, time, local-pack presence, organic result, profile actions and changes to competitors.

SpamConfirmed

Map visibility is constrained by representation policies

Keyword-stuffed names, false locations, virtual offices, duplicate profiles and ineligible businesses can be corrected, suspended or filtered. Policy compliance is part of technical local SEO.

Local pack versus local organic resultsConfirmed

The local pack is a place-ranking surface tied closely to Business Profile and location context. The organic results below it use the broader web index. A business can perform differently in each.

Service-area businessesConfirmed

Use a service area only when the business travels to customers and follows profile rules. Hiding an address does not create proximity to every city in the service area.

Multi-location architectureConfirmed

Give each legitimate location a useful canonical page with unique operational details. Avoid thousands of near-duplicate city pages that exist only to swap a place name.

Local landing-page information gainConfirmed

Useful local pages can include inventory, staff, facilities, accessibility, parking, delivery areas, local regulations, case examples, directions and location-specific FAQs.

Google sources local business informationConfirmed

Google says profile information may come from owners, public web content, licensed third parties, user contributions and Google’s interactions with places. Resolve contradictions across these sources.

Bing and map ecosystemsConfirmed

Microsoft local search also depends on business entities, categories, geographic coordinates and regional context. Maintain accurate data across the sources and platforms that feed Microsoft experiences.

18Algorithm evolution
Milestones in Google Search

Algorithms evolve by absorbing new representations, models and safeguards.

Names such as Panda, Penguin and BERT mark important changes, but modern Search is a continuously changing system of interacting components.

1998

PageRank era

Links become a scalable way to estimate relative importance in a web graph. The original patent is historical; the modern system has evolved.

2011

Panda

A quality-focused system aimed at improving the visibility of original, high-quality content. Later incorporated into core ranking systems.

2012

Penguin

A system designed to combat link spam. It was integrated into core ranking systems in 2016.

2013

Hummingbird

A major overhaul of the overall ranking architecture, improving the ability to interpret queries beyond isolated keywords.

2015

RankBrain

Machine learning helps connect unfamiliar words and phrases to concepts and likely intent.

2018+

Neural matching

Conceptual representations improve matching between queries and documents.

2019

BERT

Contextual language understanding improves interpretation of word combinations and intent.

2021

Passage ranking

Systems can better understand the relevance of individual passages within a page.

2022

Helpful content system

A site-wide classifier was introduced to promote people-first content and reduce search-first material.

2024

Helpful signals integrated

The standalone helpful-content system became part of core ranking systems during the March 2024 core update.

Continuous

SpamBrain and core updates

Spam detection and core ranking systems evolve continuously, with selected major changes announced publicly.

Current

AI-assisted search

AI Overviews and AI Mode add query fan-out, synthesis and supporting links while retaining core crawl, index and eligibility foundations.

19Google and Microsoft patent atlas
Reverse engineering without pretending patents are ranking confirmations

Patents expose possible search mechanisms, vocabulary and engineering problems.

This is a curated research atlas—not every patent ever filed. It focuses on documents with direct value for understanding crawling, indexing, query rewriting, link graphs, learning to rank, freshness, personalisation and result composition.

Patent ownership is not production confirmation.

A company may patent an idea and never deploy it, deploy only part of it, replace it, use it outside web search, or keep using a newer unpublished method. Treat patents as hypothesis generators. Validate current behaviour with official documentation, live SERPs, logs and controlled tests.

Google-linked patent families

Link graphs, phrases, entities, history, quality and result presentation

Google lineage · US6285999B1

Method for node ranking in a linked database

Mechanism described

Ranks nodes recursively from the importance of nodes linking to them.

SEO research value

Builds intuition for graph authority, internal linking and why links from different sources are not interchangeable.

Evidence boundary

The foundational PageRank mechanism is historical and has evolved; it is not a current ranking formula.

Open patent record ↗
Google · US9305099B1

Ranking documents using behaviour and link-feature data

Mechanism described

Models link weights using link features and navigational behaviour rather than treating every link identically.

SEO research value

Supports research into placement, context, visibility and the idea behind the Reasonable Surfer family.

Evidence boundary

A patent describes a possible mechanism and does not confirm current Google production use or weights.

Open patent record ↗
Google · US7536408B2

Phrase-based indexing in an information retrieval system

Mechanism described

Identifies good phrases and related phrases across documents to support indexing, retrieval and scoring.

SEO research value

Useful for thinking about topic relationships, co-occurrence, phrase completeness and spam-resistant document representation.

Evidence boundary

Do not convert the patent into a phrase-density checklist or claim the exact method is active.

Open patent record ↗
Google · US7346839B2

Information retrieval based on historical data

Mechanism described

Describes historical features such as document change, links, traffic and query-related behaviour.

SEO research value

Helps form hypotheses about freshness, sudden link changes, document history and temporal trust patterns.

Evidence boundary

The age of a domain or page is not a standalone universal ranking factor; the mechanism is contextual and historical.

Open patent record ↗
Google · US9195944B1

Site quality score

Mechanism described

Describes a site-level score based on ratios between navigational interest and resource interest.

SEO research value

Useful for studying brand or site demand, navigational queries and why page-level quality can coexist with broader site signals.

Evidence boundary

The published formula is not confirmation of a currently deployed site-wide ranking factor.

Open patent record ↗
Google · US8127220B1

Scoring links in a document

Mechanism described

Assigns scores to links based on features of the link and the containing document.

SEO research value

Supports experiments around main-content links, boilerplate, anchor context, placement and internal-link architecture.

Evidence boundary

A link-scoring patent cannot tell an SEO the current value of a specific link.

Open patent record ↗
Google · US7996419B2

Query rewriting with entity detection

Mechanism described

Detects entity names in a query and rewrites or constrains the query using entity-associated information.

SEO research value

Useful for entity SEO, ambiguous names, brand queries, place queries and understanding why literal keyword matching is insufficient.

Evidence boundary

Query rewriting is one possible retrieval-stage mechanism, not proof of how every query is currently transformed.

Open patent record ↗
Google lineage · US6526440B1

Reranking search results using local inter-connectivity

Mechanism described

Builds a local graph among top results and reranks documents based on connectivity within that result set.

SEO research value

Provides a model for topical communities, hub-like documents and query-specific authority rather than global authority alone.

Evidence boundary

The patent is old and its assignee history and production relevance must be treated cautiously.

Open patent record ↗
Google · US9390174B2

Search result ranking and presentation

Mechanism described

Combines result ranking with presentation decisions for conceptually related information.

SEO research value

Useful for understanding that ranking and SERP composition are connected but separate layers.

Evidence boundary

A presentation patent does not guarantee a particular current feature or ranking treatment.

Open patent record ↗
Google · US7716225B1

Ranking documents based on user behaviour and feature data

Mechanism described

Creates ranking models from document, link and user-behaviour features.

SEO research value

Encourages careful study of aggregate behaviour models, link context and feature interactions rather than one-factor explanations.

Evidence boundary

Behavioural patents are highly sensitive to interpretation and do not prove that clicks directly control ordinary rankings.

Open patent record ↗
Microsoft and Bing-linked patent families

Learning to rank, temporal relevance, query logs, personalisation and crawling

Microsoft · WO2013103588A1

Search ranking features

Mechanism described

Describes search ranking features and an engine module that can generate or evaluate them.

SEO research value

Useful for studying feature engineering, learning-to-rank pipelines and the separation between features and final models.

Evidence boundary

The patent does not disclose Bing’s present ranking stack or current feature weights.

Open patent record ↗
Microsoft · US9405835B2

Generating a search result ranking function

Mechanism described

Generates ranking functions from training data and selected variables.

SEO research value

Supports understanding of learned ranking models, feature selection and why ranking changes can affect query classes differently.

Evidence boundary

A learned-ranking patent is a general mechanism, not evidence of Bing’s exact current model.

Open patent record ↗
Microsoft · US7818315B2

Reranking search results based on query logs

Mechanism described

Uses query-log relationships to modify or rerank results.

SEO research value

Useful for studying query reformulation, session patterns and aggregate interaction evidence.

Evidence boundary

Do not reduce this to a claim that individual clicks or CTR directly determine ranking.

Open patent record ↗
Microsoft · US7849079B2

Temporal ranking of search results

Mechanism described

Applies time-dependent considerations to result ranking.

SEO research value

Helps model freshness-sensitive queries, event recency and different temporal decay patterns.

Evidence boundary

Temporal methods are query dependent and do not imply that newer content always ranks better.

Open patent record ↗
Microsoft · US8370337B2

Ranking search results using click-based data

Mechanism described

Describes using aggregated click-based features within ranking.

SEO research value

Useful for understanding debiasing challenges, position effects and why aggregate behaviour may be modelled.

Evidence boundary

It does not prove that Bing applies raw CTR as a simple ranking factor.

Open patent record ↗
Microsoft · US9507861B2

Enhanced query rewriting through click-log analysis

Mechanism described

Identifies related strings and rewrites queries using session and click-log information.

SEO research value

Useful for analysing spelling, reformulations, synonyms and how engines bridge user vocabulary with indexed documents.

Evidence boundary

The patent does not reveal current Bing query-rewrite rules for a given query.

Open patent record ↗
Microsoft · US7822742B2

Modifying relevance ranking of search result items

Mechanism described

Adjusts ranking using identified result relationships or relevance information.

SEO research value

Supports thinking about reranking layers and result-set adjustments after initial retrieval.

Evidence boundary

The described mechanism may be historical, partial or unused in present systems.

Open patent record ↗
Microsoft · US7792833B2

Ranking search results using language types

Mechanism described

Uses language-related types or characteristics when ranking text results.

SEO research value

Useful for international SEO, language detection, mixed-language documents and query-document language fit.

Evidence boundary

It does not replace current hreflang, locale and language-quality diagnostics.

Open patent record ↗
Microsoft · US7464075B2

Personalisation of web-page search rankings

Mechanism described

Describes modifying rankings using user or group-related information.

SEO research value

Helps explain why location, history, preferences or context can create different result orders.

Evidence boundary

Personalisation scope varies; do not treat one observed SERP as the universal ranking.

Open patent record ↗
Microsoft · WO2011116082A2

Indexing and searching using virtual documents

Mechanism described

Creates virtual document representations from embedded or externally sourced components.

SEO research value

Useful for studying how complex documents, embedded content and composite resources might be represented for retrieval.

Evidence boundary

The concept is broader than ordinary web-page SEO and is not proof of current Bing indexing architecture.

Open patent record ↗
Microsoft · WO2013022659A2

Optimising web crawling with user history

Mechanism described

Balances freshness and server constraints using historical usage or traffic information.

SEO research value

Supports crawl-scheduling hypotheses involving peak traffic, change probability and server politeness.

Evidence boundary

Bing’s current crawler behaviour should be diagnosed with logs and current documentation, not inferred solely from this patent.

Open patent record ↗
Microsoft · WO2006121536A2

Relevance improvements using feedback

Mechanism described

Uses feedback and query-result relationships to improve relevance while considering performance.

SEO research value

Useful for understanding aggregate feedback loops, offline evaluation and reranking.

Evidence boundary

Feedback mechanisms do not establish that a single user action changes ranking.

Open patent record ↗
How I read a search patentResearch protocol

Start with the problem statement, identify inputs and outputs, map the components, read independent claims, inspect cited and citing families, note dates and assignees, then design a testable SEO hypothesis without claiming production use.

Patent family versus one publicationResearch protocol

Continuations and related applications may refine the same underlying idea. Read the family timeline rather than treating each publication number as an independent ranking system.

Claims matter more than SEO summariesResearch protocol

Abstracts are accessible, but the independent claims define the protected method. Diagrams and examples can clarify the mechanism, while SEO articles may overstate implications.

Use patents to generate variables, not recipesMental model

A patent can suggest variables such as link placement, query reformulation, freshness or user context. Convert those into measurable tests rather than prescriptive ranking-factor lists.

18SEO research protocol
From observation to defensible conclusion

Reverse engineering starts with disciplined uncertainty.

A good SEO study separates what happened, what may explain it, what evidence would falsify the hypothesis and which confounders remain.

01

Define the system boundary

State whether the question concerns discovery, crawl, render, canonicalisation, indexing, retrieval, ranking or presentation.

02

Build the event timeline

Record releases, migrations, content changes, outages, manual actions, updates and measurement changes.

03

Segment the impact

Compare query classes, templates, countries, devices, directories, result types and new versus old URLs.

04

Collect independent evidence

Use logs, Search Console, analytics, crawls, rendered HTML, SERPs, backlinks and server data.

05

Write competing hypotheses

List technical, content, intent, competitor, policy, seasonality and measurement explanations.

06

Change the smallest variable

Use controlled template groups, holdouts or staged releases where risk permits.

07

Wait for the right system

Crawl, indexing and ranking changes have different processing times. Do not judge all tests on the same clock.

08

Record limits and confidence

Publish what is known, what is inferred, what failed and what would change the conclusion.

19SEO myths and boundaries
What the evidence does not support

Expertise includes knowing when the answer is unknown.

Search engines intentionally keep many details private. The job is to build useful models without turning uncertainty into invented certainty.

×
“Google uses exactly 200 ranking factors.”

Google publicly describes many systems and signals, but not a fixed universal list or weights.

×
“A sitemap forces indexing.”

It helps discovery and canonical preference; it does not guarantee indexing or ranking.

×
“robots.txt removes pages from Google.”

It blocks crawling. A known URL can still appear without content. Use noindex or access control for removal.

×
“More pages mean more traffic.”

More useful, differentiated pages can expand coverage. More low-value pages can waste crawl and trigger spam risk.

×
“Canonical tags are commands.”

They are strong signals, but search engines can choose another representative URL.

×
“Every backlink passes the same value.”

Link systems consider graph context, relevance, placement, quality and spam handling.

×
“Core Web Vitals alone can rank a weak page.”

Performance supports experience; it does not replace relevance, quality or eligibility.

×
“AI content is automatically spam.”

Automation is not the sole criterion. Scaled low-value content created to manipulate rankings is the policy problem.

×
“A patent proves the algorithm.”

A patent proves that an idea was documented and protected, not that it is currently deployed exactly as written.

×
“Crawled means indexed.”

Crawling is only one stage. Index selection and canonicalisation can exclude the URL.

×
“Exact-match keywords must be repeated everywhere.”

Modern retrieval uses language and concept systems. Natural clarity and task fit are safer than forced repetition.

×
“Google and Bing should rank the same pages.”

They have different indexes, models, graphs, policies and result composition.

20Technical glossary
The language of search systems

Precise vocabulary prevents imprecise diagnosis.

Use the search box near the top of the page to filter this glossary and every technical card across the full bible.

200Successful HTTP response with a processable representation.
301/308Permanent redirect; a strong canonical signal.
302/307Temporary redirect; source may remain canonical.
304Not modified; validates a cached representation.
404Not found; the resource is unavailable.
410Gone; explicit permanent removal.
429Too many requests; signals overload.
5xxServer failure; persistent errors reduce crawl and can remove URLs.
Canonical URLRepresentative URL selected from a duplicate cluster.
Canonical tagrel=canonical preference in HTML or an HTTP Link header.
Crawl budgetResources a crawler allocates to a host, shaped by capacity and demand.
Crawl trapA URL pattern that creates excessive or infinite crawl paths.
CrawlerAutomated software that discovers and fetches resources.
DeduplicationGrouping similar results or documents to avoid repetition.
Discovered – currently not indexedKnown URL not yet crawled or selected for indexing.
Crawled – currently not indexedFetched URL not currently retained in the index.
EntityA distinct person, place, organisation, thing or concept with attributes and relationships.
Faceted navigationFilters that generate category or result URL combinations.
GooglebotGoogle crawler family for Search and other products.
BingbotMicrosoft Bing crawler.
hreflangAnnotation connecting language and regional alternate pages.
IndexSearchable representations stored for retrieval.
IndexNowProtocol for notifying participating engines about URL changes.
Information retrievalSystems that find and rank documents relevant to a query.
Internal linkLink between pages on the same site.
Link graphNetwork of pages and links used for discovery and analysis.
NoindexDirective requesting exclusion from search results.
NofollowLink qualification indicating that ranking credit should generally not be passed as a normal editorial link.
Orphan pagePage with no crawlable internal link path.
PageRankEvolved link-analysis system rooted in recursive graph ranking.
Passage rankingUnderstanding of relevant sections within a page.
Query fan-outIssuing multiple related searches to explore subtopics and sources.
RenderingProcessing HTML, CSS and JavaScript into an interpreted document.
Robots.txtHost-level file controlling crawler access to URL paths.
Search intentUnderlying task or need represented by a query.
SERPSearch engine results page.
Soft 404A 200-status page interpreted as an error or empty result.
SpamBrainGoogle spam-detection system family.
Structured dataMachine-readable markup describing entities and content.
URL parameterQuery-string component that can change tracking, sorting, filtering or content.
Web Rendering ServiceGoogle systems that render pages using Chrome technology.
Nafil Shareef, SEO expert and search engine researcher
Nafil ShareefSEO expert · search-engine researcher · technical SEO practitioner
About Nafil Shareef

I learn Search deeply, test what I can, and publish what the evidence allows me to say.

I am Nafil Shareef—an SEO expert and search-engine researcher. I study Search as a connected system: how Google and Bing discover URLs, schedule crawls, render JavaScript, choose canonicals, create document representations, retrieve candidates, combine ranking systems and compose results.

NafilShareef.com is my public learning library. I created it to help students, entrepreneurs and marketers understand why websites are crawled, excluded, indexed, re-ranked or presented differently—and to make the difference between documentation, field evidence, patent hypotheses and speculation visible.

My research combines official documentation, patents, information-retrieval concepts, Search Console data, crawl diagnostics, server logs, source-versus-rendered comparisons and controlled website tests. I use those lessons to build and improve technical, ecommerce, content, international and scalable SEO systems on real websites.

I am most interested in the questions where common explanations stop being enough: why a page is crawled but not indexed, why Google selects another canonical, why a template underperforms across thousands of URLs, why rankings move differently by query class, and how to separate algorithmic change from implementation errors, demand shifts and measurement noise.

SEO expertTechnical SEOGoogle algorithmsCrawl engineeringIndexation diagnosticsJavaScript SEOInformation retrievalProgrammatic SEOInternational SEOSearch analyticsGoogle patentsBing & IndexNow
Learn deeplyDocumentation, papers, patents and system architecture before tactics.
Research patientlyTimelines, segmentation and competing explanations before conclusions.
Test on websitesControlled changes, implementation QA and real query evidence.
Record resultsWhat changed, what failed, what remains uncertain and what to test next.
24Primary source library
Official documentation and patent records

Every strong SEO claim should be traceable to a source or labelled as an observation.

This page prioritises official Google, Microsoft/Bing, IndexNow and patent records. Documentation can change, so source dates and current wording should be rechecked before using a statement as policy.

Does Google crawl every URL it discovers?

No. Discovery places a URL into a known set, but scheduling depends on demand, capacity, policies and expected value.

Does a higher crawl rate improve ranking?

Not by itself. Efficient crawling supports freshness and discovery; ranking still depends on relevance, quality, context and policies.

Can a robots-blocked URL appear in search?

Yes. The URL may be known through links even when its content cannot be crawled. Use noindex with crawl access, authentication or removal as appropriate.

Is canonical the same as noindex?

No. Canonical consolidates duplicate signals toward a representative URL. Noindex requests that the page be excluded from results.

Does structured data increase rankings?

It can improve understanding and eligibility for rich features, but Google does not guarantee the feature or a ranking improvement.

Are patents ranking-factor confirmations?

No. They are useful research documents showing possible mechanisms and terminology, not production confirmation.

Does Bing use IndexNow immediately?

IndexNow accelerates notification. Receipt does not guarantee crawling, indexing, citation or ranking.

How should programmatic SEO pages be evaluated?

Each page should have distinct user value, accurate data, a clear intent, crawl governance, quality checks and a reason to remain indexed.

Scroll to Top