DEV Community: SEOCode

SEOCode Rules Update v1.3.6

SEOCode — Thu, 18 Jun 2026 20:08:01 +0000

---
title: "Rule Engine Update 1.3.6: HTML Is the SEO Standard, Not Markdown"
date: 2026-06-18
version: 1.3.6
slug: rule-engine-update-1-3-6
description: "SEOCode 1.3.6 adds one new informational rule clarifying that Markdown files served as content carry no SEO advantage over HTML, per Google's own guidance."
tags:
  - rule-engine
  - changelog
  - technical-seo
  - html
  - markdown
---

Rule Engine Update 1.3.6: HTML Is the SEO Standard, Not Markdown

Version 1.3.6 adds one new informational rule based on explicit guidance from Google: serving content as Markdown files provides no SEO advantage over HTML, and HTML remains the canonical document format for Google Search.

New Rules

`html-standard-for-seo` — Markdown files have no SEO advantage over HTML

Severity: Info

Category: Technical

What the rule checks

This rule flags cases where content is being served directly as Markdown files — for example, .md files exposed at a public URL, or llms.txt-style Markdown documents intended to carry indexable content. It surfaces a warning when your repository appears to be routing Markdown files as primary content endpoints rather than rendering them as HTML before serving.

Why it matters for SEO

Google has stated directly that HTML is the standard for SEO, not Markdown. Google's crawlers and ranking systems are built around HTML as the document format of the web. A Markdown file served at a URL is not treated as an equivalent substitute for a properly structured HTML page. If you are publishing content you want to rank — articles, documentation, landing pages — and that content is being delivered as raw Markdown rather than rendered HTML, you are working against how Google's systems are designed to process and evaluate pages.

This rule complements the existing llms-txt-not-required rule. That rule addresses the specific pattern of creating llms.txt files for AI crawlers. This rule addresses the broader question: even setting aside AI-specific files, Markdown as a general content delivery format is not a recommended or advantaged format for SEO.

What you need to do

If this rule fires on your PR, check whether the files being added or modified are:

Served directly as .md files at a public URL — If so, consider whether those files should be rendered to HTML before being served. Most static site generators (Jekyll, Hugo, Eleventy, Next.js, etc.) do this automatically. Verify your build pipeline is not accidentally exposing raw Markdown at canonical URLs.
Intended only as source files — If the .md files are build inputs that get compiled to HTML, and the HTML output is what gets served and indexed, no action is needed. The rule is informational and may not apply to your setup.
Intended as AI-readable documents — See llms-txt-not-required for guidance on that specific pattern.

No code change is required if your Markdown files are already being rendered to HTML by your build process. This rule exists to catch cases where that rendering step is missing or bypassed.

Sources & References

Search Engine Roundtable — "Google: HTML The Standard For SEO, Not Markdown Files" (scraped 2026-06-18)

Catch SEO issues before they ship

SEOCode reviews every pull request against the latest Google SEO rules — automatically. No manual audits. No surprises after deploy.

It checks for missing metadata, broken structured data, hreflang errors, robots.txt issues, and more — right inside your existing GitHub workflow.

Try SEOCode →

SEOCode Rules Update v1.3.5

SEOCode — Thu, 18 Jun 2026 19:38:30 +0000

---
title: "SEOCode Rule Engine Update: v1.3.5"
date: 2026-06-18
version: 1.3.5
slug: rule-engine-update-1-3-5
description: "Version 1.3.5 adds two new rules covering domain migration subdomain variant requirements and the final removal of FAQ rich result documentation from Google Search Central."
tags:
  - rule-engine
  - changelog
  - technical-seo
  - schema
  - domain-migration
---

SEOCode Rule Engine Update: v1.3.5

Version 1.3.5 adds two new rules reflecting changes Google made to its Search Central documentation on 2026-06-18: updated site move guidance that now explicitly requires migrating all subdomain variants, and the complete removal of FAQ rich result documentation confirming the feature is dead.

New Rules

`site-move-domain-variants` — Site move guidance: include all domain variants

Severity: Warning
Category: Technical

What it checks

When SEOCode detects a domain migration in progress (based on redirect configurations, canonical changes, or Search Console Change of Address signals in your codebase), this rule verifies that all subdomain variants of the origin domain are accounted for in the migration. Specifically, it flags cases where www and non-www variants are not both being migrated.

For example: migrating example.com → newdomain.com without also migrating www.example.com → www.newdomain.com (or the appropriate canonical target) will trigger this warning.

Why it matters for SEO

Google's Change of Address tool works at the domain level, but ranking signals are associated with specific URLs — including both www and non-www variants. If you only submit a Change of Address for one variant, Google may consolidate signals for that variant but leave the other behind. The result is a slower, incomplete migration where some of your historical ranking authority doesn't transfer to the new domain.

