lacna3dtlac.sk

Your site has no robots.txt file at all. That file is the front-door sign for every robot: what to read, what to skip, and where your sitemap lives.

Without one, every crawler guesses. Most treat a missing file as "allowed", but you lose the one place to point them at your sitemap and to state your policy explicitly. An explicit welcome is a clearer signal than silence.

1. Create a plain text file named robots.txt.
2. Start permissive: "User-agent: *" then "Allow: /", plus a "Sitemap:" line pointing at your sitemap URL.
3. Serve it at exactly yoursite.com/robots.txt (site root, not a subfolder).

• Open yoursite.com/robots.txt. You should see your file, not a 404 page.
• Re-scan: "robots.txt present" flips to PASS, and if you added the Sitemap line, "Sitemap present" often flips with it.

• Don’t copy a robots.txt from another site. Theirs encodes their policy, including blocks you may not want.
• Don’t return an HTML error page at that URL with status 200; robots parsers read it as garbage rules.

Of everything your server sends for this page, very little is actual readable text. The rest is code, styling, and markup wrapper. Agents fetched a lot of bytes and found few words.

Agents work with retrieval budgets. A page that is 2% text either gets skimmed (and mis-summarised) or skipped. More signal per byte means more of your actual message survives into the agent’s summary.

1. Confirm your real copy is server-rendered. See the JavaScript check; these two usually fail together.
2. Cut boilerplate wrappers: deeply nested divs, inline SVG logos repeated per section, base64 images inlined into HTML.
3. Move large inline styles and scripts into external files.
4. Check how much of the document is inline script: your report now says. If most of it is, that is your framework serializing state for hydration, often a second copy of text already in the HTML. Send only the props a component cannot recompute, and render statically where a page does not need to hydrate.

• Re-scan: "Text-to-markup ratio" improves, and "Page weight" often improves alongside.

• Don’t pad the page with keyword text to inflate the ratio. The ratio is a proxy for substance, and stuffing is the opposite of substance.

The <title> tag is the page’s name: the text in the browser tab. Yours is missing, empty, or generic (e.g. just "Home"), so machines have no usable name for this page.

The title is the single most-quoted identifier for a page; agents cite it verbatim when referencing you. A missing one gets replaced with a guess assembled from headings, which amounts to your page’s name being written by someone else.

1. Give every page a unique, descriptive title in the shape "What the page is | Brand", under about 60 characters.
2. Set it in your framework’s metadata mechanism (Next.js Metadata API, WordPress SEO plugin, Shopify page settings) so it is per-page, not hardcoded site-wide.

• Each page shows its own title in the browser tab.
• Re-scan: "Page title" flips to PASS.

• Don’t stuff keywords. The title is quoted verbatim in agent answers, and a keyword string reads as spam exactly where customers see it.
• Don’t reuse one title across all pages; identical names make pages indistinguishable in citations.

Your structured data exists but only covers the basics (say, Organization) while the page is really a product page, an article, or an FAQ. The machine-readable caption is missing the part that describes what this page actually is.

An agent looking for "running shoes under $100" matches against Product markup with offers. A product page carrying only Organization markup is invisible to that query shape: the agent knows who you are but not what this page sells.

1. Identify the page’s real type: Product (with offers), Article, FAQPage, HowTo, LocalBusiness, Event.
2. Add that type’s JSON-LD alongside the Organization block, filled from the page’s actual content.
3. For Product: include name, price, priceCurrency, and availability. Those are the fields agents actually query.

• Re-scan: "Schema type coverage" improves. Keep "Structured data validates" green while you add.
• The coherence checks below compare your declared price and name to the visible page; they should stay (or flip to) PASS.

• Only declare types the page genuinely is. A blog post marked up as a Product to appear in shopping queries is the exact incoherence assistants are getting better at detecting.
• Keep declared values synced with the page. If a sale changes the visible price, the JSON-LD price must change in the same deploy.

Time to first byte is how long your server thinks before it starts answering: the gap between an agent asking for the page and the first byte of HTML arriving. Yours crossed our threshold (under 200ms scores full marks, over 2 seconds fails).

Agents fetch with tight timeouts and many pages in parallel. A server that takes seconds to start answering gets cut off mid-queue, and a page that times out is a page that was never read. Speed here is not polish; it decides whether the content gets fetched at all.

1. Cache the HTML itself. Marketing and docs pages rarely change per visitor; serve them from a CDN or static cache so no application code runs per request.
2. If you are on serverless hosting, cold starts are a common cause: keep the function warm or pre-render the page.
3. Move slow work (database queries, third-party API calls) out of the first response; render the shell fast and fill personalised details after.

• Run: curl -o /dev/null -s -w "%{time_starttransfer}\n" https://yoursite.com and watch the number drop.
• Hit Re-scan above: "Time to first byte" improves a bucket at a time (under 500ms passes).

• Don’t answer fast with an empty shell that loads content by JavaScript. That trades this warning for the much worse "content requires JavaScript" failure, since most agents never run your scripts.
• Don’t special-case known crawler user agents onto a faster path. Serving different performance to different audiences is the pattern crawlers penalise when they detect it.