{"slug": "i-built-a-tool-that-detects-broken-security-headers-missing-robots-txt-and-wp-a", "title": "I built a tool that detects broken security headers, missing robots.txt, and WP_DEBUG=true — then opens a PR to fix them automatically", "summary": "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.", "body_md": "Every agency I've talked to has the same story.\nClient 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.\nI 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.\nThe workflow\nDetect → Explain → Preview fix → Open PR → You approve\nConfidence scores\nThis 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).\nSo every fix has a confidence score:\n| Issue | Fix | Confidence |\n|------------------------------|------------------------------------------|------------|\n| WP_DEBUG = true | define('WP_DEBUG', false) in wp-config | 95% |\n| robots.txt missing | Valid file with User-agent: * / Allow: / | 90% |\n| Missing security headers | HSTS, X-Frame-Options, CSP | 88% |\n| Missing viewport / canonical | Correct meta tag added | 85% |\n| No cache headers | Cache-Control: max-age=31536000 | 75% |\n| Missing SEO title/desc | Placeholder — needs your review | 62% |\nGreen (≥85%) = safe to merge after a quick look. Amber (≥70%) = test on staging. Orange (<70%) = treat as a starting point, edit before merging.\nAuto-detecting the right file\nOne thing I didn't want to do: assume everyone is on Netlify.\nWhen DevLab generates a security header fix, it reads your repo and tries candidate files in order:\nnetlify.toml → adds a [[headers]] block\n.htaccess → adds Header always set inside mod_headers\nnginx.conf (or nginx/default.conf) → injects add_header into the server block\nFor SEO fixes it detects the framework:\nNext.js App Router → edits app/layout.tsx using the metadata export\nPlain HTML → injects tags into\nWhy I built the preview step\nMy first instinct was to make \"Generate PR\" a single button. Ship it, done.\nThen 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.\nSo now the flow is:\nClick \"Preview fix\"\nModal 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\nClick \"Open PR\" to proceed — or just close the modal\nThe PR opens on a dedicated branch (sitebrief/fix-security-headers style), so it's isolated and easy to close if you change your mind.\nOne-click rollback\nIf 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.\nNo need to go to GitHub just to close a PR.\nWhat's next\nShort-term:\nStaging branch deploys — open the fix PR against a staging branch, not main\nDependency security updates — scan package.json / composer.json, PR with safe version bumps\nScheduled digest — weekly email: all issues + open fix PRs across your portfolio\nIf 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.\nHappy to answer questions about the implementation, the PR flow, or how the file detection works.\nSiteBrief is in early access — sitebrief.io", "url": "https://wpnews.pro/news/i-built-a-tool-that-detects-broken-security-headers-missing-robots-txt-and-wp-a", "canonical_source": "https://dev.to/sitebrief/i-built-a-tool-that-detects-broken-security-headers-missing-robotstxt-and-wpdebugtrue-then-23jd", "published_at": "2026-05-21 16:20:43+00:00", "updated_at": "2026-05-21 16:35:19.845297+00:00", "lang": "en", "topics": ["developer-tools", "cybersecurity", "open-source", "products", "startups"], "entities": ["SiteBrief", "DevLab", "GitHub", "GitLab", "Google Search Console"], "alternates": {"html": "https://wpnews.pro/news/i-built-a-tool-that-detects-broken-security-headers-missing-robots-txt-and-wp-a", "markdown": "https://wpnews.pro/news/i-built-a-tool-that-detects-broken-security-headers-missing-robots-txt-and-wp-a.md", "text": "https://wpnews.pro/news/i-built-a-tool-that-detects-broken-security-headers-missing-robots-txt-and-wp-a.txt", "jsonld": "https://wpnews.pro/news/i-built-a-tool-that-detects-broken-security-headers-missing-robots-txt-and-wp-a.jsonld"}}