Google updated its site move documentation on 2026-06-18 to make this requirement explicit. This rule encodes that guidance so incomplete migrations are caught at the PR stage rather than weeks later in Search Console.

What you need to do

If this rule fires on your PR:

Confirm that both www.olddomain.com and olddomain.com have redirects pointing to the correct destination on the new domain.
Submit the Change of Address tool in Google Search Console for each variant separately — the tool does not automatically apply to both.
Ensure canonical tags on the new domain are consistent and point to your preferred variant.

If your site only ever served one variant (e.g., you enforced www everywhere and non-www returned a redirect), document that in your migration plan. The rule accepts a configuration override for sites that can confirm only one variant was ever active.

`faq-rich-result-documentation-removed` — FAQ rich result documentation fully removed

Severity: Info
Category: Schema

What it checks

This rule flags any use of FAQPage structured data in your codebase. It does not block merges. It surfaces as an informational notice to ensure developers are aware that FAQPage schema produces no rich result benefit in Google Search as of this update.

Note: The existing rule faq-schema-deprecated already issues actionable guidance on removing or replacing FAQPage markup. This rule adds a milestone marker: Google has now fully removed the FAQ rich result documentation from Search Central, which is the final confirmation that the feature is gone — not deprecated, not limited, gone.

Why it matters for SEO

When Google deprecates a rich result type, there is typically a window where the documentation remains available and some implementations may still render. That window is now closed for FAQ rich results. The documentation removal on 2026-06-18 is the definitive signal that no implementation of FAQPage structured data will produce a visual rich result in Google Search.

Leaving FAQPage markup in your codebase is not harmful — it won't cause a penalty — but it is dead weight. It adds payload to your pages and creates maintenance surface for structured data that returns nothing.

What you need to do

This rule is informational only. No immediate action is required to merge. However, you should plan to:

Remove FAQPage structured data from your templates and components.
If you were using FAQ rich results as a click-through rate strategy, evaluate alternatives such as HowTo (where applicable and still supported) or improving on-page content directly.
Check your structured data testing pipeline — if you have tests that assert FAQPage schema is present, those tests are now asserting the presence of inert markup and should be updated or removed.

Sources & References

Google Search Central Documentation Changelog

Catch SEO issues before they ship

SEOCode reviews every pull request against the latest Google SEO rules — automatically. No manual audits. No surprises after deploy.

It checks for missing metadata, broken structured data, hreflang errors, robots.txt issues, and more — right inside your existing GitHub workflow.

Try SEOCode →

SEOCode Rules Update v1.3.2

SEOCode — Tue, 09 Jun 2026 17:06:26 +0000

---
title: "SEOCode Rule Engine 1.3.2: Three New Schema Rules for Speakable, IPTC Media Provenance, and Shipping Vocabulary"
date: 2026-06-09
version: 1.3.2
slug: rule-engine-1-3-2
description: "Version 1.3.2 adds three new schema rules covering Google's removal of Speakable rich result support, IPTC digital source type tagging for AI-generated media, and deprecated shipping schema types."
tags: [schema, structured-data, release-notes, ai-content, ecommerce]
---

SEOCode Rule Engine 1.3.2: Three New Schema Rules for Speakable, IPTC Media Provenance, and Shipping Vocabulary

Version 1.3.2 adds three new schema rules that reflect recent changes to schema.org's vocabulary and Google's supported structured data features — covering a removed rich result type, AI-generated media provenance, and deprecated ecommerce shipping types.

New Rules

`speakable-schema-deprecated` — SpeakableSpecification structured data no longer supported

Severity: Warning | Category: Schema

SpeakableSpecification was introduced in schema.org 3.2 and promoted to core in 3.5. It was designed to mark sections of a document as well-suited for text-to-speech rendering. Google has since removed Speakable from its list of supported rich result types and no longer processes SpeakableSpecification for any Search feature.

Why it matters: Implementing this schema type has no effect on how your content appears in Google Search. It is dead weight in your structured data. The type still exists in the schema.org vocabulary and may be consumed by other platforms, but if your goal is Google Search optimization, this markup does nothing.

What to do: If SEOCode flags this rule, audit whether you have a specific non-Google reason to keep SpeakableSpecification markup. If not, remove it to reduce structured data noise.

`schema-org-iptc-digital-source-type` — Missing IPTCDigitalSourceEnumeration for AI-generated media

Severity: Info | Category: Schema

Schema.org 24.0 introduced the IPTCDigitalSourceEnumeration vocabulary with 14 coded values describing the origin of digital media. Schema.org 29.4 added further missing enumeration values. The vocabulary is applied via the digitalSourceType property on MediaObject and its subtypes: ImageObject, VideoObject, and AudioObject.

Relevant values include:

