GPT-6 Astra for Website Audits: What It Found on FloxoLab

We did not accept the list on trust. Every finding had to be reproduced or confirmed in source, ranked by real impact, fixed in the correct source-of-truth file, tested locally, and checked again in production. That verification step is the difference between a useful AI-assisted audit and a polished list of guesses.

This is a field report about using Astra inside Codex with repository and read-only web access. It is not a benchmark, a ChatGPT plan review, an API migration tutorial, or evidence that an AI model replaces a crawler or technical reviewer.

What GPT-6 Astra is

OpenAI describes GPT-6 Astra as its most capable model for difficult end-to-end work. Its API documentation lists a 1,050,000-token context window and support for tools including web search, hosted shell, computer use, MCP, and apply patch.

Those are the relevant capabilities for this test. A modern site may span JSX, a content manifest, build scripts, server routes, and a hosting artifact. A large context window and tool access let Astra inspect those relationships instead of reviewing one pasted HTML file in isolation.

OpenAI's API price on September 7, 2026 was $10 per million input tokens and $50 per million output tokens. That supports aiming Astra at difficult investigations rather than every routine edit. We did not preserve a controlled cost comparison for this audit.

Specifications and prices were checked on September 7, 2026 against the official GPT-6 Astra model page and OpenAI's model guidance.

How we tested Astra on a real website

The target was FloxoLab, a live static-content and Node.js site with SEO guides, automation articles, interactive tools, an Express backend, generated hosting artifacts, and automated checks. The audit was conducted on September 4, 2026. Remediation and production verification followed on September 5.

Astra received more than a URL. It could inspect the repository, current architecture notes, content and routing rules, selected production responses, and validation commands. The brief imposed five constraints:

1. Make no changes during the audit.
2. Report only reproducible findings, not generic best practices.
3. Give the affected file or URL, code evidence, impact, and priority.
4. Finish with only the 10 changes likely to deliver the most real value.
5. Distinguish repository behavior from CDN or hosting behavior.

That scope mattered. Astra did not receive permission to “improve everything.” It had to prove that a defect existed and explain why it deserved attention.

5 findings a normal page-level audit could easily miss

1. A timeout that did not stop the underlying request

FloxoLab's MentionProof checker fetches a submitted publication URL under a total deadline. The implementation used Promise.race() to reject when the deadline expired, but rejecting the wrapper promise did not terminate a response that continued streaming data.

This was easy to miss in an ordinary page review because the user-facing operation appeared to time out. At the transport layer, the socket remained active and kept receiving chunks. A controlled reproduction returned the timeout at roughly 102 milliseconds while the connection continued beyond 277 milliseconds.

Why it mattered: repeated slow or hostile responses could keep consuming network and process resources after the application considered the work finished.

Fix and verification: the request now accepts an abort signal, the total deadline triggers an AbortController, and the underlying request is destroyed. Regression coverage includes an ordinary slow response and a continuously streaming response. The MentionProof suite passed 94 of 94 tests.

2. A double slash could create a protocol-relative redirect

The Node routing layer decoded the request path and reused it in a redirect without first normalizing leading slashes. A request for //blog/index.html could return Location: //blog/. Browsers interpret a location beginning with two slashes as protocol-relative, so malformed input could escape the intended path semantics.

Why it mattered: this was a routing correctness and hardening problem at the boundary between untrusted input and the canonical public host.

Fix and verification: the server now normalizes the decoded path to one leading slash. Host and legacy .html canonicalization also sends a cleaner destination while preserving query strings. Seven backend tests passed, and the double-slash path redirected safely to /blog/.

3. The browser and server disagreed about valid form input

The contact form marked its message field as required and capped it at 4,000 characters. The backend separately required at least 10 characters. A visitor could submit a message that the browser considered valid and receive a server-side 400 response.

Why it mattered: the mismatch created avoidable failure at the main contact conversion point.

Fix and verification: the textarea received minLength={10} while the server remained authoritative. Frontend source and backend tests then enforced the same minimum.

4. The image viewer looked like a modal but did not behave like one

The article image viewer declared aria-modal="true", but it did not move focus into the viewer, keep keyboard focus inside it, make the background inert, or restore focus to the image that opened it. It also replaced useful image labels with generic preview text.

Why it mattered: sighted mouse users could operate the overlay, while keyboard and assistive-technology users received a weaker and potentially confusing interaction.

Fix and verification: the viewer now focuses the close control, traps Tab within the simple dialog, marks the background inert, restores trigger focus, exposes open and closed state, and preserves a descriptive image name. Local browser checks covered open, keyboard, close, and focus return before the asset was checked in production.

5. Eleven BlogPosting schemas referenced a publisher logo that did not exist

Eleven guides declared /favicon-512.png as the publisher logo in BlogPosting structured data. The file was absent and the public URL returned 404. An existing /favicon-192.png asset was already suitable.

