Site Rescue

Inspiration

Website audits are good at telling you what is wrong, but they often leave the harder question unanswered: what should I fix first?

I have worked with website projects where a report can contain a long list of technical, SEO, accessibility, and performance issues. Knowing that those issues exist is useful, but turning them into a practical sequence of work still takes time.

That led to the idea for Site Rescue: instead of stopping at an audit, turn the findings into a prioritized rescue plan.

The goal became simple:

Find what's broken. Fix what matters.

What it does

Site Rescue lets you paste a website URL and get a structured rescue plan.

It first performs a real website scan and crawls multiple pages within a controlled scope. The scanner checks for concrete issues across areas such as SEO, accessibility, technical configuration, performance, and page structure.

The results are then organized into three priority levels:

• Fix now
• Fix next
• Improve later

Each finding includes the evidence produced by the scanner, and the AI turns those findings into plain-English explanations and developer-ready tasks.

The important distinction is that the scanner is the source of truth. The AI does not invent website problems. It receives the structured findings and evidence from the scanner and focuses on explaining, prioritizing, and turning them into actionable work.

How we built it

I built Site Rescue from an empty project using the Devpost Learn Skill Pack with OpenCode.

The application uses a Node.js and Express backend with a browser-based frontend. The scanner handles URL validation, secure crawling, page discovery, HTML analysis, response measurements, and structured findings.

For the AI layer, I used OpenRouter with a free model. The AI receives bounded scanner evidence and its generated plan is validated before being shown to the user.

I also built the project as an installable PWA, so the same application can run as a standalone web app.

Security and honest reporting were important parts of the implementation. The scanner validates URLs, protects against requests to private or local addresses, revalidates redirects, respects crawl boundaries, handles non-HTML responses, and distinguishes successful, partial, and failed scans.

Challenges we ran into

One of the biggest challenges was deciding how much the scanner should do.

It would have been easy to keep adding checks until Site Rescue became a huge auditing platform. Instead, I had to keep the proof of concept focused on one complete workflow: scan a real site, produce reliable findings, and turn those findings into useful next actions.

Another challenge was making sure the AI could not quietly turn missing information into invented findings. I solved this by keeping the scanner responsible for detection and giving the AI only structured findings and evidence to work with.

Handling real websites also introduced practical challenges around redirects, non-HTML pages, crawl limits, failed requests, slow responses, and secure URL handling.

Accomplishments that we're proud of

I'm proud that Site Rescue became a working end-to-end product rather than just an AI-generated report interface.

A real website can be scanned across multiple pages, findings can be traced back to scanner evidence and specific pages, and the AI can turn those findings into a prioritized rescue plan.

I'm also proud of the boundaries around the AI. The system does not ask the model to guess what is wrong with a website. It gives the model verified evidence and asks it to make that evidence useful.

The project also ended up as an installable PWA, giving the same application a more complete product experience.

What we learned

The biggest lesson was that planning before implementation matters, especially when working with an AI coding agent.

Using the Learn Skill Pack forced me to define the scope, requirements, acceptance criteria, and boundaries before letting the agent build. That made it much easier to catch problems early and verify that the implementation actually matched the idea.

I also learned that AI becomes much more useful when its role is clearly defined. Instead of asking it to discover everything, I gave it a specific job: take reliable evidence and turn it into useful decisions and developer work.

What's next for Site Rescue

The current version is intentionally a focused proof of concept.

The next step would be expanding the audit catalog while keeping the evidence-first approach. I would also like to make the generated developer tasks more actionable, add deeper recommendations for individual issues, and eventually let users track the progress of a website's rescue plan over time.

The core idea would remain the same:

Website → Evidence → Priorities → Developer-ready fixes.

Built With

• ai
• cheerio
• css
• express.js
• html
• javascript
• node.js
• openrouter
• puppeteer
• pwa
• tailwind-css
• web-scrapping