Technical baseline audit of an institutional website

Anyone about to commission a new institutional website tends to describe what they want without a technical picture of what already exists. Without that picture, vendors quote without knowing what will be migrated, and the gap shows up later as change requests, delays and tense negotiation.

The baseline audit changes this dynamic before the selection document goes out: the vendor quotes against a defined scope, and the contract starts with measurable acceptance criteria.

The audit is a single, fixed-scope engagement on a site that is already live. It covers six dimensions:

• Security: non-invasive gathering of public information (DNS, TLS configuration, HTTP security headers), a version inventory taken from the administration panel, a passive lookup against a public database of known vulnerabilities, and a static review of the site’s own custom code.
• Information architecture and structure: a URL inventory, duplicated content, forgotten installations on the server, external integrations and an architecture diagram.
• Performance: mobile Lighthouse runs on five to seven key pages, and collection of the Core Web Vitals.
• Accessibility: an assessment against WCAG 2.2 AA, using Lighthouse and axe-core.
• SEO: on-page analysis of a sample of 20 URLs, plus validation of the sitemap and the technical configuration.
• Editorial and data flows: the administrative paths for editing each type of content, duplicated data sources for the same field, and where form submissions end up.

The final delivery brings together three consolidated documents, ten detailed technical reports and the raw data gathered during the audit: screenshots of each finding, sitemaps, structured results of the vulnerability lookups and Lighthouse reports.

The three consolidated documents contain the following:

• Executive Summary: the critical findings with quantified severity, a conclusion for each dimension and an estimate of the risk of inaction, written for executive leadership.
• Technical Requirements for Selection: non-functional requirements with quantitative thresholds for performance, accessibility and security. It includes the quantified migration scope and the decommissioning list for the current server.
• Consolidated Report: findings grouped by severity (critical, high, medium, low), recommendations on three horizons (P0 this week, P1 this month, P2 in the new site’s roadmap) and an estimate of the effort the vendor will face.

Sigil Labs works as agentic consulting: a senior consultant directs AI agents that run the mechanical tasks in parallel. DNS checks, Lighthouse, SEO crawling and static code review run at the same time. The agents capture screenshots and logs of every operation, and the reports follow a uniform template. The consultant spends their time interpreting findings, making recommendations and judging severity.

Sigil Labs’ commercial proposal compares this with the traditional format, in which one senior consultant works for three to four weeks part-time. The proposal sets the same scope at 5 to 7 business days.

The audit runs in read-only mode. The client needs to provide:

• credentials for the hosting control panel;
• one hour for the kick-off meeting and one hour to present the findings;
• occasional availability to confirm context, for example whether a directory is still in use.

Once the work is done, the client is advised to rotate the credentials it supplied, and Sigil Labs discards the credentials it received. The client has unlimited internal use of the deliverables, including attaching them to the selection document and sharing them with the chosen vendor, and Sigil Labs does not reuse client-specific data in other engagements. There are 14 days of support for questions about the deliverables.

The service suits anyone about to choose the vendor for a new institutional website who wants to decide on verifiable requirements. The audit was carried out in full and produced the three consolidated documents and ten technical reports described above. This page describes the method and the deliverables and publishes no findings.

Fixing the problems is out of scope and falls to the operations team or the vendor of the new site. Where two-factor authentication blocks automation, the client conducts the session in a visible browser.

The audit is an example of how Sigil Labs delivers security and technical diagnostic services with AI agents and senior human review. There are three optional steps. The first two can be bought independently of each other and of the audit; the third is a possible offer for later:

• Technical evaluation of the proposals: a scoring table that checks the requirements against each proposal received. Estimated at 8 to 12 hours.
• In-depth code review: an analysis of the current code before the vendor starts building, showing what to migrate, discard or replace. Estimated at 8 to 12 hours.
• Re-audit after the fixes: Sigil Labs may offer it once the new site is live, to check whether the contractual acceptance criteria were met.