What Tuqo checks when you publish
A site made with AI is almost always published with the same mistakes: an API key in the files, a link to localhost, megabytes of images inside the HTML, a form that submits nowhere. Tuqo finds them at publish time and explains what to do. It doesn't block, doesn't spam you with emails, and leaves the decision to you.
Publish as usual
Files from the panel or an AI agent, an archive, the CLI or Git — checks run on every publishing path, with nothing to set up.
Tuqo reads the site's files
HTML, CSS, JS, robots.txt: links, head tags, forms, the size of images embedded in HTML. Only the files in your set — no requests to the site from outside and no third-party services.
It shows what to fix
A chip next to the site's address that counts the issues, a “What to improve on the site” checklist page with the reason and the fix, and for AI agents a recommendations field right in the publish response.
Worth fixing (10)
Issues that keep the site from working as intended or expose too much. The site's chip in the panel turns yellow.
Files and structure Link to a file that doesn't exist: css/style.css
Why. The page refers to a file that isn't in the set: styles won't apply, the image won't show, the script won't run.
What to do. Add the file to the set or fix the path. Letter case and folders in the path matter.
Secrets and private data A Tuqo key found in the files: tqk_d0ec02_…
Why. The key gives access to the project through the API and MCP: any visitor could change your sites.
What to do. Remove the key from the files and publish again, then reissue the key in the project settings (API keys section).
Secrets and private data Something that looks like a secret: a Telegram bot token
Why. A token, a cloud key or a private key in a public file is as good as publishing a password.
What to do. Remove the secret from the files, publish again and revoke it with the service that issued it.
Links and resources Links to localhost or local files: http://localhost:3000/api
Why. It worked on the developer's computer; visitors won't be able to open it.
What to do. Replace them with addresses on the published site, or remove them.
Links and resources Resources over http:// on a secure site: http://cdn.example.com/lib.js
Why. The site opens over https, and the browser blocks scripts and styles loaded over http and marks images as insecure.
What to do. Change http:// to https:// or put the files into the site's set.
Page head and search The site is hidden from search: meta robots noindex
Why. Google and Yandex won't show the site in results. Often left over from a template or a test build.
What to do. Remove the tag if the site should be found in search.
Page head and search robots.txt blocks crawling of the whole site
Why. Search engine crawlers won't visit a single page.
What to do. Remove the Disallow: / line from robots.txt, or list only the sections that should be closed.
Page head and search No meta viewport: the site looks tiny on phones
Why. Without it a phone renders the page as if on a desktop monitor, and the text is unreadable without zooming.
What to do. Add to the head: <meta name="viewport" content="width=device-width, initial-scale=1">.
Weight and speed Images embedded in HTML: 4.6 MB of base64 (3)
Why. The whole page has to load before the first paint, and base64 doesn't compress. On a phone, visitors wait several seconds.
What to do. Pass images as separate files (in deploy_files with encoding: base64) and keep only links in the HTML. While you're at it, scale them down to their actual on-screen size.
Forms A form with no submit address
Why. The Submit button doesn't send anything.
What to do. Take the form code from the site's Forms tab: submissions will arrive in Tuqo, in notifications and in the auto-reply.
Could be improved (4)
Advice on how the site looks in search and messengers, and on forms. The chip is teal.
Page head and search The page title is “Document”
Why. The title shows in the browser tab, in bookmarks and in search results.
What to do. Put the name and the point of the page in <title>, for example “Your Office — coworking desks in Sochi”.
Page head and search No favicon
Why. The browser tab and bookmarks show the site with a blank icon.
What to do. Put favicon.svg or favicon.png in the root and add <link rel="icon" href="/favicon.svg"> to the head.
Page head and search No link preview for messengers
Why. A link to the site in Telegram, WhatsApp or VK shows up without an image or a description.
What to do. Add og:title, og:description and og:image with a 1200×630 image to the head.
Forms The form sends submissions to a third-party service: formspree.io
Why. Submissions go to another service. Tuqo can receive them too: they would land on the Forms tab, in notifications and in the auto-reply. If this is intended, leave it as is.
What to do. To receive submissions in Tuqo, take the form code from the site's Forms tab and use it instead of the current one.
Where you see them
Chip on the site
Next to the domain chip: yellow if something is worth fixing, teal if it's advice only. Counters for both levels and a View button.
Checklist page
Every issue: a title, why it matters, what to do and exactly where (file and line, up to 10 places). Mark as done and Hide are remembered in your browser.
Prompt for AI
The Copy for AI button turns the issues into a ready prompt: paste it into Claude, ChatGPT or Cursor, and the agent fixes the files and publishes again.
Response to the agent
Over MCP and REST, issues come in the recommendations field of the publish response, the deploy status and the site card: the first five plus a count of the rest. The agent offers to fix them; the decision is yours.
What the agent sees
Part of a deploy_files response over MCP; REST and get_site carry the same field:
"recommendations": {
"summary": { "fix": 2, "improve": 1 },
"items": [
{ "code": "tuqo-key", "level": "fix",
"title": "A Tuqo key found in the files: tqk_d0ec02_…",
"how": "Remove the key from the files and publish again, then reissue the key in the project settings (API keys section)." },
{ "code": "localhost", "level": "fix",
"title": "Links to localhost or local files: http://localhost:3000/api" },
{ "code": "og", "level": "improve", "title": "No link preview for messengers" }
],
"more": 0,
"note": "These are recommendations for the site files, not errors: the site is published and working. Ask the owner what to apply; don't change anything else."
}Over MCP the title, why, how and note texts are always in English, as here. Over REST and in the panel they follow the request language (Accept-Language: en for English, otherwise Russian). The code and level fields are the same in any language.
- Runs on every publishing path: panel, AI agent, archive, CLI, Git CD
- Service files (.git, .env, SSH keys) are never published — separately from the checks
- A toggle in site settings, plus Mark as done and Hide on every issue
- No notifications and no “Check now” button — the checklist lives with the publish
Publish checks — frequently asked questions
Can the checks block a publish? +
No. They are recommendations: the site is published either way, and the issues are shown next to it. What to fix is your call. The only thing Tuqo never publishes is service files such as .git, .env and SSH keys: they are dropped on upload, with a notice.
How do I turn them off? +
Site settings have a toggle, Show recommendations after publishing. Turned off, the checks are not computed at all, and the chip and the recommendations field disappear. Turned back on, Tuqo recalculates them for the current publish. You can also hide a single issue with Hide.
What exactly do you read? +
Only the files in your set: HTML, CSS, JS and robots.txt up to 2 MB each, up to 24 MB in total per run. Images and archives are not read; only their names are looked at. We don't fetch your site from outside and pass nothing to third-party services.
Will I get notifications? +
No, on purpose: an email on every deploy would turn a useful checklist into spam. The issues wait for you in the panel and in the agent's response.
What if a check is wrong? +
It happens. Say a form sends submissions to your own server rather than to Tuqo: the check honestly warns you, but nothing is broken. Click Hide and the issue won't come back for that site. Send false positives to support — we fix the rules.
Why only 14 checks? +
This is the first wave: the things that most often break sites made with AI or published for the first time. The catalog holds 35 more candidates — page weight, accessibility, legal, counters. We add them on demand so the checklist stays short and honest.
Which plans include them? +
All of them, including Free. Checks are part of publishing, not a paid feature.
Publish and see what to fix
No setup, on every plan. An AI agent gets the issues right in its response and fixes them itself.