TrainedAlgorithmicMediaDigitalSource — content generated entirely by a trained algorithm (e.g., an AI image generator)
CompositeWithTrainedAlgorithmicMediaDigitalSource — content that combines real-world capture with AI-generated elements

Why it matters: Google uses digitalSourceType as a content provenance signal in its "About this image" feature. Correctly tagging AI-generated or AI-assisted media helps search engines and users understand the origin of your content. This also aligns with C2PA metadata standards, which are increasingly relevant for content authenticity. This rule complements the existing c2pa-metadata rule in SEOCode.

What to do: For any ImageObject, VideoObject, or AudioObject in your structured data that represents AI-generated or AI-assisted media, add the digitalSourceType property with the appropriate IPTCDigitalSourceEnumeration value. If the media is fully human-captured with no algorithmic manipulation, tagging it explicitly is still good practice for provenance clarity.

Example:

{
  "@type": "ImageObject",
  "url": "https://example.com/image.jpg",
  "digitalSourceType": "https://cv.iptc.org/newscodes/digitalsourcetype/trainedAlgorithmicMedia"
}

`schema-org-shipping-vocabulary-updated` — Deprecated shipping schema types in use

Severity: Warning | Category: Schema

Schema.org 29.0 deprecated DeliveryTimeSettings and ShippingRateSettings, replacing them with updated shipping vocabulary types.

Why it matters: Google uses shipping structured data to populate shipping information in merchant listings and product rich results. As Google adopts the updated schema.org vocabulary, relying on deprecated types risks your shipping data being misread or ignored in product search features. The impact may not be immediate, but staying on deprecated types creates technical debt that will need to be resolved before it affects your merchant listings.

What to do: If your product structured data uses DeliveryTimeSettings or ShippingRateSettings, migrate to the replacement types introduced in schema.org 29.0. Refer to the schema.org release notes for the specific replacement type names and property mappings.

Sources & References

Schema.org Release Notes

Catch SEO issues before they ship

SEOCode reviews every pull request against the latest Google SEO rules — automatically. No manual audits. No surprises after deploy.

It checks for missing metadata, broken structured data, hreflang errors, robots.txt issues, and more — right inside your existing GitHub workflow.

Try SEOCode →

SEOCode Rules Update v1.3.0

SEOCode — Tue, 09 Jun 2026 16:29:51 +0000

---
title: "SEOCode Rule Engine 1.3.0: AI Mode preferred sources, hasAdultConsideration schema, and third-party tool guidance"
date: 2026-06-09
version: "1.3.0"
slug: "rule-engine-1-3-0"
description: "Version 1.3.0 adds three new rules covering Google's expanded preferred sources feature, the new hasAdultConsideration merchant listing property, and Google's published guidance on evaluating third-party SEO tools."
tags: ["changelog", "rules", "schema", "technical-seo", "ai-overviews", "structured-data"]
---

SEOCode Rule Engine 1.3.0

Version 1.3.0 adds three rules reflecting changes Google published to its Search Central documentation on 2026-06-09, and updates one existing rule with revised references and fix guidance.

New Rules

`preferred-sources-ai-mode` — Preferred sources not configured for AI Mode and AI Overviews

Severity: Info

Google's preferred sources feature, which previously applied only to standard Google Search, now also applies to AI Overviews and AI Mode. Publishers who qualify and have correctly configured preferred sources can receive increased visibility in AI-generated search results.

What the rule checks:
This rule flags pages where identity signals required for preferred sources eligibility are absent or misconfigured. Specifically, it looks for:

Organization schema with a matching sameAs or url property
Site name schema (WebSite with a name property)
Self-referencing canonical URLs

Why it matters:
AI Overviews and AI Mode are now a significant surface in Google Search. Preferred sources is one of the few explicit mechanisms Google offers publishers to influence how their content is attributed in AI-generated answers. If your identity signals are broken or missing, you cannot benefit from this feature even if your site otherwise qualifies.

What to do:
Check that your site has valid Organization and WebSite structured data on your homepage, and that canonical URLs are correctly set across your pages. Then review Google's eligibility requirements for preferred sources (linked in the references below) to confirm your site qualifies.

`has-adult-consideration-schema` — Missing `hasAdultConsideration` property on adult merchant listings

Severity: Info

Google has added support for the hasAdultConsideration property in merchant listing structured data, aligning it with the existing Merchant Center feed specification.

What the rule checks:
This rule flags Product or Offer structured data on pages that appear to contain adult content but do not include the hasAdultConsideration property.

Why it matters:
Without this property, Google must infer whether a merchant listing contains adult content algorithmically. Incorrect classification can affect where and how your products appear in shopping experiences — either surfacing them in contexts where adult content is filtered out, or failing to apply appropriate filters. Explicit markup removes the ambiguity.

