Skip to main content
Archived

SEO Report for https://index.hu

Your general SEO Checkup Score

SEO Score59/100
Average SEO score of top 100 sites: 75%This value indicates the average SEO score of the top 100 most visited websites in the US (in the past 12 months)

Your site scored 59/100, well below the 75 average for top sites. We found 14 issues to fix, and clearing them is how you move up.

14 Failed
5 Warnings
25 Passed

Want to fix these issues and track your progress?

Issues to fix

HIGH
To improve the website experience for your visitors, it is recommended to eliminate any render-blocking resources on this webpage.
Details
HIGH
To ensure that Search Engines can accurately identify the topic of this webpage, it is important to include the most common keywords in the title tag, meta description, and heading tags.
Details
HIGH
Using images in a modern format can significantly reduce the file size and improve the loading speed of a webpage, providing a better user experience and potentially increasing engagement.
Details
MEDIUM
Minify all JavaScript files to reduce page size and loading time.
Details
MEDIUM
Serve properly sized images to reduce page loading times and to improve user's experience.
Details
MEDIUM
Avoid using distorted images, as they can have a negative impact on the user experience.
Details
MEDIUM
Reducing the JavaScript execution time can result in faster page load times and a smoother user experience, as it allows the browser to render and display the page more quickly.
Details
MEDIUM
HTTP/2 protocol offers several key improvements, including faster page load times, improved performance, better security and more efficient use of network resources.
Details
MEDIUM
Avoid performance and security issues by adding "rel=noopener" or "rel=noreferrer" to your "target=_blank" links.
Details
LOW
Consider reducing the HTML size to improve loading times and retain visitors.
Details
LOW
Reducing the Document Object Model (DOM) size can lead to faster page loading times, improved site performance, and better user experience by decreasing the amount of time it takes for the browser to process and render the page.
Details
LOW
Using more than 20 HTTP requests on a webpage can negatively impact the loading time.
Details
LOW
Consider adding the Strict-Transport-Security header to your webpage to ensure that web traffic is encrypted over HTTPS, mitigating the risk of man-in-the-middle attacks and other security threats.
Details

Common SEO issues

Score:61
Failed:3
Warnings:2
Passed:8
Meta Title Test
100% of top 100 sites passed
This webpage is using a title tag.
Text: Index - friss hírek, események, tények
Length: 38 characters
The meta title is an HTML element that defines a page's title, displayed in search engine results, browser tabs, and bookmark lists. A concise, keyword-relevant title is a strong on-page ranking signal and a major driver of organic click-through rate. AI answer engines and LLM-driven search experiences also rely on the title to identify, summarize, and cite the page in generative results.
Meta Description Test
92% of top 100 sites passed
This webpage is using a meta description tag with a length of 101 characters. We recommend using well-written and inviting meta descriptions with a length between 150 and 220 characters (spaces included).
Text: Magyarország kezdőlapja: gyors hírek, feltárt tények, karcos vélemények. Fontos hírek: ai summit 2026
Length: 101 characters
The meta description is an HTML tag that provides a short summary of a page's content, often shown beneath the title in search results. While not a direct ranking factor, an accurate and inviting description significantly improves click-through rate from organic listings. AI answer engines and social platforms also use it as a trusted summary when generating previews, citations and shareable snippets.
Google Search Results Preview Test
Desktop version
https://index.hu/Index - friss hírek, események, tényekMagyarország kezdőlapja: gyors hírek, feltárt tények, karcos vélemények. Fontos hírek: ai summit 2026
Mobile version
https://index.hu/Index - friss hírek, események, tényekMagyarország kezdőlapja: gyors hírek, feltárt tények, karcos vélemények. Fontos hírek: ai summit 2026
A simulated preview of how the page may appear in Google search results, combining the title, URL, and meta description as Google typically renders them. Useful for spotting truncated text, weak phrasing, or missing elements before publishing, since the snippet directly influences whether searchers click through.
Most Common Keywords Test
There is likely no optimal keyword density (search engine algorithms have evolved beyond keyword density metrics as a significant ranking factor). It can be useful, however, to note which keywords appear most often on your page and if they reflect the intended topic of your page. More importantly, the keywords on your page should appear within natural sounding and grammatically correct copy.
45tovább
34magyar
33hogy
24volt
24órája
A frequency analysis of the most repeated words and phrases in the page's visible content. Useful for getting a quick sense of which topics search engines are likely to associate with the page, and for spotting cases where the actual content drifts from the intended subject.
Keywords Usage Test
48% of top 100 sites passed
The most common keywords of this webpage are not distributed across the important HTML tags! Primary keywords should appear in title tag, meta description and heading tags to help Search Engines to properly identify the topic of this webpage.
Keyword
Title tag
Meta description
Headings
tovább
magyar
hogy
volt
órája
Cross-checks whether the most frequently used keywords on the page also appear in the title and meta description. Alignment between body content and metadata helps search engines confirm the page's topic and reinforces relevance for those terms.
Related Keywords Test
Related Keywords

See which keywords rank your URL in Google’s top 20

Get key keyword metrics like average position, search volume, CPC, and more.

A list of search queries for which the page already appears in the top organic results. Highlights the topical territory the page is winning in search and can surface unexpected terms that present new content or optimization opportunities.
Competitor Domains Test
Competitor Domains

Understand your competitors' SEO and backlink profile

Get related competitors and their domain authority score in relation to your domain.

Identifies up to ten domains that compete for similar organic search results, ranked by overall domain authority based on the volume and quality of their backlink profiles. Useful for benchmarking the competitive landscape and prioritizing which sites to study for content and link-building strategy.
Robots.txt Test
99% of top 100 sites passed
This website is using a robots.txt file.
https://index.hu/robots.txt
Verifies whether the site exposes a robots.txt file at the root domain. This file is the first resource most crawlers request, telling search engines and other bots which paths they may or may not access. It is also the standard mechanism for allowing or blocking modern AI crawlers used by training pipelines and answer engines.
Sitemap Test
83% of top 100 sites passed
This website has a sitemap file.
http://index.hu/sitemap/sitemapindex.xml
Looks for an XML sitemap on the site and reports whether one is published. Sitemaps give search engines an explicit, machine-readable list of the URLs you want crawled, along with metadata such as last-modified dates, which speeds up discovery of new and updated pages. They are especially useful for large sites or those with weak internal linking.
Image Alt Test
78% of top 100 sites passed
This webpage is using "img" tags with empty or missing "alt" attribute!

Image Alt Test

How to pass this test?

Alt attributes provide a text alternative for images, used by screen readers when a user cannot see the image and by search engines and multimodal AI models to understand what the image depicts. Fixing this issue means writing concise, descriptive alt text for every meaningful image on the page, and using empty alt for purely decorative images so assistive technology can skip them. The same alt text helps multimodal LLMs and image search tools surface and cite your visuals.

