I built a tool that detects broken security headers, missing robots.txt, and WP_DEBUG=true — then opens a PR to fix them automatically

DevLab, a new feature of the web agency tool SiteBrief that automatically detects common website misconfigurations—such as exposed debug modes, missing security headers, and absent robots.txt files—and generates fixes with confidence scores. The tool then opens a GitHub or GitLab pull request for the user to review and approve, offering a preview step to ensure transparency and a one-click rollback option. It supports multiple server configurations and frameworks, aiming to save agencies from repeatedly fixing the same issues across client sites.

Every agency I've talked to has the same story. Client calls on a Friday. Site is down or flagged by Google Search Console. You SSH in, find WP DEBUG = true in production, turn it off, deploy, done. Twenty minutes gone. Next week, different client, same thing. I run a small web agency tool called SiteBrief — it monitors uptime, SSL, PageSpeed, SEO, and security headers across client sites. After six months of watching the same issues appear on the same types of sites, I built DevLab: a section that not only detects problems but generates the fix and opens a GitHub PR or GitLab MR for your review. The workflow Detect → Explain → Preview fix → Open PR → You approve Confidence scores This was the part I spent the most time thinking about. "AI generates fixes" sounds scary. The honest answer is: some fixes are deterministic swap true for false in one line , others are educated guesses write an SEO title for a site you've never seen . So every fix has a confidence score: | Issue | Fix | Confidence | |------------------------------|------------------------------------------|------------| | WP DEBUG = true | define 'WP DEBUG', false in wp-config | 95% | | robots.txt missing | Valid file with User-agent: / Allow: / | 90% | | Missing security headers | HSTS, X-Frame-Options, CSP | 88% | | Missing viewport / canonical | Correct meta tag added | 85% | | No cache headers | Cache-Control: max-age=31536000 | 75% | | Missing SEO title/desc | Placeholder — needs your review | 62% | Green ≥85% = safe to merge after a quick look. Amber ≥70% = test on staging. Orange <70% = treat as a starting point, edit before merging. Auto-detecting the right file One thing I didn't want to do: assume everyone is on Netlify. When DevLab generates a security header fix, it reads your repo and tries candidate files in order: netlify.toml → adds a headers block .htaccess → adds Header always set inside mod headers nginx.conf or nginx/default.conf → injects add header into the server block For SEO fixes it detects the framework: Next.js App Router → edits app/layout.tsx using the metadata export Plain HTML → injects tags into Why I built the preview step My first instinct was to make "Generate PR" a single button. Ship it, done. Then I showed it to three agency owners. All three asked: "But what exactly is it going to change?" That was the signal. Nobody wants a black box touching client repos. So now the flow is: Click "Preview fix" Modal shows: action description, exact file path, confidence bar with color coding, a safety note "this adds headers to netlify.toml — it will not touch your application code" , and the "Nothing merges automatically" guarantee Click "Open PR" to proceed — or just close the modal The PR opens on a dedicated branch sitebrief/fix-security-headers style , so it's isolated and easy to close if you change your mind. One-click rollback If you open a PR and then decide against it, there's a Close button directly in the DevLab history panel. It calls GitHub's PATCH /pulls/{number} state: closed or GitLab's PUT /merge requests/{iid} state event: close and marks the fix as rolled back in our records. No need to go to GitHub just to close a PR. What's next Short-term: Staging branch deploys — open the fix PR against a staging branch, not main Dependency security updates — scan package.json / composer.json, PR with safe version bumps Scheduled digest — weekly email: all issues + open fix PRs across your portfolio If you run a dev shop with multiple client sites and you're tired of playing whack-a-mole with the same misconfigs every month — that's exactly who DevLab is for. Happy to answer questions about the implementation, the PR flow, or how the file detection works. SiteBrief is in early access — sitebrief.io