Why it mattered: the schema was syntactically valid, so a JSON parser alone would not find the defect. The error appeared only when the referenced asset was resolved.

Fix and verification: the 11 references were replaced with the existing image URL. Content checks found no remaining bad logo reference, and the production asset returned HTTP 200.

The other five priorities

• Stale seven-day asset cache keys.
• Missing expanded and hidden accessibility states in the homepage FAQ.
• A static #contact link whose target appeared only after JavaScript mounted.
• Canonical and internal-URL normalization, including a two-stage redirect pattern and incorrect /seo#faq links.
• External homepage badges that loaded eagerly near the bottom of the page.

These issues crossed several ownership boundaries. Some fixes belonged in React components. Others belonged in the Express server, a shared JavaScript asset, static HTML, or the content manifest that regenerates managed article markup. Astra's value was partly its ability to trace the correct edit location instead of patching whichever generated file contained the symptom.

What Astra did not turn into a crisis

The audit found no Critical issue. The sitemap and manifest were consistent, all 106 sitemap URLs tested locally returned 200, canonical checks passed, the inspected JSON-LD blocks parsed correctly, Brotli responses worked, and npm audit reported zero known dependency vulnerabilities.

That restraint matters. A missing schema image is a real broken reference; it is not evidence that rankings were lost. Browser automation can report a missing element because its selector is stale; that is not proof production is noindexed. Astra's findings still required a reviewer to preserve those distinctions.

One infrastructure nuance remained after the code fixes. The application could canonicalize an apex .html URL in one hop, but a comparable www request still passed through a Hostinger CDN redirect before reaching Node. Removing that extra hop would require a separately authorized hosting change. Repository code alone could not prove or safely change the CDN configuration.

Where Astra fits beside a crawler and human review

The useful workflow combines them. Let the crawler enumerate. Let Search Console show Google's evidence. Let tests reproduce contracts. Use Astra to follow failures across systems and help turn them into reviewable fixes. Keep a human responsible for scope, evidence, priority, and production authority.

In our setup, a read-only Google Search Console connection over MCP can bring URL Inspection and Performance evidence into the same Codex chat as repository and crawl findings. That shortens the evidence handoff; it does not make Search Console a complete crawl or give the model write or deployment authority. The Search Console self-check explains what those signals can and cannot prove.

For the crawler-and-Search-Console side, use the technical SEO audit workflow. If an outside reviewer needs access, define the minimum safe role with what access an SEO audit actually needs.

A practical brief for an Astra website audit

This reusable brief captures the constraints that made the test useful. It is not the verbatim transcript from our audit.

Audit this website and its current source without making changes.

Goal:
Find reproducible technical defects that can affect users, crawling,
indexing, accessibility, security, performance, or conversion.

Evidence rules:
- Inspect the current source of truth before generated output.
- Confirm each finding in code, a local reproduction, or a read-only
  production check.
- Do not list generic best practices.
- Do not infer ranking loss, security impact, or production behavior
  without evidence.
- Separate application behavior from CDN, hosting, and browser behavior.

For every finding, report:
1. Exact file or URL
2. Defect and reproduction
3. Evidence
4. User or business impact
5. Critical, High, Medium, or Low priority
6. Smallest appropriate fix
7. Validation needed after the fix

Finish with the 10 changes that offer the highest real value.
Do not edit, commit, deploy, submit forms, or change external systems.

The permissions in the final line should change only when the owner explicitly wants implementation. Audit access is not deployment authority.

Is Astra worth using for a website audit?

Use Astra when the hard part is following a defect across a large or unfamiliar system: source files, generated pages, routing, APIs, tests, browser state, and production behavior. The FloxoLab exercise found issues that a page-level content review would probably miss, and it helped convert them into a bounded remediation pass.

Use a cheaper model or ordinary automation for narrow, repeatable checks such as validating title lengths, parsing a known JSON format, or applying a mechanical edit. Use established crawlers for exhaustive URL collection. Keep human review for permissions, business impact, contradictory evidence, and the decision to touch production.

Our conclusion is narrower than “Astra can audit a website.” With the repository, the right tools, explicit boundaries, and a requirement to prove every claim, Astra became a strong technical audit collaborator. Without those conditions, the same model could still produce a confident list that nobody should ship.

Evidence basis

• OpenAI model specifications and guidance were checked on September 7, 2026 against the official pages linked above.
• The FloxoLab audit was completed read-only on September 4, 2026.
• The 10 confirmed fixes were implemented in commit dcc98b9 and validated locally on September 5, 2026.
• Validation included 94 MentionProof tests, seven contact-backend tests, content checks for 84 articles and 106 sitemap URLs, repository checks, a Hostinger artifact build, and 46 artifact route checks.
• The updated homepage behavior, cache keys, schema image, assets, and selected routes were checked separately after deployment.
• No controlled comparison with another model was run, and no per-task token-cost record was preserved.