Example

<img src="/images/marathon-shoes.jpg"
     alt="Side view of a lightweight neon-green marathon running shoe">

<img src="/images/divider.svg" alt="">

Where to make the change

  • Raw HTML: add the alt attribute to every <img> tag. For decorative images, use alt="" so screen readers skip them.
  • WordPress: the media library has an Alt text field on every uploaded image. Fill it once and the value is reused everywhere the image is inserted.
  • Shopify: in the product or page editor, click an image and use the Edit alt text option. Theme code that renders product images should pull image.alt.
  • Wix or Squarespace: click the image in the editor and use the Alt text or Image description field in the side panel.
  • Headless or framework sites: require an alt prop on every image component and lint for missing values during build.

Common causes and how to resolve them

  • Attribute missing: add alt="" at minimum so the page validates. Replace with descriptive text on any image that conveys information.
  • Alt text is the filename: "IMG_4837.jpg" tells the user nothing. Replace with a description of what is in the image.
  • Alt text duplicates the visible caption: screen readers will read both, doubling the user's listening time. Differentiate the alt from the caption or empty the alt.
  • Decorative images get descriptive alt text: background patterns and dividers should use alt="", otherwise screen readers narrate noise.
  • Bulk imports left alt blank: a one-off audit of the media library or a CMS-side script can fill missing alt values from product names, captions, or asset descriptions.

Best practices

  • Describe the function, not just the appearance: for a chart, describe what the chart shows. For a button image, describe what the button does.
  • Keep it concise: aim for under 125 characters. Screen readers do not pause mid-sentence, so long alt text is exhausting to listen to.
  • Skip "image of" or "picture of": the screen reader already announces it as an image.
  • Include the focus keyword when natural: alt text is a minor on-page signal, but stuffing keywords in unnatural alt text harms both accessibility and ranking.
Inspects whether images on the page include descriptive alt attributes. Alt text provides accessibility for screen readers, a fallback when images fail to load, and a textual signal that helps search engines understand image content. It also improves how AI crawlers and image search tools interpret and surface the visuals.
Responsive Image Test
29% of top 100 sites passed
Not all images in this webpage are properly sized! This webpage is serving images that are larger than needed for the size of the user's viewport.

Responsive Image Test

How to pass this test?

This test fails when one or more images on the page are served at dimensions significantly larger than the size at which the browser actually renders them. Fixing this issue means resizing the source files (or serving responsive variants) so the bytes downloaded match the pixels actually displayed. The result is faster page loads, lower data usage, and better Core Web Vitals scores.

Example

<img
  src="/images/hero-800.jpg"
  srcset="/images/hero-400.jpg 400w,
          /images/hero-800.jpg 800w,
          /images/hero-1600.jpg 1600w"
  sizes="(max-width: 640px) 100vw, 800px"
  alt="Marathon runners at sunrise"
  width="800" height="450">

Where to make the change

  • Raw HTML: use srcset and sizes to let the browser pick the right variant for the user's viewport. Always include intrinsic width and height attributes.
  • WordPress: WordPress generates multiple image sizes automatically. Use the the_post_thumbnail() helper or the block editor's image block, both of which emit responsive srcset markup.
  • Shopify: use the image_url Liquid filter with size parameters (for example {{ image | image_url: width: 800 }}) and pair with image_tag to emit a responsive image.
  • Wix or Squarespace: both platforms generate responsive variants automatically; this issue is typically caused by uploading a deliberately oversized image.
  • Headless or framework sites: use the framework's image component (for example next/image or astro:assets), which generates responsive variants and lazy-loads off-screen images.

Common causes and how to resolve them

  • Original camera or stock-photo file uploaded as-is: a 6000-pixel-wide JPEG rendered in a 400-pixel column wastes most of the bytes. Resize the source or generate responsive variants.
  • No srcset: the browser has no choice but to use the single source. Add multiple variants so mobile users get smaller files.
  • Hero images sized for ultra-wide displays: if your largest layout is 1600 pixels, do not ship a 4000-pixel original.
  • Background images set in CSS without responsive sources: use the image-set() CSS function or media queries to swap in different image files at different breakpoints.

Best practices

  • Generate variants at common widths: 400, 800, 1200, and 1600 pixels covers most viewports cleanly.
  • Always set width and height: intrinsic dimensions let the browser reserve space and avoid layout shift, helping CLS.
  • Lazy-load off-screen images: add loading="lazy" to images below the fold so the browser only downloads them when needed.
  • Pair with modern formats: resizing alone is good; resizing and serving WebP or AVIF compounds the savings.
Compares the natural dimensions of each image to the size at which it is actually rendered in the user's viewport. Serving images significantly larger than needed wastes bandwidth, slows page load, and forces the browser to scale assets unnecessarily, all of which hurt performance and user experience.
Image Aspect Ratio Test
75% of top 100 sites passed
Not all image display dimensions match the natural aspect ratio! Fix aspect ratio issues to avoid distorted images on this website!

Image Aspect Ratio Test

How to pass this test?

This test fails when one or more images are rendered at an aspect ratio meaningfully different from the source file's native ratio, producing stretched or squashed visuals. Fixing this issue means either using width and height attributes that match the file's real dimensions or replacing the source with a correctly proportioned crop.

Example

<!-- Source file is 1600 x 900 (16:9). Set matching attributes: -->
<img src="/images/marathon-1600.jpg"
     alt="Marathon runners at sunrise"
     width="1600" height="900"
     style="max-width: 100%; height: auto;">

Where to make the change

  • Raw HTML and CSS: set the width and height attributes to the source file's native dimensions. Use CSS height: auto when scaling responsively so the browser preserves the ratio.
  • WordPress: when inserting an image via the block editor, choose the image's intended size rather than overriding dimensions in custom CSS.
  • Shopify, Wix, or Squarespace: use the platform's built-in image cropper so the displayed crop matches the source file you upload.
  • Headless or framework sites: components like next/image require both width and height, which prevents distortion when the layout scales.

Common causes and how to resolve them

  • Hard-coded width and height that do not match the file: recompute them from the source dimensions or remove them and rely on the file's intrinsic ratio.
  • Container has a fixed height that crops the image: use CSS object-fit: cover if cropping is intentional, or change the container so the image keeps its natural ratio.
  • Wrong source file uploaded: swap in a correctly proportioned crop rather than stretching the wrong file in CSS.

Best practices

  • Always set both width and height: the browser uses these to reserve space and avoid layout shift before the image loads, which helps CLS.
  • Use object-fit when cropping is intentional: cover fills the container without distortion; contain letterboxes to preserve the full image.
  • Standardize on a few aspect ratios: picking one or two ratios per template makes it easier to crop assets consistently and avoid one-off distortions.
