Archiv für den Autor: Andreas

Here’s why Google’s contentEffort is not a confirmed ranking factor

Google’s leaked search documentation includes a field called contentEffort, described as an AI estimate of effort for article pages. It does not establish that Google identifies lightly edited AI articles and automatically demotes them, or reveal how much the field matters to rankings.

The entry comes from the documentation exposed in 2024. Claims that it confirms a content-effort ranking factor go beyond the available evidence. Publishers do face a documented risk from producing large amounts of unoriginal material to manipulate search results, but Google’s scaled-content-abuse policy applies regardless of how that material is made.

What the leaked field records

The preserved QualityNsrPQData documentation describes contentEffort as:

“LLM-based effort estimation for article pages”

The description specifies article pages and says nothing about detecting AI authorship. It also points to an internal reference that the public entry does not explain.

The field holds a list of versioned numeric signals. The associated data structure contains a numerical value and a version identifier. That describes how a value can be stored; it supplies neither a score for a particular publisher nor a scale that an SEO tool could reproduce.

In his May 2024 examination of the leak, Mike King distinguished documented attributes from confirmed ranking factors. He noted that the material did not disclose scoring functions or establish whether every available feature was being used. Those omissions prevent a reader from calculating the ranking effect of an individual field.

Even an earlier discussion of contentEffort by Cyrus Shepard included the qualification that it was unknown how, or even whether, Google used the score. The stronger claim needs evidence beyond the field’s existence.

Google’s guidelines allow high-effort AI work

Google’s Search Quality Rater Guidelines address the relationship between AI and effort directly. Section 4.6.6 says:

“the use of Generative AI tools alone does not determine the level of effort or Page Quality rating.”

The same passage says generative AI can be used for both high-quality and low-quality content, including original artwork involving substantial effort. Elsewhere, the guidelines recognize work spent building useful page functionality, such as a machine-translation service.

They also instruct raters to assign the lowest rating when almost all of a page’s main content is republished, paraphrased or generated with virtually no effort, originality or additional value for visitors. Crediting the source does not, by itself, fix that deficiency.

These are instructions for human evaluators. Google says their ratings do not directly influence rankings. They explain what Google wants evaluators to recognize, but they do not disclose the implementation of contentEffort or establish that an LLM follows the same rubric.

The policy risk is scaled content abuse

Google defines scaled content abuse as generating many pages primarily to manipulate rankings rather than help users. Its examples include using generative AI without adding value, transforming scraped material, and combining other pages‘ content without a useful contribution. The policy explicitly covers unoriginal, low-value output however it is created.

It does not set a weekly article allowance. Publishing dozens of articles is therefore insufficient, on its own, to establish a violation. Equally, having someone lightly edit every draft does not resolve a process whose output still meets the policy’s definition.

SEW’s guide to black hat SEO techniques puts scaled content abuse first because a flawed production process can spread the same problem across a large body of work.

Publishers can inspect the contribution, even without the score

The uncertainty around contentEffort leaves publishers without a defensible optimization formula. A more useful editorial decision is where to spend the next hour on an article. Google’s guidance on explaining how content was created gives product reviews a concrete example: show what was tested, the results, and evidence of the process.

For a software review, that could mean running a failed task again, recording the settings and showing the output. A reader can then distinguish a reproducible limitation from a vague complaint. Adding an illustration of someone using a laptop would provide no equivalent evidence about the product.

AI could help organize those test notes or edit the explanation. The contribution would remain the observed behavior and the evidence supporting it. The publisher could document that improvement, but would still have no measurement of whether Google’s contentEffort score changed.

The post Here’s why Google’s contentEffort is not a confirmed ranking factor appeared first on Search Engine Watch.

Source:: searchenginewatch.com

Google AI Mode now shows product comparisons

product comparisons

Google AI Mode now shows comparisons between two or more products. When a user’s query is related to ecommerce, AI Mode now displays this information in a comparison table. This is a genuinely useful feature for showing product comparisons.

Here is a screenshot of how it looks.

Showing this kind of comparison is very helpful for users, making it easier to purchase a better product based on the comparison table provided.

The post Google AI Mode now shows product comparisons appeared first on Search Engine Watch.

Source:: searchenginewatch.com

Google AI Mode now shows long summaries for brand ads

 long summaries for brand ads

Google AI Mode is now showing a longer summary specifically for brand ads. Previously, we spotted a shorter summary appearing below ads for ecommerce queries, but this looks different AI Mode is now showing a longer summary above the ads, and this appears to be limited to brand ads specifically.

Here is a screenshot of this.

Showing this type of extended summary above brand ads could be helpful for advertisers, giving users extra context to read before engaging with the ad.

The post Google AI Mode now shows long summaries for brand ads appeared first on Search Engine Watch.

Source:: searchenginewatch.com

Google’s own NotebookLM becomes a target for parasite SEO

Public reports from Google’s NotebookLM, now branded Gemini Notebook, are being used for parasite SEO. An SEO practitioner described an experiment on September 19 in which a page he published became an AI Overview source within 24 hours, according to his account.

Another SEO practitioner highlighted the broader practice on September 21, sharing search results containing public notebooks about coupons, crypto refunds and backlink tools. His warning prompted the discussion about whether Google would restrict indexing.

Search Engine Watch checked Google while signed out on September 21, using the same site:https://notebook.google.com/notebook/ query shown in the practitioner’s screenshot. The results included coupon pages for e-bikes and peptides, alongside pages promising Instagram likes and private-profile viewing.

