Skip to content
Eminence Astro Suite

Unsupported Tags

This page documents metadata tags that Eminence Astro Suite does not support by design. The project prioritizes modern, standards-oriented metadata and does not plan to support legacy or insecure platform behaviors. This keeps the integration smaller, easier to maintain, and aligned with current browser capabilities.

Modern alternatives to these tags are already implemented in the integration or available via standard components and should be used instead.

The tags listed here are considered outdated, legacy conventions, or fall outside the specific scope of their respective components.

Apple Web App Tags

Section titled “Apple Web App Tags”

Commonly referred to as “standalone mode” tags, these were used by early versions of iOS to manage how a website behaves when added to the home screen.

Included tags:

  • meta name="apple-mobile-web-app-title"
  • meta name="apple-touch-startup-image"
  • meta name="apple-mobile-web-app-capable"
  • meta name="apple-mobile-web-app-status-bar-style"

Reason

Section titled “Reason”

These are legacy Apple-specific tags that have been superseded by the Web App Manifest standard. The package intentionally avoids mixing unrelated Apple web app concerns with specific components like AppleItunesApp.

Section titled “Recommended Alternative”

Use standards-based web app metadata through the integration:

References

Section titled “References”

Web App Tags

Section titled “Web App Tags”

Included tags:

  • meta name="application-name"

Reason

Section titled “Reason”

This tag is excluded because modern browsers and platforms rely on the Web App Manifest for installable app metadata. The name and short_name fields in manifest.webmanifest supersede the need for meta name="application-name".

Section titled “Recommended Alternative”

Use standards-based app naming metadata through your web app manifest:

References

Section titled “References”

Administrative Author Metadata

Section titled “Administrative Author Metadata”

Included tags:

  • meta name="author"

Reason

Section titled “Reason”

The author meta tag is largely administrative metadata and is not used by major search engines as a ranking signal.

Modern search and trust systems rely on stronger signals than a hidden head tag. Visible bylines, dedicated author profile pages, structured data such as Schema.org JSON-LD, and social metadata like Open Graph author properties provide much clearer and more machine-readable authorship context.

Because meta name="author" does not meaningfully affect browser behavior, ranking, or modern metadata interoperability, this package does not include an Author component.

Section titled “Recommended Alternative”

Use stronger authorship signals instead:

  • visible bylines and linked author profile pages
  • Schema.org JSON-LD for Article, NewsArticle, or related content types
  • Open Graph article or book author properties where applicable

References

Section titled “References”

Feed Discovery Alternates

Section titled “Feed Discovery Alternates”

Link tags used for auto-discovery of RSS or Atom feeds: <link rel="alternate" type="application/rss+xml">.

Reason

Section titled “Reason”

The LanguageAlternates component is deliberately scoped to hreflang alternates for localization only. Adding feed discovery would broaden the component’s responsibility beyond its primary purpose.

Section titled “Recommended Alternative”

Emit feed alternates manually or use dedicated feed generation tooling.

References

Section titled “References”
Section titled “Archive Link Relation”

Included tags:

  • <link rel="archives" href="...">

Reason

Section titled “Reason”

While this tag is still technically valid HTML, it has effectively become a ghost tag in modern browsers and search ecosystems.

Current browsers do not provide special handling for rel="archives": no navigation affordance, no dedicated UI, and no prioritization behavior. Search engines also rely on internal links and sitemaps for archive discovery, so this relation contributes negligible SEO value.

Because it does not provide meaningful browser or crawler behavior in current practice, this package does not include an Archives component.

Section titled “Recommended Alternative”

Use modern, explicit structure signals instead:

  • nav landmarks with standard links to archive pages
  • structured data such as JSON-LD where hierarchy context is needed
  • sitemap.xml entries for archive URLs

References

Section titled “References”
Section titled “Assets Link Relation”

Included tags:

  • <link rel="assets" href="...">

Reason

Section titled “Reason”

rel="assets" is not part of the HTML standard and has never been a recognized relation type in W3C or WHATWG specifications.

In practice, when this relation appears in codebases, it is usually for private tooling conventions (for example custom framework hooks, build scripts, or niche asset discovery pipelines), not for interoperable browser behavior. Browsers do not provide built-in support for this relation, and search engines do not use it as a meaningful ranking or discovery signal.

Because this tag is non-standard and provides no meaningful browser or SEO benefit, this package does not include an Assets component.

Section titled “Recommended Alternative”

Use standard mechanisms that have real browser and crawler behavior:

  • rel="preload" or rel="prefetch" for asset loading priority
  • rel="manifest" for progressive web app metadata and icons
  • standard script and stylesheet loading with integrity attributes where applicable

References

Section titled “References”
Section titled “Bookmarks Link Relation”

Included tags:

  • <link rel="bookmarks" href="...">

Reason

Section titled “Reason”

While rel="bookmarks" appears in historical HTML specifications as a registered link relation, modern browsers do not provide special handling for this relation type.

No browser renders a UI affordance for bookmarks relations, and crawler behavior treats it like any other link. Users rely on their browser bookmarks managers and content discovery systems, not on website-provided bookmarks relations. Search engines do not use this relation as a ranking or discovery signal.

Because it lacks meaningful browser behavior and does not improve user experience or SEO, this package does not include a Bookmarks component.

Section titled “Recommended Alternative”

If you need to help users discover important pages or sections:

  • Use clear navigation landmarks with semantic nav elements and standard links
  • Provide a dedicated bookmarks or favorites page with descriptive, linked content
  • Use schema.org structured data to mark important content sections or collections
  • Consider a sitemap or topic index page for comprehensive navigation