Compares each image's natural aspect ratio against the ratio at which it is displayed on the page. Significant mismatches result in stretched or squashed visuals that look unprofessional and degrade the user experience.
Deprecated HTML Tags Test
94% of top 100 sites passed
This webpage does not use HTML deprecated tags.
Scans the markup for HTML elements that are no longer part of the modern HTML specification. Deprecated tags may still render today, but browsers can drop support at any time, leading to broken layouts and rendering inconsistencies. Replacing them with current standards keeps the page resilient and easier to maintain.
Backlinks Test
Backlinks

Get a full and detailed list of your backlinks

See every website linking to yours, along with detailed backlink data.

Surfaces the external pages that link to the analyzed URL. Backlinks from authoritative, topically relevant sites remain one of the strongest off-page ranking signals, while a profile dominated by low-quality or spammy links can attract algorithmic penalties. Reviewing the inbound link mix helps identify both link-building wins and toxic links worth disavowing.
JS Error Test
83% of top 100 sites passed
There are no severe JavaScript errors on this webpage.
Inspects the page for JavaScript runtime errors that occur as it loads. Unhandled errors can break interactive features, leave content unrendered, and signal poor code quality, all of which hurt the user experience that search engines factor into rankings.
Charset Declaration Test
96% of top 100 sites passed
This webpage has a character encoding declaration.
Content-Type: text/html; charset=UTF-8
Checks whether the page declares a character encoding such as UTF-8. Without an explicit charset declaration, browsers must guess the encoding, which can lead to garbled symbols, broken accented characters, and inconsistent rendering across devices. UTF-8 is the modern standard recommended by Google.

Speed optimizations

Score:41
Failed:7
Warnings:3
Passed:4
HTML Page Size Test
23% of top 100 sites passed
The size of this webpage's HTML is 90.09 Kb, and is greater than the average size of 33 Kb! This can lead to slower loading times, lost visitors, and decreased revenue. Good steps to reduce HTML size include: using HTML compression, CSS layouts, external style sheets, and moving javascript to external files.

HTML Page Size Test

How to pass this test?

This test fails when the raw HTML document weighs significantly more than necessary, even before counting images, CSS, or JavaScript. Bloated HTML increases time to first byte, slows parsing, and stalls rendering on mobile networks and lower-powered devices. Fixing this issue means trimming inline data, removing legacy markup, and keeping the document focused on what the user needs.

Where to make the change

  • Application code or templates: identify which sections produce the most bytes (often a large inline JSON blob, an inline base64 image, or a giant comment block) and refactor them to load externally or be removed.
  • WordPress: check for plugins or page builders that emit large inline configurations. Disable unused plugins and prefer themes that ship clean markup.
  • Shopify: theme code may inline large product or section JSON. Move heavy data to a fetch-on-demand endpoint when possible.
  • Headless or framework sites: review the rendered output for serialized state (for example __NEXT_DATA__ in Next.js) and trim what is sent on first paint by streaming or lazy-loading non-critical chunks.

Common causes and how to resolve them

  • Inline base64 images or fonts: move them to external files so the browser can cache them across requests.
  • Excessive inline CSS or JavaScript: link to external stylesheets and scripts so they cache. Inline only the truly critical CSS for above-the-fold content.
  • Large server-side JSON payloads: ship only the data needed for first render. Fetch the rest on demand.
  • Repeating boilerplate or commented-out code: strip comments and dead code in the production build.
  • HTML compression disabled: Gzip or Brotli compression often shrinks the response by half or more. Confirm the server sends the appropriate Content-Encoding header.

Best practices

  • Aim for under 100 KB of HTML: most pages can comfortably stay under this. Anything beyond a few hundred KB usually indicates structural bloat worth refactoring.
  • Enable compression: Gzip is the safe minimum, Brotli is even better for HTML and other text formats.
  • Defer non-critical content: rendering only what is needed for the initial viewport keeps both bytes and parse time down.
  • Audit periodically: add HTML size to your performance budget so regressions get caught in CI.
Measures the size of the raw HTML document, excluding images and external CSS or JavaScript. Bloated HTML increases time to first byte and parsing time, slowing down rendering on mobile networks and lower-powered devices. Trimming inline styles, redundant markup, and oversized inline data keeps initial load fast.
DOM Size Test
56% of top 100 sites passed
The Document Object Model (DOM) of this webpage has 4,368 nodes which is greater than the recommended value of 1,500 nodes! A large DOM size negatively affects site performance and increases the page load time.

DOM Size Test

How to pass this test?

This test fails when the page builds a Document Object Model with too many nodes or excessive nesting depth. Large DOMs increase memory usage, lengthen style and layout calculations, and slow rendering, particularly on mobile devices. Fixing this issue means simplifying the markup so the browser has less work to do on every interaction.

Where to make the change

  • Application code or templates: identify the heaviest sections (long lists, repeating components, deep grid wrappers) and either paginate them, virtualize them, or flatten the markup.
  • WordPress: heavy page-builder themes often emit deeply nested wrapper divs. Consider switching templates or using a theme that emits cleaner markup.
  • Headless or framework sites: use a virtualized list component for long item lists so only visible rows are rendered into the DOM.

Common causes and how to resolve them

  • Long lists rendered in full: show a paginated subset or virtualize the list so only on-screen items exist in the DOM.
  • Excessive wrapper divs: a stack of layout wrappers ten deep can usually be flattened to two or three with modern CSS layouts (Grid, Flexbox).
  • Hidden modals and dropdowns kept in the DOM: render them on demand instead of always emitting them with display: none.
  • Third-party widget injecting many nodes: a chat widget or carousel may add hundreds of nodes per page. Lazy-load it after main content renders.

Best practices

  • Aim for under 1500 nodes total and a maximum depth of 32: Lighthouse uses these as warning thresholds and they correlate with smooth rendering on mid-tier mobile devices.
  • Render only what is visible: long lists, accordions, and modals belong outside the initial DOM until needed.
  • Prefer flat semantic markup: a single <article> with a few children is faster than a deeply nested <div> tree.
  • Audit with Lighthouse: the DOM size audit reports the worst-offending elements, which often points at a single template that needs rework.
Measures the size and depth of the page's Document Object Model, the tree of nodes the browser builds from the HTML. Very large DOMs increase memory usage, lengthen style and layout calculations, and slow down rendering, particularly on mobile devices. Keeping the DOM lean improves both load time and runtime responsiveness.
JS Execution Time Test
53% of top 100 sites passed
The JavaScript code used by this webpage is executed in more than 3.5 seconds! When the JavaScript code takes a long time to execute, it slows down the page performance in several ways: longer download times, main thread bottlenecks, delays of "Time To Interactive", memory leaks, etc.

JS Execution Time Test

How to pass this test?