What to do:
If you operate a merchant site with adult product listings, add "hasAdultConsideration": true to the relevant Offer or Product structured data blocks. This is a direct signal to Google rather than leaving classification to inference.

Example:

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Example Product",
  "offers": {
    "@type": "Offer",
    "hasAdultConsideration": true,
    "price": "29.99",
    "priceCurrency": "USD"
  }
}

`third-party-seo-tools-guidance` — Third-party SEO tool recommendations not critically evaluated

Severity: Info

Google has published explicit guidance on how to evaluate recommendations from third-party SEO tools, services, and consultants.

What the rule checks:
This is a process-level rule rather than a markup check. It surfaces as an informational flag when SEOCode detects patterns in your codebase that are commonly associated with outdated or unverified SEO advice — for example, meta tags or structured data patterns that contradict current Google documentation.

Why it matters:
Google's guidance makes four points worth internalizing:

SEO tool recommendations do not necessarily reflect Google's actual ranking signals.
Many recommendations are based on correlation studies, not confirmed causation.
Advice can become outdated as Google's systems evolve.
Google Search Console data and official Search Central documentation should be the primary reference for SEO decisions.

This rule exists to prompt a review when your code contains patterns that may have originated from third-party tool output rather than verified guidance.

What to do:
When this rule fires, cross-reference the flagged pattern against the Google Search Central documentation. If the pattern is not supported or recommended there, treat it as unverified. No code change is automatically required — this rule is informational and intended to prompt a review step.

Updated Rules

`preferred-sources-feature` — Missing preferred sources markup or configuration

The existing rule covering preferred sources configuration has been updated with revised references, an updated description, and a new fix template to reflect Google's expansion of the feature to AI Overviews and AI Mode. The underlying check logic is unchanged; the update ensures the guidance surfaced in pull request comments points to current documentation.

What to do:
No action required unless this rule is already firing on your PRs. If it is, the updated fix template provides more accurate remediation steps than the previous version.

Sources & References

Google Search Central Documentation Changelog

Catch SEO issues before they ship

SEOCode reviews every pull request against the latest Google SEO rules — automatically. No manual audits. No surprises after deploy.

It checks for missing metadata, broken structured data, hreflang errors, robots.txt issues, and more — right inside your existing GitHub workflow.

Try SEOCode →

DEV Community: SEOCode

SEOCode Rules Update v1.3.6

Rule Engine Update 1.3.6: HTML Is the SEO Standard, Not Markdown

New Rules

html-standard-for-seo — Markdown files have no SEO advantage over HTML

What the rule checks

Why it matters for SEO

What you need to do

Sources & References

Catch SEO issues before they ship

SEOCode Rules Update v1.3.5

SEOCode Rule Engine Update: v1.3.5

New Rules

site-move-domain-variants — Site move guidance: include all domain variants

What it checks

Why it matters for SEO

What you need to do

faq-rich-result-documentation-removed — FAQ rich result documentation fully removed

What it checks

Why it matters for SEO

What you need to do

Sources & References

Catch SEO issues before they ship

SEOCode Rules Update v1.3.2

SEOCode Rule Engine 1.3.2: Three New Schema Rules for Speakable, IPTC Media Provenance, and Shipping Vocabulary

New Rules

speakable-schema-deprecated — SpeakableSpecification structured data no longer supported

schema-org-iptc-digital-source-type — Missing IPTCDigitalSourceEnumeration for AI-generated media

schema-org-shipping-vocabulary-updated — Deprecated shipping schema types in use

Sources & References

Catch SEO issues before they ship

SEOCode Rules Update v1.3.0

SEOCode Rule Engine 1.3.0

New Rules

preferred-sources-ai-mode — Preferred sources not configured for AI Mode and AI Overviews

has-adult-consideration-schema — Missing hasAdultConsideration property on adult merchant listings

third-party-seo-tools-guidance — Third-party SEO tool recommendations not critically evaluated

Updated Rules

preferred-sources-feature — Missing preferred sources markup or configuration

Sources & References

Catch SEO issues before they ship

`html-standard-for-seo` — Markdown files have no SEO advantage over HTML

`site-move-domain-variants` — Site move guidance: include all domain variants

`faq-rich-result-documentation-removed` — FAQ rich result documentation fully removed

`speakable-schema-deprecated` — SpeakableSpecification structured data no longer supported

`schema-org-iptc-digital-source-type` — Missing IPTCDigitalSourceEnumeration for AI-generated media

`schema-org-shipping-vocabulary-updated` — Deprecated shipping schema types in use

`preferred-sources-ai-mode` — Preferred sources not configured for AI Mode and AI Overviews

`has-adult-consideration-schema` — Missing `hasAdultConsideration` property on adult merchant listings

`third-party-seo-tools-guidance` — Third-party SEO tool recommendations not critically evaluated

`preferred-sources-feature` — Missing preferred sources markup or configuration