The AI Overview example

The first practitioner’s screenshot shows an AI Overview for “best ai seo communities”, with his AI SEO Rainmakers community listed first and a Google Notebook report displayed as a cited source. He said Gemini wrote the content and attributed the result to Google favoring its own domain.

SEW opened a public report matching the title shown in that screenshot. It recommends Rainmakers, compares it with other training resources and ends with a link inviting readers to join. The page identifies its content as AI-generated from user-provided sources and instructions.

SEW has not independently reproduced the AI Overview or verified the claimed turnaround time. The screenshot alone does not establish why Google selected the page or whether the citation persisted.

A coupon report with its own keyword list

One Polish-language report about ENGWE e-bike discounts opened without signing in. It repeatedly promoted a coupon code and linked to the retailer using a referral identifier. A table listed variations of the brand’s coupon keywords across several countries and languages.

The page carried Gemini Notebook branding and a notice identifying its content as AI-generated from user-provided sources and instructions. It was a shareable report at an /artifact/ URL. We did not establish who created it or whether the retailer was involved.

Google introduced public notebook sharing in June 2025, describing uses such as study guides and business manuals. The commercial pages now appearing in Search show another use of that publishing capability.

SEW’s site search confirms that those promotional pages are indexed. Google’s site-operator documentation says a query without additional search terms does not rank its results. Our coupon-page check therefore does not measure competitive rankings or traffic.

Parasite SEO aims to benefit from a host’s existing ranking signals. Google’s spam policies expressly cover its own properties, although a public page or referral link alone does not establish a violation.

A robots.txt block would not necessarily remove the pages

A reply to the practitioner’s post noted that NotebookLM’s robots.txt address redirected to Google sign-in. SEW reproduced that behavior with an ordinary unauthenticated request. We did not verify the response served to Googlebot.

The September 21 post predicts that Google will block crawling or add noindex. Those measures work differently. A robots.txt restriction controls crawling and can leave a URL visible in search results. A noindex instruction removes a page once Google crawls and processes it, which requires the crawler to retain access.

Applying noindex across all public notebooks would also remove legitimate shared material as Google processed the change. That would be a broader decision about public discovery, extending beyond the coupon pages that prompted this discussion.

The post Google’s own NotebookLM becomes a target for parasite SEO appeared first on Search Engine Watch.

Source:: searchenginewatch.com

Google says page errors could explain cross-domain canonical mix-up

Google’s John Mueller has suggested that pages returning the same error message could explain a site owner’s report of Google selecting a page on an unrelated website as canonical for their own pages. He advised checking what Google receives when it loads the affected URLs. The cause of this particular incident remains unconfirmed.

The complaint, covered by Search Engine Journal on September 18, concerned pages about companies and suppliers. Another Reddit participant described a similar experience on their own site, where Google appeared to have grouped pages displaying a generic JavaScript error.

Mueller explained that the normal content would be missing from search results whether Google indexed the error message, classified the page as a soft 404, or selected another URL as canonical.

Google can choose a canonical you never declared

A canonical is the representative URL Google chooses from pages it considers duplicates. A site owner can recommend one using a rel="canonical" link element, but Google can choose a different URL. It can also make that choice without an explicit canonical declaration.

Google’s canonicalization troubleshooting guide specifically lists unrelated servers returning identical error pages as a possible cause of unexpected cross-domain selection. Google may fail to recognize those pages as errors and treat them as duplicates.

Consider two sites with completely different articles whose applications both fail with the same error text. If that message replaces the main content, the pages Google receives can look alike even though their intended content has nothing in common.

A soft 404 is one way Google can classify this failure: a page returns a successful HTTP response, but its content indicates an error or is effectively empty. Google’s crawling documentation lists missing JavaScript and broken database connections among possible causes.

Google also lists incorrect canonical settings and maliciously inserted tags or redirects as causes of unexpected canonical selection. Finding another domain in the report warrants investigation; it does not, by itself, establish which failure occurred.

A live test cannot confirm a canonical fix

Mueller recommended Search Console’s live URL test. That helps show whether the page renders correctly now, but Google’s documentation makes clear that it cannot determine which URL Google will choose as canonical.

Search Console view What to check
Indexed result The last crawl time, user-declared canonical and Google-selected canonical.
Live test The current rendered page, HTML and JavaScript output. It does not verify canonical selection.

For an affected URL, record the indexed result before running Test live URL. Then open View tested page and check whether the screenshot and HTML contain the expected content. A successful test today cannot rule out an error during an earlier crawl.

Google’s troubleshooting guide also says pages may remain grouped as duplicates for up to two weeks after content issues are fixed. That describes re-evaluation of the duplicate grouping, rather than a timetable for recovering rankings.

Check that the article actually loads

Google’s JavaScript guidance warns that applications can return an HTTP 200 status while displaying an error page. An uptime monitor that checks only that response could report success while the article itself is missing.

A useful deployment test would load a representative article and confirm that its expected headline and body appear after rendering. Scheduled checks can catch the same failure after launch. Saving the failed page output and its timestamp would give developers something concrete to compare with application logs and Search Console’s crawl time.

Changing a canonical tag cannot restore article text that the application never displayed. If the rendered page contains only an error, fixing that failure is necessary whichever URL Google selected.

The post Google says page errors could explain cross-domain canonical mix-up appeared first on Search Engine Watch.

Source:: searchenginewatch.com