This test fails when the browser spends excessive time parsing, compiling, and executing JavaScript while the page loads. Heavy JavaScript work blocks the main thread and is the primary cause of poor Interaction to Next Paint (INP), the Core Web Vital that replaced First Input Delay in 2024 and that Google uses as part of its ranking algorithms. Fixing this issue means shipping less JavaScript, splitting what remains, and deferring everything that is not needed for the initial interaction.

Where to make the change

  • Application code: audit your bundle with a tool such as Bundle Analyzer or Source Map Explorer. Identify the largest dependencies and either remove, replace, or lazy-load them.
  • Build configuration: enable code splitting so each route loads only its own chunk. Tree-shake unused exports from libraries.
  • Third-party scripts: the biggest INP wins often come from removing or deferring analytics, advertising, and tag-management scripts.

Common causes and how to resolve them

  • Single large bundle: split the bundle by route or feature so the user only downloads and executes the code for the current page.
  • Heavy third-party tags: load analytics, ads, and chat widgets after main content with async or defer, or move them into Google Tag Manager so they can be controlled centrally.
  • Unused JavaScript: audit with the Coverage tab in DevTools to find code that loads but never runs on the page. Remove or split it out.
  • Long tasks blocking the main thread: break work into smaller chunks with setTimeout, requestIdleCallback, or scheduler.yield(). Move heavy computation to a Web Worker.
  • Polyfills shipped to modern browsers: use modern-only bundles for ES2017+ and serve legacy polyfills only when needed via differential serving.

Best practices

  • Target sub-200 millisecond INP at the 75th percentile: this is the official "good" threshold for the Core Web Vital.
  • Ship less code: the cheapest JavaScript to execute is the JavaScript you never sent. Audit dependencies for lighter alternatives.
  • Defer non-critical scripts: use defer for scripts that need the DOM, async for fully independent ones.
  • Move CPU-intensive work off the main thread: Web Workers can handle large data transformations without freezing the UI.
Reports the total time the browser spends parsing, compiling, and executing JavaScript while the page loads. Heavy JavaScript work blocks the main thread and is the primary cause of poor Interaction to Next Paint, the Core Web Vital that replaced First Input Delay in 2024 and that Google uses as part of its ranking algorithms. Reducing bundle size and deferring non-critical scripts directly improves perceived performance.
Page Objects Test
7% of top 100 sites passed
This webpage is using more than 20 http requests, which can slow down page loading and negatively impact user experience!
Content size by content type
Content type
Percent
Size
image
49.9 %
9.33 Mb
javascript
18.3 %
3.41 Mb
other
17.1 %
3.20 Mb
font
6.9 %
1.29 Mb
css
5.2 %
998.30 Kb
html
2.6 %
488.19 Kb
TOTAL
100%
18.68 Mb
Requests by content type
Content type
Percent
Requests
javascript
48.2 %
165
image
18.4 %
63
other
13.5 %
46
html
9.6 %
33
font
5.6 %
19
css
4.7 %
16
TOTAL
100%
342
Content size by domain
Domain
Percent
Size
kep.cdn.indexvas.hu
42.3 %
7.90 Mb
cms.indaplay.hu
15.0 %
2.79 Mb
index.hu
10.1 %
1.89 Mb
indaplay.hu
7.0 %
1.32 Mb
galeria.cdn.index.hu
6.5 %
1.21 Mb
googletagmanager.com
3.4 %
644.64 Kb
imasdk.googleapis.com
2.3 %
438.39 Kb
cmp.inmobi.com
1.9 %
356.32 Kb
indexhu.adocean.pl
1.7 %
329.43 Kb
securepubads.g.doubleclick.net
1.5 %
295.69 Kb
Other
8.3 %
1.56 Mb
TOTAL
100%
18.68 Mb
Requests by domain
Domain
Percent
Requests
indaplay.hu
15.2 %
52
index.hu
12.3 %
42
kep.cdn.indexvas.hu
10.5 %
36
indexadhu.hit.gemius.pl
8.5 %
29
indexhu.adocean.pl
6.1 %
21
cms.indaplay.hu
3.5 %
12
viewability.inda.hu
3.2 %
11
gahu.hit.gemius.pl
2.9 %
10
cmp.inmobi.com
2.3 %
8
iap.cdn.indexvas.hu
2.3 %
8
Other
33.0 %
113
TOTAL
100%
342
Verifies that every resource the page requests, including images, scripts, stylesheets, and fonts, can be successfully retrieved. Broken or unreachable assets can leave the page rendered incorrectly, trigger console errors, and damage both user experience and how search engines perceive page quality.
CDN Usage Test
95% of top 100 sites passed
This webpage is not serving all resources (images, javascript and css) from CDNs!

CDN Usage Test

How to pass this test?

A Content Delivery Network serves static assets from edge locations close to the user, reducing latency, improving cache hit rates, and offloading traffic from the origin server. Fixing this issue means routing your images, JavaScript, CSS, and fonts through a CDN so visitors anywhere in the world get fast, consistent delivery.

Where to make the change

  • Cloud platforms: Cloudflare, Fastly, AWS CloudFront, Bunny.net, and similar providers offer free or low-cost CDN tiers. Sign up, point your domain through the CDN, and enable caching for static asset paths.
  • WordPress: use a CDN integration plugin or sign up directly with Cloudflare and update the site's nameservers.
  • Shopify: Shopify serves storefront assets through its own CDN automatically; the failure usually points at custom assets uploaded outside the platform.
  • Headless or framework sites: deploying to Vercel, Netlify, or Cloudflare Pages puts the entire site behind a global CDN by default.

Common causes and how to resolve them

  • No CDN at all: add one. Even a free Cloudflare account in front of an existing host produces measurable speed gains.
  • CDN configured but bypassed for some assets: ensure all img, script, link, and font URLs use the CDN hostname rather than the origin.
  • Cache headers prevent caching: long-lived assets need cache-control headers like public, max-age=31536000, immutable. Without them, the CDN cannot cache effectively.
  • Origin-only third-party scripts: many vendors already serve their scripts via their own CDN. Use the URL the vendor provides rather than self-hosting.