References

Section titled “References”

Administrative Creator Metadata

Section titled “Administrative Creator Metadata”

Included tags:

  • meta name="creator"

Reason

Section titled “Reason”

The creator meta tag is administrative metadata with little to no practical effect in modern browsers, search engines, or social platforms.

Current crawlers and ranking systems do not rely on hidden meta name="creator" values for trust, authorship, or discoverability. When creator identity matters, stronger signals such as visible credits, organization pages, structured data, and platform-specific metadata are more explicit and interoperable.

Because meta name="creator" does not materially affect browser behavior or modern metadata consumption, this package does not include a Creator component.

Section titled “Recommended Alternative”

Use stronger creator and ownership signals instead:

  • visible credit lines or organization attribution in page content
  • Schema.org JSON-LD for Organization, Person, CreativeWork, Article, or related content types
  • Open Graph metadata where creator or publisher context is relevant

References

Section titled “References”

Facebook Admin Metadata

Section titled “Facebook Admin Metadata”

Included tags:

  • meta property="fb:app_id"
  • meta property="fb:admins"

Reason

Section titled “Reason”

These Facebook-specific admin tags are platform-scoped metadata and do not provide general SEO value or meaningful browser behavior.

They are only relevant to narrow Facebook ownership/admin workflows and are not part of broader, standards-based metadata ecosystems used across modern crawlers and clients.

Because they are proprietary and outside this package’s standards-first scope, this package does not include a Facebook component.

Section titled “Recommended Alternative”

Use broadly interoperable metadata instead:

  • Open Graph core metadata through the OpenGraph component
  • standards-based structured data such as Schema.org JSON-LD where ownership or organization context is needed
  • platform-specific setup in the platform’s dashboard when available

References

Section titled “References”

Pinterest Rich Pin Opt-Out Metadata

Section titled “Pinterest Rich Pin Opt-Out Metadata”

Included tags:

  • meta name="pinterest-rich-pin" content="false"

Reason

Section titled “Reason”

This tag is still technically relevant in 2026, but only as a niche Pinterest-specific kill switch to disable Rich Pins.

Most sites benefit from Rich Pins because they can improve metadata consistency and content visibility on Pinterest. In this package, the default approach is to focus on broadly useful, standards-oriented metadata rather than platform-specific opt-out flags.

Because this behavior is both niche and easy to add manually when needed, this package does not include a Pinterest component.

Section titled “Recommended Alternative”

If you need to disable Rich Pins for a specific project, add the tag manually in your page <head>:

  • <meta name="pinterest-rich-pin" content="false" />

References

Section titled “References”
Section titled “Legacy App Links Metadata”

Included tags:

  • meta property="al:ios:url"
  • meta property="al:ios:app_store_id"
  • meta property="al:android:url"
  • meta property="al:android:package"
  • meta property="al:web:url"
  • meta property="al:web:should_fallback"

Reason

Section titled “Reason”

App Links metadata tags were introduced as an early deep-linking convention, primarily in social crawler ecosystems. They still work in some contexts, but they are now legacy relative to modern platform-native deep-linking standards.

Modern deep linking on iOS and Android is based on verified domain association, not HTML metadata tags. Those native systems are more secure, avoid URI-scheme hijacking issues, and provide smoother user experience by opening apps directly when associations are valid.

Because this package prioritizes standards-oriented metadata with broad long-term value, App Links tags are no longer supported as a built-in component.

Section titled “Recommended Alternative”

Use native deep-linking configuration as your primary strategy:

  • iOS Universal Links via apple-app-site-association
  • Android App Links via assetlinks.json
  • standard web fallback routing in your app/site logic

Use platform metadata only when needed for a specific ecosystem behavior.

If your project depends on Meta/Facebook share flows, you may still add legacy al:* tags manually for compatibility as a secondary fallback.

References

Section titled “References”

Publisher Metadata

Section titled “Publisher Metadata”

Included tags:

  • meta name="publisher"

Reason

Section titled “Reason”

meta name="publisher" is still valid HTML, but it is a legacy-style metadata pattern with limited modern impact.

Major search engines do not use this tag as a ranking signal, and modern publisher identity features rely on stronger structured signals. While some niche tools (such as internal CMS workflows, browser scrapers, and some citation systems) may still read it, it is generally non-essential for mainstream SEO.

Because this package prioritizes modern, broadly useful metadata, it does not include a Publisher component.

Section titled “Recommended Alternative”

Use Schema.org JSON-LD for publisher and organization identity, for example Organization linked with canonical site information.

If your workflow still requires this meta tag for niche tooling, add it manually in your page head.

References

Section titled “References”
Section titled “Sitemap Link Relation”

Included tags:

  • <link rel="sitemap" href="...">

Reason

Section titled “Reason”

While <link rel="sitemap"> is technically valid HTML, it is not an authoritative sitemap discovery mechanism. The official Sitemaps.org protocol, agreed upon by Google, Microsoft, and Yahoo, defines only two recognized discovery methods: listing the sitemap URL in robots.txt and direct submission via a search engine’s webmaster console (such as Google Search Console or Bing Webmaster Tools).

Major crawlers such as Googlebot do not use the <link rel="sitemap"> tag for discovery. The tag originates from Semantic Web conventions and is occasionally read by third-party site auditing tools, but it provides no benefit for search engine indexing. Adding it to every page’s <head> would be pure bloat with no practical effect on crawlability.

Section titled “Recommended Alternative”

Announce your sitemap through the two authoritative methods:

References

Section titled “References”