Enar SEO Türkçe

Free Tool

SEO Competitor Comparison Tool

Audit your site and your competitors with the same comprehensive set of checks and compare them side by side: redirects, broken and redirected links, canonicals, Open Graph, status codes of URLs in structured data, HTML size, robots.txt, sitemaps and more. For every check, we show which brand gets it more right.

If you enter a domain (e.g. examplebrand.com), the home page is analyzed. To compare similar pages, enter full addresses (e.g. one news article from each of three brands).

Optional. Chooses which device the page is requested as. Google crawls most sites with its mobile crawler, so the default is Mobile; change it only if you want to see the desktop version as well.

When you enter an address, the page is requested through the Enar SEO server, just like a browser would (because browsers' security rules prevent reading data from other sites directly). The fetched content and addresses are not stored; the analysis runs in your browser. Link checks are rate-limited to be gentle on the sites.

How do we compare?

  1. We fetch the page like a mobile browser. Starting from the address you entered, we record every redirect one by one, and we also probe the http and www/non-www versions separately.
  2. We read robots.txt and the sitemap. If the sitemap is an index, we open the first child sitemap and take a sample of its URLs.
  3. We check the addresses one by one. We measure the HTTP status (2xx, 3xx, 4xx, 5xx) of the page's internal and external links, CSS/JS/image files, URLs in structured data (JSON-LD), canonical and og:image targets, and the sitemap sample.
  4. We analyze the HTML. The head section, meta and Open Graph tags, structured data, headings, images, accessibility and the HTML size breakdown are extracted using the same method.
  5. We score and compare against the rules. Each check is marked as “passed, warning, issue, info”, and the brand that does it best is highlighted in the row.

Ratings

Each scored check has a weight from 1 to 3 depending on its importance: passed gets full points, warning half points and issue zero. “Info” and “not applicable” rows don't affect the score; for example, hreflang isn't expected on a single-language site, nor BreadcrumbList on a home page. Category and overall scores are the weighted average expressed out of 100.

The “Best” label in a row shows the brand that implements that check more correctly than the others: status is compared first (passed > warning > issue), and on a tie the measurable value decides (fewer broken links, smaller HTML, faster response and so on). If all brands are equal, no label is shown.

Kategoriler

  • Crawling and Indexing: Whether search engines can reach the page and index the right address, and how clean the redirects are.
  • Meta Tags and Snippets: The title and description shown in search results, plus the basic instructions given to the browser.
  • Social Sharing (Open Graph and X): The title, description and image shown when a link is shared on social networks or messaging apps.
  • Structured Data: schema.org markup: describing the page and the brand to search engines in machine-readable form.
  • Link Health: The HTTP status of the page's links and resources: broken, redirected, unreachable.
  • Speed and HTML Size: HTML size, server response time, compression, and resources and images that delay rendering.
  • HTML Hygiene and Accessibility: Heading hierarchy, alt text, semantic tags and the correctness of the head section.
  • GEO / AI Readiness: Whether AI search and answer engines can access the site and correctly recognize the brand.

Where the rules come from

The checks are based on the Enar SEO checklist, compiled from Google Search Central and web.dev documentation, W3C accessibility guidelines, the findings of independent technical SEO audits of large publisher sites, and the technical SEO task list applied on those sites. Where recommendations conflict, a single decision is applied (e.g. no maximum-scale in the viewport, changefreq/priority are unnecessary in sitemaps, AMP isn't required).

What you need to know

  • The analysis uses the initial HTML the server sends; content added later with JavaScript isn't evaluated.
  • Timings (TTFB) are measured from the Enar SEO server and may differ depending on your visitors' location.
  • Some social networks and firewalls return 403/429 to automated requests; these addresses are shown separately as “couldn't verify” and aren't counted as broken.
  • On large sites, links are checked up to the limit you choose rather than all of them; the result states how many links were checked.

Comparison criteria

The correct implementation of each check, why it matters and the source it's based on:

Crawling and Indexing

Whether search engines can reach the page and index the right address, and how clean the redirects are.

The page's HTTP status code weight 3/3
Correct implementation: The analyzed page should return 200 (OK).
Why does it matter? A page that returns 4xx or 5xx isn't indexed, and if server errors persist, Google crawls the site less often.
Source: Google: HTTP status codes and network errors · Google Search Central
Redirect from the entered address to the page weight 2/3
Correct implementation: At most one permanent (301/308) redirect; there should be no chains and no temporary (302/307) redirects.
Why does it matter? Every extra redirect adds delay for both visitors and Googlebot. A temporary redirect leaves it unclear which address is the real one.
Source: Google: Redirects and Google Search · Google Search Central, Independent technical SEO audits, Technical SEO task list applied on publisher projects
Use of HTTPS weight 3/3
Correct implementation: The page should load over https://.
Why does it matter? HTTPS is a page experience signal; browsers flag http pages as “not secure”.
Source: Google: Page experience · Google Search Central, Technical SEO task list applied on publisher projects
http → https redirect weight 2/3
Correct implementation: The http:// address should go to the final https address in a single step, with a permanent (301/308) redirect.
Why does it matter? Old links and people typing the address by hand should reach the secure, canonical version in one hop; intermediate steps create a chain.
Source: Google: Redirects and Google Search · Google Search Central, Independent technical SEO audits
www and non-www consolidation weight 2/3
Correct implementation: The alternate version (with or without www) should permanently redirect to the main version.
Why does it matter? If both versions return 200, the same site is published at two addresses, splitting link equity and crawl budget.
Source: Google: Consolidating duplicate URLs (canonical) · Google: Redirects and Google Search · Google Search Central
Separate mobile site (m.) weight 1/3
Correct implementation: A responsive design on a single URL; if there's a separate mobile site, each m. page should point to its desktop counterpart with canonical, and each desktop page to its m. page with rel=alternate.
Why does it matter? Google uses mobile-first indexing and recommends responsive design. Separate m. sites are prone to redirect, mapping and content-mismatch errors between the two versions. (Detected only with a mobile user agent.)
Source: Google: Mobile-first indexing best practices · Google Search Central
HSTS security header weight 1/3
Correct implementation: A Strict-Transport-Security header should be sent (e.g. max-age=31536000; includeSubDomains).
Why does it matter? Forces the browser to always connect to the site over HTTPS, removing the http→https redirect step.
Source: MDN: Strict-Transport-Security · MDN Web Docs, Independent technical SEO audits
Indexability (robots meta and X-Robots-Tag) weight 3/3
Correct implementation: The page should have no noindex or none directive.
Why does it matter? A page with noindex is removed from search results.
Source: Google: robots meta tag and X-Robots-Tag · Google Search Central
Canonical tag weight 3/3
Correct implementation: A single, absolute (https://…) canonical in the head that points to the page itself.
Why does it matter? Tells Google which address is the real one. A missing, multiple or conflicting canonical leads to duplicate content problems.
Source: Google: Consolidating duplicate URLs (canonical) · Google Search Central, Independent technical SEO audits, Technical SEO task list applied on publisher projects
Status of the canonical target weight 2/3
Correct implementation: The address the canonical points to should return 200, not a redirect or an error.
Why does it matter? Pointing to a redirecting or erroring address as the “real” one sends Google conflicting signals, and the canonical may be ignored.
Source: Google: Consolidating duplicate URLs (canonical) · Google Search Central
robots.txt file weight 2/3
Correct implementation: There should be an accessible (200) robots.txt in the root directory, and it shouldn't return a 5xx error.
Why does it matter? If robots.txt returns a server error (5xx), Google may not crawl the site at all for a while. A missing file (404) means “everything can be crawled”.
Source: Google: How robots.txt is interpreted · Google Search Central, Independent technical SEO audits
Does robots.txt block the page? weight 3/3
Correct implementation: The analyzed page should be crawlable for Googlebot.
Why does it matter? The content of a page blocked by robots.txt can't be read; even if it appears in the index, it will be a weak result without a description.
Source: Google: How robots.txt is interpreted · Google Search Central
Sitemap declared in robots.txt weight 1/3
Correct implementation: robots.txt should contain at least one “Sitemap:” line.
Why does it matter? Lets every search engine find the sitemap on its own.
Source: Google: Building a sitemap · Google Search Central, Independent technical SEO audits
XML sitemap weight 2/3
Correct implementation: A valid XML sitemap (urlset or sitemap index) should be live.
Why does it matter? A sitemap helps new and updated pages get discovered quickly; it's critical for large, frequently updated sites.
Source: Google: Building a sitemap · Google Search Central, Independent technical SEO audits
Nested sitemap index weight 2/3
Correct implementation: A sitemap index should only point to sitemaps that contain URL lists (urlset); an index shouldn't list another index.
Why does it matter? Google doesn't support nested sitemap index files (the “Nested sitemap indexes” error in Search Console); URLs in a child index aren't read this way.
Source: Google: Managing large sitemaps with a sitemap index · Google Search Central, Independent technical SEO audits
lastmod in the sitemap weight 1/3
Correct implementation: A <lastmod> on every URL showing the page's actual last-modified date.
Why does it matter? Google uses reliable lastmod values when deciding which pages to recrawl.
Source: Google: Building a sitemap · Google Search Central, Independent technical SEO audits
changefreq / priority in the sitemap weight 1/3
Correct implementation: Shouldn't be used.
Why does it matter? Google ignores changefreq and priority values; they just make the file bigger.
Source: Google: Building a sitemap · Google Search Central, Independent technical SEO audits
Status of URLs in the sitemap (sample) weight 2/3
Correct implementation: The sitemap should contain only canonical URLs that return 200.
Why does it matter? Redirected or erroring URLs reduce trust in the sitemap and waste crawl budget.
Source: Google: Building a sitemap · Google Search Central, Independent technical SEO audits, Technical SEO task list applied on publisher projects
Google News sitemap info only, not scored
Correct implementation: A News sitemap containing articles from the last 48 hours is recommended for news publishers.
Why does it matter? Helps articles get discovered quickly in Google News and the News tab. Not needed if it isn't a news site.
Source: Google: News sitemap · Google Search Central
hreflang implementation weight 1/3
Correct implementation: On multilingual sites, each version should reference itself and the other versions, there should be an x-default, and the targets should return 200.
Why does it matter? Ensures the right language/country version is shown to the right user. Not needed on single-language sites.
Source: Google: Localized versions (hreflang) · Google Search Central
Meta refresh redirect weight 1/3
Correct implementation: Shouldn't be used; if a redirect is needed, prefer a server-side 301.
Why does it matter? Meta refresh is slow, causes accessibility problems and gives search engines a weak redirect signal.
Source: Google: Redirects and Google Search · MDN: meta refresh · Google Search Central
AMP version info only, not scored
Correct implementation: Not required; speed problems should be solved on the main (canonical) page.
Why does it matter? AMP is no longer required for Top Stories, and maintaining two separate versions is a burden.
Source: Google: AMP and Google Search · Google Search Central, Independent technical SEO audits
Meta Tags and Snippets

The title and description shown in search results, plus the basic instructions given to the browser.

Title tag weight 3/3
Correct implementation: A single, page-specific title of roughly 30–65 characters that fits within ~580 pixels, with the search term first.
Why does it matter? It's the main source of the clickable title in search results. If it's too long it gets truncated; if it's missing, Google generates one itself.
Source: Google: Title links · Google Search Central, Independent technical SEO audits
Meta description weight 2/3
Correct implementation: A single, page-specific summary of roughly 70–160 characters.
Why does it matter? It may be shown as the description in search results and affects click-through rate.
Source: Google: Snippets and meta descriptions · Google Search Central, Independent technical SEO audits
Meta keywords weight 1/3
Correct implementation: Shouldn't be used.
Why does it matter? Google doesn't use this tag for ranking, and it reveals your keyword strategy to competitors.
Source: Google: Meta tags Google supports · Google Search Central, Independent technical SEO audits
Viewport tag weight 3/3
Correct implementation: width=device-width, initial-scale=1; zooming shouldn't be restricted with maximum-scale or user-scalable=no.
Why does it matter? It's the foundation of mobile-friendliness. Blocking zoom is an accessibility violation for visually impaired users (WCAG 1.4.4).
Source: MDN: Viewport meta tag · WCAG 2.2: Resize text (1.4.4) · MDN Web Docs, W3C (WCAG, HTML), Independent technical SEO audits, Technical SEO task list applied on publisher projects
Language declaration (html lang) weight 2/3
Correct implementation: A valid language code, such as <html lang="en">.
Why does it matter? Helps screen readers pronounce text correctly, and browser translation and search engines detect the language correctly.
Source: MDN: The lang attribute · MDN Web Docs, W3C (WCAG, HTML)
Character encoding weight 1/3
Correct implementation: UTF-8, declared with <meta charset> within the first 1024 bytes of the document or in an HTTP header.
Why does it matter? If it isn't declared, accented and non-Latin characters may display incorrectly, and the browser may have to re-parse the page.
Source: MDN: meta charset · MDN Web Docs
Favicon weight 1/3
Correct implementation: An accessible (200) icon declared with rel=icon; SVG with an ICO fallback is recommended.
Why does it matter? Google shows the favicon next to the site in search results, which affects recognition and clicks.
Source: Google: Favicons in search results · Google Search Central, Technical SEO task list applied on publisher projects
Mobile icon set (apple-touch-icon, manifest, theme-color) weight 1/3
Correct implementation: apple-touch-icon, a web app manifest and theme-color should be used together.
Why does it matter? Keeps the brand consistent for users who add the site to their home screen and in the mobile browser interface.
Source: web.dev: Web app manifest · web.dev / Chrome for Developers
Large image preview permission (max-image-preview:large) weight 1/3
Correct implementation: max-image-preview:large in the robots meta tag.
Why does it matter? Allows large images in Google Discover and search results, which noticeably increases clicks on news and content sites.
Source: Google: Google Discover · Google: robots meta tag and X-Robots-Tag · Google Search Central
Social Sharing (Open Graph and X)

The title, description and image shown when a link is shared on social networks or messaging apps.

Open Graph basic set weight 2/3
Correct implementation: og:title, og:description, og:image, og:type, og:url, og:site_name and og:locale should be used together.
Why does it matter? Platforms such as Facebook, LinkedIn, WhatsApp and Telegram build the share card from these tags. If they're missing, the card looks empty or wrong.
Source: Open Graph protocol · Open Graph protocol, Independent technical SEO audits, Technical SEO task list applied on publisher projects
og:image availability and size weight 2/3
Correct implementation: An image with an absolute https URL that returns 200 and is at least 1200 pixels wide, with og:image:width/height declared.
Why does it matter? The image is the element of a share card that most affects clicks. An unreachable or small image ruins the card.
Source: Open Graph protocol · Google: Google Discover · Open Graph protocol, Google Search Central
og:url and canonical consistency weight 1/3
Correct implementation: og:url should point to the same address as the canonical.
Why does it matter? Makes sure shares (like and comment counts) are collected on a single address.
Source: Open Graph protocol · Google: Consolidating duplicate URLs (canonical) · Open Graph protocol
X (Twitter) card tags weight 1/3
Correct implementation: twitter:card (preferably summary_large_image); the title, description and image can also be read from Open Graph.
Why does it matter? Makes links shared on X appear as cards with a large image.
Source: X: Card markup · Technical SEO task list applied on publisher projects
Article time tags (article:*) weight 1/3
Correct implementation: article:published_time and article:modified_time on article pages (plus author and section).
Why does it matter? Sharing platforms and some search surfaces read the publication/update date from these tags.
Source: Open Graph protocol · Open Graph protocol, Technical SEO task list applied on publisher projects
Structured Data

schema.org markup: describing the page and the brand to search engines in machine-readable form.

JSON-LD structured data weight 3/3
Correct implementation: The page should have at least one valid JSON-LD block (the format Google recommends).
Why does it matter? Structured data describes the page and the brand to search engines in machine-readable form; it's a prerequisite for rich results.
Source: Google: Introduction to structured data · Google Search Central, Independent technical SEO audits
JSON-LD syntax weight 3/3
Correct implementation: All blocks should be valid JSON.
Why does it matter? A single comma or quote error causes the entire block to be ignored.
Source: Google: Structured data guidelines · Google Search Central
Structure linked with @graph and @id weight 1/3
Correct implementation: Entities (Organization, WebSite, WebPage, Article…) in a single @graph, linked to each other with @id references.
Why does it matter? Ensures the same brand is defined with a single identity on every page and makes the relationships between entities clear.
Source: Enar SEO: JSON-LD architecture with @graph · Google: Introduction to structured data · Independent technical SEO audits
Organization (publisher) schema weight 2/3
Correct implementation: Organization (or a subtype such as NewsMediaOrganization): name, url and logo; ideally also sameAs and contact information.
Why does it matter? It's the primary source for Google to recognize the brand (logo, official profiles) and for the knowledge panel.
Source: Google: Organization structured data · Google Search Central, Independent technical SEO audits, Technical SEO task list applied on publisher projects
Is the Organization name the brand name? weight 1/3
Correct implementation: The name field should contain the brand name, not the domain (example.com).
Why does it matter? Google and AI models match the brand by this name; a domain name weakens the brand entity.
Source: Google: Organization structured data · Google Search Central, Technical SEO task list applied on publisher projects
sameAs (official profiles) weight 1/3
Correct implementation: sameAs links in Organization to official profiles such as social networks and Wikipedia/Wikidata.
Why does it matter? Confirms that the brand's accounts on different platforms belong to the same entity (knowledge graph, GEO).
Source: Google: Organization structured data · Google Search Central, Independent technical SEO audits
WebSite schema (site name) weight 2/3
Correct implementation: WebSite schema (name, url) on the home page.
Why does it matter? Google determines the site name shown in search results from this schema. It's only needed on the home page.
Source: Google: Site names (WebSite) · Google Search Central, Independent technical SEO audits
BreadcrumbList weight 1/3
Correct implementation: A BreadcrumbList on inner pages that matches the visible breadcrumb.
Why does it matter? Shows a readable path instead of the URL in search results and describes the site hierarchy.
Source: Google: Breadcrumb structured data · Google Search Central, Independent technical SEO audits, Technical SEO task list applied on publisher projects
Article / NewsArticle schema weight 2/3
Correct implementation: Article/NewsArticle/BlogPosting on article pages, including headline, image, datePublished and author (by name).
Why does it matter? Helps news and articles appear in Top Stories, Discover and rich results with the correct date and author.
Source: Google: Article structured data · Google Search Central, Independent technical SEO audits
Empty fields weight 2/3
Correct implementation: Fields that can't be filled shouldn't be written at all; don't publish empty strings, empty arrays or null.
Why does it matter? Empty fields trigger validation warnings and reduce the data's reliability.
Source: Google: Structured data guidelines · Google Search Central, Technical SEO task list applied on publisher projects
Status of URLs in structured data weight 2/3
Correct implementation: Addresses in fields such as url, logo, image, sameAs and item should return 200, with no redirects, errors or http://.
Why does it matter? Google ignores unreachable addresses, and redirected logos and images weaken rich result eligibility.
Source: Google: Structured data guidelines · Google Search Central, Technical SEO task list applied on publisher projects
Use of Microdata / RDFa info only, not scored
Correct implementation: Informational: JSON-LD is preferred; if microdata is used, it shouldn't conflict with the JSON-LD.
Why does it matter? Marking up the same entity in two different formats with different values causes confusion.
Source: Google: Introduction to structured data · Google Search Central
Speed and HTML Size

HTML size, server response time, compression, and resources and images that delay rendering.

Server response time (TTFB) weight 2/3
Correct implementation: 800 ms or less (web.dev's “good” threshold).
Why does it matter? The later the server sends the first byte, the later the rest of the page arrives. It's measured from the Enar SEO server and varies with the visitor's location.
Source: web.dev: Time to First Byte (TTFB) · web.dev / Chrome for Developers
HTML size (raw) weight 2/3
Correct implementation: Raw HTML is ideally under 125 KB and should never exceed 2 MB.
Why does it matter? Googlebot reads only the first 2 MB, and Bing warns above 125 KB. Large HTML also slows down how quickly the browser processes the page.
Source: Google: Googlebot (2 MB limit) · Enar SEO: HTML Size Analyzer tool · Google Search Central
Transferred HTML size (compressed) weight 1/3
Correct implementation: Compressed HTML as small as possible: under ~50 KB is good, over 150 KB is heavy.
Why does it matter? This is the actual data visitors download over the network; on mobile connections it directly affects how soon they see the first view.
Source: Chrome: Enable text compression · Enar SEO: HTML Size Analyzer tool · web.dev / Chrome for Developers
Text compression (gzip / Brotli / zstd) weight 2/3
Correct implementation: HTML should be sent compressed; Brotli or zstd is preferred.
Why does it matter? Compression usually shrinks HTML by 70–85%. Brotli produces 15–20% smaller output than gzip.
Source: Chrome: Enable text compression · web.dev / Chrome for Developers
DOM size (element count) weight 1/3
Correct implementation: Under 800 elements is good; over 1,400 is an “excessive DOM size”.
Why does it matter? A large DOM means more memory, longer style calculations and slower interactions (INP).
Source: Chrome: Avoid an excessive DOM size · web.dev / Chrome for Developers
Inline code weight (CSS + JS + JSON) weight 1/3
Correct implementation: The CSS, JavaScript and JSON data embedded in the HTML should stay under ~50 KB in total.
Why does it matter? Inline code can't be cached, is downloaded again on every page view and pushes the actual content toward the end of the HTML.
Source: Enar SEO: HTML Size Analyzer tool · Chrome: Render-blocking resources · web.dev / Chrome for Developers
Render-blocking JavaScript weight 2/3
Correct implementation: External scripts in the head should load with async, defer or type="module".
Why does it matter? A synchronous script stops the page from rendering until it's downloaded and executed (LCP is delayed).
Source: Chrome: Render-blocking resources · web.dev / Chrome for Developers, Technical SEO task list applied on publisher projects
Render-blocking CSS files weight 1/3
Correct implementation: Critical CSS inline and the rest in a few external files; 0–1 blocking CSS file is ideal.
Why does it matter? The browser doesn't render the page until every external CSS file has downloaded; many files delay the first view.
Source: Chrome: Render-blocking resources · web.dev / Chrome for Developers
Third-party script sources weight 1/3
Correct implementation: Keep the number of scripts loaded from other domains low (3 or fewer is good).
Why does it matter? Every third-party script adds DNS/connection cost and performance risk; ad and tracking code worsens INP.
Source: web.dev: Third-party JavaScript · web.dev / Chrome for Developers, Technical SEO task list applied on publisher projects
Mixed content (http resources on an https page) weight 3/3
Correct implementation: All resources on an HTTPS page should load over https://.
Why does it matter? Browsers block http resources or show warnings; images may disappear and a security warning may appear.
Source: web.dev: Mixed content · web.dev / Chrome for Developers, Technical SEO task list applied on publisher projects
width/height on images (CLS) weight 2/3
Correct implementation: width and height attributes that reflect the real aspect ratio on every <img>.
Why does it matter? When an image of unknown size loads, content shifts down (CLS), causing mis-clicks while people read.
Source: web.dev: Optimize CLS · web.dev / Chrome for Developers, Technical SEO task list applied on publisher projects
Lazy-loading the first image (LCP risk) weight 2/3
Correct implementation: The main image at the top of the screen shouldn't be lazy-loaded.
Why does it matter? If the largest image (LCP) loads late, the page feels “loaded” later and Core Web Vitals get worse.
Source: web.dev: Don't lazy-load the LCP image · web.dev / Chrome for Developers, Technical SEO task list applied on publisher projects
Prioritized image loading (fetchpriority / preload) weight 1/3
Correct implementation: fetchpriority="high" or <link rel="preload" as="image"> on the main image.
Why does it matter? Tells the browser to download the most important image first; it can noticeably improve LCP.
Source: web.dev: Fetch Priority API · web.dev / Chrome for Developers, Technical SEO task list applied on publisher projects
Lazy-loading offscreen images weight 1/3
Correct implementation: Images further down the page should load with loading="lazy".
Why does it matter? Downloading images nobody sees yet wastes bandwidth and initial load time.
Source: web.dev: Browser-level lazy loading · web.dev / Chrome for Developers, Technical SEO task list applied on publisher projects
Modern image formats (WebP/AVIF) weight 1/3
Correct implementation: Images should be served as WebP or AVIF.
Why does it matter? Modern formats are 25–50% smaller than JPEG/PNG at the same quality.
Source: Chrome: Modern image formats · web.dev / Chrome for Developers, Technical SEO task list applied on publisher projects
Resource hints (preconnect / preload) info only, not scored
Correct implementation: Informational: preconnect to critical third-party domains, preload critical resources.
Why does it matter? Used correctly, they bring connection setup and the download of critical resources forward; overusing them backfires.
Source: web.dev: Fetch Priority API · web.dev / Chrome for Developers
HTML Hygiene and Accessibility

Heading hierarchy, alt text, semantic tags and the correctness of the head section.

H1 heading weight 2/3
Correct implementation: A single, non-empty <h1> that describes the page's topic.
Why does it matter? The H1 is the page's main heading; search engines and screen readers use it to understand what the page is about.
Source: Google: SEO Starter Guide · W3C: Heading structure · Google Search Central, W3C (WCAG, HTML), Technical SEO task list applied on publisher projects
Other tags inside the H1 weight 1/3
Correct implementation: The H1 should be plain text, without spans, links or images inside.
Why does it matter? Nested tags blur the heading's text and meaning; links inside the H1 in particular turn the heading into a navigation element.
Source: W3C: Heading structure · Technical SEO task list applied on publisher projects
Heading hierarchy (h2–h6) weight 1/3
Correct implementation: Heading levels should follow in order without skipping (h2 → h3 → h4).
Why does it matter? A clean hierarchy creates a scannable outline of the content, and screen reader users navigate by headings.
Source: W3C: Heading structure · W3C (WCAG, HTML)
Empty heading and paragraph tags weight 1/3
Correct implementation: Don't output empty <h1>–<h6> or <p> tags.
Why does it matter? Empty headings create meaningless stops in screen readers and break the page structure.
Source: W3C: Heading structure · Technical SEO task list applied on publisher projects
Alt text on images weight 2/3
Correct implementation: An alt attribute on every <img>; alt="" for decorative images.
Why does it matter? Visually impaired users and Google Images understand what an image shows from its alt text.
Source: Google: Image SEO best practices · W3C: Alternative text for images · Google Search Central, W3C (WCAG, HTML), Independent technical SEO audits, Technical SEO task list applied on publisher projects
title attribute on images weight 1/3
Correct implementation: Don't use title on <img>; the description belongs in the alt text.
Why does it matter? title shows a tooltip on mouse hover, which isn't reliable for touch and screen reader users.
Source: W3C: Alternative text for images · Technical SEO task list applied on publisher projects
alt used outside img weight 1/3
Correct implementation: alt only on <img>, <area> and <input type="image">; aria-label on other elements.
Why does it matter? alt on other elements isn't read by any assistive technology, so the name is missing.
Source: W3C: Accessible name (name, role, value) · Technical SEO task list applied on publisher projects
Buttons without an accessible name weight 1/3
Correct implementation: Icon buttons should have an aria-label or visually hidden text.
Why does it matter? A nameless button is read out just as “button” by screen readers, so it's unclear what it does.
Source: W3C: Accessible name (name, role, value) · W3C (WCAG, HTML), Technical SEO task list applied on publisher projects
iframe titles weight 1/3
Correct implementation: Every <iframe> should have a title describing its content.
Why does it matter? Screen reader users learn what the embedded content is from its title.
Source: W3C: Giving iframes a title (H64) · W3C (WCAG, HTML), Technical SEO task list applied on publisher projects
Semantic HTML (main, nav, header, footer) weight 1/3
Correct implementation: The page should use <main>, <nav>, <header> and <footer> regions.
Why does it matter? Semantic tags tell screen readers and AI agents which part of the page is the main content.
Source: W3C: Landmark regions · W3C (WCAG, HTML), Independent technical SEO audits
Head section integrity weight 2/3
Correct implementation: <head> should contain only meta, link, title, script, style, base, noscript and template.
Why does it matter? An invalid element in the head (e.g. div, img, iframe) closes the head early, and Google may ignore the canonical, hreflang and robots tags after it.
Source: Google: Page metadata in valid HTML · Google Search Central
HTML5 doctype weight 1/3
Correct implementation: The document should start with <!DOCTYPE html>.
Why does it matter? Without a doctype, the browser renders the page in old “quirks” mode, which can cause layout errors and unexpected behavior.
Source: MDN: Quirks mode and standards mode · MDN Web Docs
Deprecated HTML tags weight 1/3
Correct implementation: Deprecated tags such as font, center and marquee shouldn't be used.
Why does it matter? Non-standard tags create a maintenance burden; styling should be done with CSS.
Source: MDN: Deprecated HTML elements · MDN Web Docs
Duplicate id values info only, not scored
Correct implementation: Informational: each id should be used only once per page.
Why does it matter? Duplicate ids break label–field associations, in-page links and accessibility relationships.
Source: W3C: Accessible name (name, role, value) · W3C (WCAG, HTML)
GEO / AI Readiness

Whether AI search and answer engines can access the site and correctly recognize the brand.

Correct implementation: Answer crawlers such as OAI-SearchBot, ChatGPT-User, PerplexityBot and Claude-SearchBot shouldn't be blocked.
Why does it matter? These crawlers let the site be cited as a source in answer engines such as ChatGPT, Perplexity and Claude; blocking them wipes out AI visibility directly.
Source: OpenAI: Crawlers and user agents · Enar SEO: GEO guide · Independent technical SEO audits
Access for AI training crawlers weight 1/3
Correct implementation: Training crawlers such as GPTBot, Google-Extended, ClaudeBot and CCBot should be managed deliberately; Enar SEO's default is to leave them allowed.
Why does it matter? Blocking training crawlers is a business decision (licensing, content policy). Leaving them allowed makes it more likely the brand is represented accurately in models.
Source: Google: Google crawlers (Google-Extended) · OpenAI: Crawlers and user agents · Google Search Central, Independent technical SEO audits
llms.txt file info only, not scored
Correct implementation: Informational: Google states that special files such as llms.txt aren't needed for its AI features.
Why does it matter? It isn't a widely adopted standard; having it or not doesn't affect rankings.
Source: Google: AI features and your website · Google Search Central
Correct implementation: The home page (preferably the footer) should link to an About or imprint page.
Why does it matter? AI models and search engines learn who the brand is, who owns it and what expertise it has from this page (E-E-A-T).
Source: Google: Helpful, reliable content · Google Search Central, Independent technical SEO audits