Best practices

  • Use a versioned asset path: filenames like app.a3f9.css let you set far-future cache headers without ever serving stale files. Update the filename when content changes.
  • Enable Brotli at the edge: most CDNs can compress responses on the fly, including text formats.
  • Pre-warm caches for new launches: after a major release, request key URLs through every region (or use the CDN's purge-and-prefetch tools) so users do not hit cold caches.
Detects whether static assets such as images, JavaScript, and CSS are delivered through a Content Delivery Network. CDNs serve files from edge locations close to the user, reducing latency, improving cache hit rates, and offloading traffic from the origin server. The result is faster, more consistent page performance worldwide.
Modern Image Format Test
43% of top 100 sites passed
This webpage is not serving images in a modern format! Image formats like JPEG 2000, JPEG XR, and WebP often provide better compression than PNG or JPEG, which means faster downloads and less data consumption.

Modern Image Format Test

How to pass this test?

This test fails when images are served in legacy formats such as JPEG and PNG instead of modern alternatives like WebP or AVIF. Modern formats compress significantly better at equivalent visual quality, which means smaller transfers, faster page loads, and lower data usage for visitors on metered connections. Fixing this issue means generating modern variants and serving them to browsers that support them.

Example

<picture>
  <source srcset="/images/hero.avif" type="image/avif">
  <source srcset="/images/hero.webp" type="image/webp">
  <img src="/images/hero.jpg" alt="Marathon runners at sunrise" width="1600" height="900">
</picture>

Where to make the change

  • Raw HTML: use the <picture> element with multiple <source> entries so the browser picks the best supported format.
  • WordPress: WordPress 6.x and later supports WebP natively. Use a media optimization plugin to convert existing JPEGs and PNGs and serve modern formats automatically.
  • Shopify: Shopify's image CDN can serve WebP automatically; using the image_url filter with format parameter or the image_tag helper handles negotiation.
  • Wix or Squarespace: both platforms convert and serve WebP automatically when supported by the visitor's browser.
  • Headless or framework sites: components like next/image and astro:assets generate AVIF and WebP variants at build time and serve the best format per request.

Common causes and how to resolve them

  • Only legacy formats published: add a build step or image CDN that generates WebP and AVIF alongside the original.
  • Single-format <img> tag: wrap the image in <picture> with <source> entries for AVIF and WebP, falling back to the JPEG.
  • Image CDN not negotiating format: enable automatic format conversion or pass a format=auto query parameter (depends on provider).
  • SVG used where a raster image would be smaller (or vice versa): illustrations and icons should be SVG; photos should be raster in a modern format. Mixing them up wastes bytes.

Best practices

  • AVIF first, WebP fallback, JPEG last: AVIF compresses best, WebP is widely supported, JPEG remains the universal fallback.
  • Match quality to use case: hero images can use higher quality settings; thumbnails can drop quality without visible loss.
  • Use an image CDN: services like Cloudflare Images, Cloudinary, or Imgix handle resizing, format conversion, and caching in one step.
Identifies images served in legacy formats such as JPEG and PNG instead of modern alternatives like WebP or AVIF. Modern formats compress significantly better at equivalent visual quality, which means smaller transfers, faster page loads, and lower data usage for visitors on metered connections.
Image Caching Test
95% of top 100 sites passed
This website is using cache headers for images and the browsers will display these images from the cache.
Inspects whether image responses include caching headers that allow browsers to store them for repeat visits. With proper caching directives, returning visitors retrieve images from the local cache instead of refetching them, producing noticeably faster subsequent page loads.
CSS Caching Test
98% of top 100 sites passed
This webpage is using cache headers for all CSS resources.
Inspects whether external CSS files are served with caching headers that allow browsers to store and reuse them. Cached stylesheets skip the network on repeat visits, reducing load time for returning users while still allowing updates through versioned filenames.
JavaScript Minification Test
98% of top 100 sites passed
This webpage is using JavaScript files that are not minified!

JavaScript Minification Test

How to pass this test?

This test fails when external JavaScript files are not minified. Minification strips whitespace, comments, and shortens identifiers, producing smaller files that are faster to download and parse. Fixing this issue is almost always a build configuration change rather than a code change.

Where to make the change

  • Build pipeline: enable minification in your bundler. Webpack, Rollup, Vite, esbuild, and Parcel all minify by default in production mode.
  • WordPress: a caching or optimization plugin can minify enqueued scripts on the fly.
  • Shopify: Shopify serves theme JavaScript minified automatically when delivered through the platform asset pipeline.
  • CDN-based minification: Cloudflare and others offer auto-minify for JavaScript responses if you cannot change the build.

Common causes and how to resolve them

  • Build running in development mode: ensure the production build (NODE_ENV=production or equivalent) runs in deploy.
  • Minifier disabled in config: a previous config tweak may have turned minification off. Re-enable it explicitly.
  • Inline scripts not minified: minifiers usually skip inline scripts. Move large inline scripts to external files so they are processed.

Best practices

  • Pair minification with compression: a minified file compresses even better with Brotli or Gzip.
  • Ship sourcemaps: upload sourcemaps to your error monitoring tool so production stack traces remain readable.
  • Use modern syntax targets: targeting modern browsers in your build produces smaller output than transpiling everything down to ES5.
Detects whether external JavaScript files are minified by stripping whitespace, comments, and shortening identifiers. Minified scripts are substantially smaller and faster to download and parse, which lowers page load time and improves Core Web Vitals scores.
CSS Minification Test
100% of top 100 sites passed
All CSS resources used by this webpage are minified.
Detects whether external CSS files are minified by removing whitespace, comments, and unused characters. Minification reduces stylesheet size with no functional change, leading to faster downloads and quicker first render.
Render Blocking Resources Test
15% of top 100 sites passed
This webpage is using render blocking resources! Eliminating render-blocking resources can help this webpage to load significantly faster and will improve the website experience for your visitors.

Render Blocking Resources Test

How to pass this test?

This test fails when JavaScript or CSS resources block the browser from rendering visible content. Each render-blocking file delays the first paint, and on slower networks the cumulative impact can be severe. Fixing this issue means inlining the truly critical CSS, deferring or asynchronously loading non-essential scripts, and removing unused code.

Example

<head>
  <!-- Inline only above-the-fold critical CSS -->
  <style>/* critical styles here */</style>

  <!-- Load full stylesheet asynchronously -->
  <link rel="preload" href="/styles/main.css" as="style"
        onload="this.onload=null;this.rel='stylesheet'">

  <!-- Defer non-critical scripts -->
  <script src="/scripts/app.js" defer></script>
</head>

Where to make the change

  • Application code or templates: identify the CSS and JavaScript needed for the initial render and load only those synchronously. Defer the rest.
  • Build pipeline: use a critical CSS extractor (such as critical or penthouse) to generate the above-the-fold styles automatically.
  • WordPress: performance plugins offer "delay JS execution" and "load CSS asynchronously" options that handle most of this without code changes.
  • Headless or framework sites: use the framework's preload and code-splitting hints to control what blocks rendering.

Common causes and how to resolve them

  • Single large stylesheet blocking render: inline critical CSS for the first viewport, load the full stylesheet asynchronously.
  • Synchronous third-party scripts in the head: add defer or async, or move them to the end of the body.
  • Web fonts blocking text rendering: add font-display: swap in @font-face rules so the fallback font shows immediately.
  • Render-blocking @import in CSS: replace with separate <link rel="stylesheet"> tags so the browser can fetch them in parallel.

Best practices

  • Use defer for scripts that need the DOM: they execute after parsing but before DOMContentLoaded.
  • Use async for fully independent scripts: they execute as soon as they download, in any order.
  • Preload the critical request chain: tell the browser early about fonts and key assets with <link rel="preload">.
  • Audit with Lighthouse: the Render-blocking resources audit lists every offending file with the estimated time saved by deferring it.
Identifies JavaScript and CSS resources that the browser must download and process before it can render visible content. Each render-blocking file delays the first paint, and on slower networks the cumulative impact can be severe. Inlining critical styles, deferring non-essential scripts, and removing unused code all help unblock the rendering path.
Time To First Byte Test
99% of top 100 sites passed
The Time To First Byte value of this webpage is 0.136 seconds. To provide a good user experience, Google recommends that sites should strive to have a TTFB of 0.8 seconds or less.
0.136 s
0.8 s
1.8 s
Measures Time to First Byte, the delay between the browser requesting the page and the first byte of the response arriving. TTFB reflects backend, network, and CDN performance and effectively sets the floor for every other loading metric, since rendering cannot begin until bytes start flowing. Sustained high TTFB usually points to slow server processing, missing edge caching, or inefficient redirects.
Largest Contentful Paint Test
77% of top 100 sites passed
The Largest Contentful Paint duration of this webpage is 3.58 seconds. To provide a good user experience, Google recommends that sites should strive to have Largest Contentful Paint of 2.5 seconds or less.
3.58 s
2.5 s
4 s
Largest Contentful Paint element within the viewport:
<img class="cikkep" alt="Orbán Viktor „ÁVH”-zása után megszólalt Unger Anna..." loading="lazy" src="//kep.cdn.indexvas.hu/1/0/7127/71275/712756/712756...">

Largest Contentful Paint Test

How to pass this test?

Largest Contentful Paint (LCP) measures when the largest visible element in the viewport, such as a hero image or main heading, finishes rendering. LCP is one of Google's Core Web Vitals and a direct ranking factor, used as a proxy for when the user perceives the page as effectively loaded. Fixing this issue means identifying the LCP element and ensuring it loads as early as possible.

Where to make the change

  • Identify the LCP element: open Chrome DevTools, run a Performance trace, and find the LCP marker. The element it points at is the one to optimize.
  • Application code or templates: preload the LCP image, give it fetchpriority="high", and ensure it is in the initial HTML rather than injected by JavaScript.
  • Server and CDN: reduce TTFB and ensure the LCP image is served from a fast, geographically close origin.

Common causes and how to resolve them

  • Hero image loaded lazily: remove loading="lazy" from the LCP image; it should load eagerly.
  • LCP image not preloaded: add <link rel="preload" as="image" href="/hero.jpg" fetchpriority="high"> in the head so the browser fetches it before parsing the rest of the document.
  • LCP image too large or in legacy format: resize to displayed dimensions and serve as WebP or AVIF.
  • Slow TTFB or render-blocking resources: address the underlying TTFB and render-blocking issues; LCP cannot be fast if the page itself is slow to start.
  • Client-side rendered hero content: server-render or pre-render the LCP element so it appears in the initial HTML.
  • Web fonts delaying LCP text: use font-display: swap so the LCP heading renders immediately in a fallback font.

Best practices

  • Target sub-2.5 second LCP at the 75th percentile: the official Core Web Vitals threshold for a "good" experience.
  • Preload the LCP image: the single highest-impact LCP optimization on most sites.
  • Use fetchpriority="high": tells the browser to prioritize the resource ahead of others.
  • Ship modern image formats: AVIF and WebP cut hero image bytes substantially, which directly lowers LCP.
Measures Largest Contentful Paint, the time at which the largest visible element in the viewport, such as a hero image or main heading, finishes rendering. LCP is one of Google's Core Web Vitals and a direct ranking factor, used as a proxy for when the user perceives the page as effectively loaded.
Cumulative Layout Shift Test
91% of top 100 sites passed
The CLS score of this webpage is 0.2187. To provide a good user experience, Google recommends that sites should strive to have a CLS score of 0.1 or less.
0.2187
0.1
0.25
DOM element which contributes the most to CLS score:
Text: Orbán Viktor „ÁVH”-zása után megszólalt Unger Anna: Meg fogjuk tenni a szükséges...
Html: <section class="blokk hajtas-felett dupla-vezeto-blokk cimlap-blok..." data-ff-zoneid="Hajtás felett 1">
Score: 0.1872

Cumulative Layout Shift Test

How to pass this test?

Cumulative Layout Shift (CLS) measures the total amount that visible elements move around unexpectedly while the page loads. Layout shifts cause users to misclick and feel the page is unstable, and CLS is one of Google's Core Web Vitals and a direct ranking factor. Fixing this issue means reserving space for everything that loads after first paint so nothing pushes existing content around.

Where to make the change

  • Application code or templates: add explicit width and height (or aspect-ratio CSS) to every image, video, and embed so the browser can reserve space before the asset loads.
  • CSS: use aspect-ratio on responsive containers; use min-height on slots that load content asynchronously (ads, embeds, recommendations).
  • Cookie consent and overlays: render banners as fixed overlays rather than inserting them at the top of the document.

Common causes and how to resolve them

  • Images without dimensions: add width and height attributes (or set aspect-ratio in CSS) so the browser reserves the slot before the image loads.
  • Late-loading web fonts: use font-display: swap with size-adjust and matched fallback metrics so swapping the font does not change line heights.
  • Aggressively injected cookie consent banners: render them as a fixed overlay on top of the layout, not as a block element pushing content down.
  • Ads or embeds inserted without reserved space: reserve a fixed-size container for each slot so the surrounding content does not jump.
  • Animations that move layout-affecting properties: animate transform and opacity instead of top, left, or height.

Best practices

  • Target a CLS score of 0.1 or less at the 75th percentile: the official Core Web Vitals threshold for a "good" experience.
  • Reserve space for everything: if it loads after first paint, give it a fixed slot so it cannot push content.
  • Animate transform only: transform-based animations do not trigger layout and therefore do not produce layout shift.
  • Test on mobile first: small viewports amplify the perceived impact of layout shifts.
Measures Cumulative Layout Shift, the total amount that visible elements move around unexpectedly while the page loads. Layout shifts cause users to misclick and feel the page is unstable, and CLS is one of Google's Core Web Vitals and a direct ranking factor. Common causes include images without explicit dimensions, late-loading fonts, and aggressively injected overlays such as cookie consent banners.

Server and security

Score:64
Failed:3
Warnings:0
Passed:2
SSL Checker and HTTPS Test
100% of top 100 sites passed
This website is successfully using HTTPS, a secure communication protocol over the Internet.
The certificate is not used before the activation date.
The certificate has not expired.
The hostname "index.hu" is correctly listed in the certificate.
The certificate should be trusted by all major web browsers.
The certificate was not revoked.
The certificate was signed with a secure hash.
Certificate Chain:
Server certificate
Common Name
index.hu
Subject Alternative Names
index.hu, www.index.hu
Not Valid Before
Mon, November 24, 2025 at 12:00:00 AM UTC
Not Valid After
Fri, December 25, 2026 at 11:59:59 PM UTC
Signature Algorithm
sha256WithRsaEncryption
Issuer
Sectigo Public Server Authentication CA DV R36
Intermediate certificate
Common Name
Sectigo Public Server Authentication CA DV R36
Organization
Sectigo Limited
Location
GB
Not Valid Before
Mon, March 22, 2021 at 12:00:00 AM UTC
Not Valid After
Fri, March 21, 2036 at 11:59:59 PM UTC
Signature Algorithm
sha384WithRsaEncryption
Issuer
Sectigo Public Server Authentication Root R46
Root certificate
Common Name
Sectigo Public Server Authentication Root R46
Organization
Sectigo Limited
Location
GB
Not Valid Before
Mon, March 22, 2021 at 12:00:00 AM UTC
Not Valid After
Wed, March 21, 2046 at 11:59:59 PM UTC
Signature Algorithm
sha384WithRsaEncryption
Issuer
Sectigo Public Server Authentication Root R46
Verifies whether the site is served over HTTPS with a valid TLS certificate. HTTPS encrypts the connection between visitor and server, protecting credentials and other sensitive data in transit, and Google has used it as a positive ranking signal since 2014. Modern browsers also flag non-HTTPS pages as Not Secure, which damages user trust.
Mixed Content Test (HTTP over HTTPS)
100% of top 100 sites passed
This webpage does not use mixed content - both the initial HTML and all other resources are loaded over HTTPS.
Detects whether a page served over HTTPS is loading any sub-resources such as images, scripts, or stylesheets over insecure HTTP. Mixed content weakens the security guarantees of HTTPS, and modern browsers either block the resources outright or warn the user, often breaking the page in the process.
HTTP2 Test
99% of top 100 sites passed
This webpage is not using the HTTP/2 protocol!
Verifies whether the page and its resources are delivered over HTTP/2 or newer, rather than the legacy HTTP/1.1 protocol. HTTP/2 introduces multiplexing, header compression, and prioritization, which together reduce latency and allow the browser to load many resources from the same origin far more efficiently.
HSTS Test
84% of top 100 sites passed
This webpage is not using the Strict-Transport-Security header! This is a security header that was created as a way to force the browser to use secure connections when a site is running over HTTPS.

HSTS Test

How to pass this test?

The Strict-Transport-Security (HSTS) response header tells browsers to access the site only over HTTPS, automatically upgrading future requests and refusing to fall back to HTTP. Fixing this issue means configuring the server to send the header on every HTTPS response.

Example

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Where to make the change

  • Server configuration: add the header in Nginx (add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;), Apache (Header always set Strict-Transport-Security ...), or your application's response middleware.
  • CDN: Cloudflare, Fastly, and CloudFront let you set HSTS at the edge so it applies regardless of origin configuration.
  • Cloud platforms: Netlify and Vercel allow HSTS via headers files (_headers on Netlify, vercel.json on Vercel).

Common causes and how to resolve them

  • Header not sent: add it in the server or CDN config. Confirm in DevTools, Network tab.
  • Header sent only on HTTP responses: HSTS is only honored over HTTPS, so the header must accompany the HTTPS response.
  • Short max-age: a max-age below a few months provides little protection. Bump to a year (31536000) once you are confident HTTPS is stable.
  • includeSubDomains breaking subdomains that lack HTTPS: only add this directive after every subdomain serves HTTPS. Otherwise users will lose access to the HTTP-only ones.

Best practices

  • Start with a short max-age, then ramp up: a one-week max-age lets you back out quickly if something breaks. Increase to a year once stable.
  • Add preload after testing: submit your domain to hstspreload.org so browsers ship with HSTS for your site baked in. Note that removing a preloaded site is slow.
  • Pair with HTTP-to-HTTPS redirects: HSTS only kicks in after a successful HTTPS visit. Until then, redirects do the work.
Checks whether the server sends a Strict-Transport-Security header instructing browsers to only access the site over HTTPS. HSTS protects users from protocol downgrade attacks and accidental exposure to insecure connections, and is a baseline requirement for any site handling sensitive data.
Unsafe Cross-Origin Links Test
45% of top 100 sites passed
This webpage is using target="_blank" links without rel="noopener" or rel="noreferrer" attribute, which can expose it to performance and security issues!

Unsafe Cross-Origin Links Test

How to pass this test?

This test fails when external links opened in a new tab (with target="_blank") lack the rel="noopener" or rel="noreferrer" attributes. Modern browsers (Chrome 88+, Firefox 79+, Safari 12.1+) apply noopener implicitly, so this is largely a defense for older browsers and a way to keep the destination page from running in the same browser process as the original tab. Fixing this issue means adding the attributes explicitly to every external target="_blank" link.

Example

<a href="https://example.com" target="_blank" rel="noopener noreferrer">
  External link
</a>

Where to make the change

  • Application code or templates: search for target="_blank" and add rel="noopener noreferrer" to each match. A simple find-and-replace handles most cases.
  • WordPress: the block editor adds rel="noopener" automatically on every external link opened in a new tab. Older content may need a one-time bulk update.
  • Shopify, Wix, Squarespace: editor-generated links typically include the rel attributes. Manual HTML embeds need them added.
  • Headless or framework sites: wrap external links in a component that always sets the correct rel attributes.

Common causes and how to resolve them

  • Hand-written external links missing the attribute: add rel="noopener noreferrer" to each one.
  • Old content from before the editor added it automatically: a one-time bulk update through the database or CMS export covers it.
  • Markdown-rendered content: configure the renderer to add the attributes to every external link by default.

Best practices

  • Use noopener noreferrer together: noopener handles the security concern, noreferrer additionally hides the referring URL. Both are safe defaults for most external links.
  • Reserve target="_blank" for genuinely external links: internal links should open in the same tab so users can use the back button naturally.
  • Add a lint rule: ESLint plugins for React and similar frameworks can enforce the rel attribute automatically.
Inspects external links opened in a new tab to confirm they include the noopener or noreferrer relationship attributes. Modern browsers now apply noopener implicitly to such links, so this is largely a defense for older browsers and a way to keep the destination page from running in the same process as the original tab. Including the attributes explicitly remains a security and performance best practice.

Mobile usability

Score:100
Failed:0
Warnings:0
Passed:3
Meta Viewport Test
92% of top 100 sites passed
This webpage is using a viewport meta tag.
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
Checks whether the page declares a viewport meta tag that controls how the layout scales on mobile devices. Without it, mobile browsers render the page at a default desktop width and shrink it to fit, producing unreadable text and unusable touch targets. A correct viewport declaration is the foundation of responsive design.
Media Query Responsive Test
98% of top 100 sites passed
This webpage is using CSS media queries, which is the base for responsive design functionalities.
Detects whether the page's stylesheets use CSS media queries to adapt the layout to different screen sizes. Media queries are the primary mechanism for responsive design, allowing typography, spacing, and component arrangement to adjust gracefully from phones to large desktops. Because Google now indexes the web mobile-first, the responsive mobile layout is effectively the version search engines crawl, evaluate, and rank.
Mobile Snapshot Test
Mobile view
A rendered screenshot of how the page appears on a mobile device. Useful for visually confirming that responsive layouts work as intended and for spotting issues such as overflowing content, illegible text, or broken images that automated checks alone may miss.

Advanced SEO

Score:95
Failed:1
Warnings:0
Passed:8
Structured Data Test
66% of top 100 sites passed
This webpage is using structured data.
Inspects the page for structured data markup such as JSON-LD or Microdata that follows schema.org vocabularies. Structured data helps search engines understand entities and relationships on the page, often unlocking rich result features in SERPs such as star ratings, FAQs, recipes, and product cards. It is also a primary signal AI answer engines use to extract precise facts when generating responses.
Custom 404 Error Page Test
80% of top 100 sites passed
This website is using a custom 404 error page. We recommend to have a custom 404 error page in order to improve the website's user experience by letting users know that only a specific page is missing/broken (and not the entire site), providing them helpful links, the opportunity to report bugs, and potentially track the source of broken links.
Detects whether the site serves a branded, helpful page when a requested URL is not found, instead of the browser's generic error screen. A custom 404 keeps users on the site by offering navigation, search, or suggested links, which reduces frustration and protects engagement metrics that influence both UX perception and indirect SEO outcomes.
Noindex Tag Test
99% of top 100 sites passed
This webpage does not use the noindex meta tag. This means that it can be indexed by search engines.
Detects whether the page is being excluded from search engine indexes via a noindex directive in the robots meta tag or X-Robots-Tag HTTP header. A noindex on the wrong page is one of the most common ways important content silently disappears from search results, so verifying its absence on pages meant to rank is critical.
Canonical Tag Test
93% of top 100 sites passed
This webpage is using the canonical link tag. This tag specifies that the URL: https://index.hu/ is preferred to be used in search results. Please ensure that this specification is correct, as canonical tags are often hard-coded and may not always reflect the latest changes in a site's URL structure.
<link href="https://index.hu/" rel="canonical"/>
Detects whether the page declares a canonical link tag indicating its preferred URL. Canonical tags consolidate ranking signals across duplicate or near-duplicate URLs onto a single authoritative version, which prevents search engines from splitting authority across variants caused by query parameters, session IDs, or alternate paths. They also help AI crawlers identify the source of truth when citing the page.
Nofollow Tag Test
This webpage does not use the nofollow meta tag. This means that search engines will crawl all links from this webpage.
Detects whether the page applies a nofollow directive, either through a robots meta tag, an X-Robots-Tag header, or per-link rel attributes, that tells search engines not to follow outbound links. Google recommends nofollow for sponsored links and for user-generated content where the linked sites are not vetted, so its presence or absence has real consequences for how link equity flows.
Disallow Directive Test
Your robots.txt file includes a disallow command which instructs search engines to avoid certain parts of your website! You are advised to confirm if access to these resources or pages are intended to be blocked (e.g., if they contain internal-only content or sensitive information).
Surfaces the disallow rules declared in the site's robots.txt file. Disallow directives tell search engine crawlers not to access specific files, paths, or directories, which is useful for keeping admin sections and duplicate content out of indexes but dangerous when applied too broadly, since over-blocking can hide important pages from search.
Meta Refresh Test
98% of top 100 sites passed
This webpage is not using a meta refresh tag.
Detects whether the page uses a meta refresh tag to automatically reload or redirect after a delay. Meta refresh is largely obsolete, hurts accessibility by jumping focus and disorienting screen reader users, and is a weaker signal to search engines than a proper server-side 301 redirect. Its presence usually indicates outdated implementation worth updating.
SPF Records Test
94% of top 100 sites passed
This DNS server is using an SPF record.
v=spf1 a mx include:_spf.inda.hu include:_spf.google.com ?all
Checks the domain's DNS for a Sender Policy Framework record. SPF lets receiving mail servers verify that messages claiming to come from the domain were actually sent by an authorized mail server, which significantly reduces the chance of legitimate email being marked as spam and protects the domain's sender reputation.
Ads.txt Validation Test
67% of top 100 sites passed
This website is using an Authorized Digital Sellers (ads.txt) file, but its content has invalid records! Having errors in this file would cause advertisers to not recognize and ignore the authorized sellers list and that will lead to lost revenue.

Ads.txt Validation Test

How to pass this test?

The ads.txt file is a public list of the advertising vendors authorized to sell your inventory programmatically. A correctly formatted ads.txt protects against domain spoofing in the ad supply chain and is required for inclusion in many premium advertising marketplaces. Fixing this issue means publishing a valid ads.txt at the site root with current authorized seller entries.

Example

google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0
example-ssp.com, 12345, RESELLER
contact=ads@example.com

Where to make the change

  • Raw HTML or static site: upload ads.txt to the site root so it is served at https://example.com/ads.txt.
  • WordPress: use a small plugin or upload the file via FTP. Some advertising plugins manage it automatically based on connected accounts.
  • Shopify: upload the file through the theme code editor as an asset, then expose it at the root via a route configuration.
  • Cloudflare or similar CDN: serve ads.txt from a worker if you do not have file-system access at the origin.

Common causes and how to resolve them

  • File missing: create one with at least your direct advertising relationships.
  • File at the wrong path: ads.txt must be at the domain root, not in a subdirectory.
  • Wrong relationship value: use DIRECT for direct seller relationships, RESELLER for authorized resellers. Other values are invalid.
  • Stale entries: partners change; remove relationships you no longer have so spoofers cannot exploit them.
  • Returning HTML instead of plain text: the file must be served as text/plain. A page that returns HTML or a 404 fails validation.

Best practices

  • Audit quarterly: stale entries are the main source of ads.txt vulnerabilities.
  • Mirror app-ads.txt for mobile inventory: apps use a parallel app-ads.txt file with the same syntax.
  • Add a contact line: include a contact=email@example.com line so vendors can reach the right person about ad-quality issues.
Validates the format of the site's ads.txt file, which publishers use to declare which advertising vendors are authorized to sell their inventory programmatically. A correctly formatted ads.txt protects against domain spoofing in the ad supply chain and is required for inclusion in many premium advertising marketplaces.

Dominate search today on Google and AI Engines.

Join 85,000+ SaaS Marketers, Growth Agencies, Content-Led Companies and E-commerce Brands.

See Pricing
Dashboard preview showing SEO site checkup metrics, page group insights, and issue prioritization