Audit details
Measured findings were computed from the crawl by code and list the pages they were seen on. Judgement findings were written by the strategist model from the same crawl: review them before acting.
site-domobot.vercel.app
A real scan, unedited. Open a finding to see the pages it was measured on, or read the rankfile.md your coding agent would get.
94 out of 100
8 measured tasks, 2 to fix first, plus 5 strategist suggestions to review. 46 pages crawled, scanned 22d ago.
Hand it to your coding agent
13 tasks · about 3 minutes to start- Put the Rankfile in the site's repository
On your own scans this is a ZIP to unzip at the root of the repo. Here, read the rankfile.md it contains.
- Start your agent
In a terminal, from the root of the site's repository:
claude "$(cat prompt.md)"
What prompt.md says
I ran Rankfile on https://site-domobot.vercel.app. The result is rankfile.md, with the skills it references in .claude/skills/ and the site's SEO memory in rankfile/. First, wire the memory so it survives new sessions: 1. Add the line "@rankfile/seo-map.md" to CLAUDE.md at the repository root (create the file with that line if there is none). 2. In .claude/rules/rankfile-pages.md, set the paths: list to where this repository keeps its pages, then leave the rules as they are. 3. Merge rankfile/settings.json into .claude/settings.json (create it if missing): it protects robots.txt with a hook. Then read rankfile.md and work through its tasks in order. For each task: 1. Load the skill it names from .claude/skills/<skill>/SKILL.md, plus .claude/skills/seo-site-domobot-vercel-app/SKILL.md. 2. Read rankfile/pages/<page>.md when the task touches a money page listed in rankfile/seo-map.md. 3. Find the templates or pages in this codebase that produce the affected URLs. 4. Make the change, tick the task's checkbox in rankfile.md, and add a dated line to rankfile/decisions.md. Tasks marked "judgement" are proposals: tell me what you plan to change before doing them. Never change the URL of a page that already serves content; ask before deleting a page.
- Scan again once the changes are live
The next scan lists the tasks that are done, those still open and anything new, with the score change. Deploy first: Rankfile reads the live site.
Fix first
All 13 findings- high1 page shows part of its text only after JavaScript runs
Render this content on the server or at build time (pre-render the route, or move the data fetch into the server component / getStaticProps), so the text is in the first HTML response.
- high1 page shifts layout while loading
Give images, embeds and ads explicit
width/height(oraspect-ratio), reserve space for content loaded after the page (tables, banners), and avoid inserting elements above existing content. - medium4 pages take over 2.5 s to show the main content on a phone
Find the largest element (usually the hero image or heading): serve the image in AVIF/WebP at its displayed size with
fetchpriority="high"and no lazy-loading, preload the font it uses, and cut the JavaScript that runs before it paints. - medium1 page blocks the phone's main thread for over 600 ms
Ship less JavaScript on these pages: split bundles per route, defer third-party scripts, and render static parts on the server instead of hydrating them.
Score by area
- Technicalcrawl, indexing, sitemap, links
- 94
- Contenttitles, descriptions, headings, depth
- 96
- Structured dataJSON-LD on the pages
- 100
- AI searchllms.txt, AI crawlers
- 96
- Speeddownload, phone rendering, real visitors
- 83
100 minus what the measured tasks cost, weighted by severity and by the share of pages affected. A progress gauge for the Rankfile, not a ranking prediction.
Measured in a phone browser
| Page | Main content shown | Layout shift | Blocking time | JavaScript | Words served → after JS |
|---|---|---|---|---|---|
| / | 3.3 s | 0 | 264 ms | 173 KB | 1111 → 1111 |
| /robots | 2.8 s | 0.003 | 603 ms | 173 KB | 361 → 361 |
| /guides | 2.5 s | 0.002 | 174 ms | 173 KB | 121 → 121 |
| /compare | 2.0 s | 0.463 | 459 ms | 173 KB | 25 → 159 |
| /news | 3.1 s | 0 | 67 ms | 173 KB | 492 → 492 |
| /about | 1.4 s | 0 | 25 ms | 173 KB | 208 → 208 |
One page per site section, in Rankfile's browser with a phone screen, slow 4G and a 4× slower CPU (Lighthouse's mobile conditions). Good: content shown within 2.5 s, layout shift under 0.1, blocking time under 200 ms. Lab figures: real visitors may be faster or slower.
What this audit covered
46 pages read as the server sends them. The page limit was not reached; pages that nothing links to and the sitemap omits can still be missing.
Not measured: Core Web Vitals from real visitors: no GOOGLE_API_KEY is set, so the Chrome UX Report was not queried; Rendering with JavaScript and lab speed: 6 of 46 pages rendered in a phone browser (one per site section); the others were read as served HTML; Keyword positions and impressions: Search Console is read only for scans run from the app by a connected account; Backlinks: no link index is connected.