Website content audit checklist for developers

A website content audit checklist turns “the copy looks finished” into a release decision developers can verify. Before launch, check the deployed page for placeholder text, vague claims, repeated template copy, unclear actions, missing proof, and absent support paths.

This is a page-level content QA pass, not a months-long inventory project. Start with the public routes tied to acquisition, signup, pricing, documentation, and support. Record the exact evidence for each problem so the owner can fix and retest it.

Website content audit checklist

Run this checklist against the production-like page, not only a design file or content document:

1. State what the page offers, who it serves, and what the visitor can do next.
2. Remove placeholders, demo identities, empty statistics, and staging references.
3. Replace vague or absolute claims with specific, reviewable evidence.
4. Find repeated boilerplate that hides the purpose of individual sections.
5. Align the title, H1, headings, and opening copy around one page intent.
6. Give the primary action a specific label and a working destination.
7. Expose a real documentation, contact, support, or ownership path.
8. Review the rendered mobile and desktop page after data and scripts load.
9. Add stable content contracts to CI, then rerun the review after deployment.

Google's people-first content guidance asks whether a page serves an intended audience, provides substantial value, has accurate sourcing, and makes authorship clear. Use those questions as review prompts, not as a formula for rankings.

Define the page job before reviewing sentences

Write a three-line contract for the route before editing details:

Audience: Frontend developers preparing a public release
Outcome: Find launch blockers with evidence
Primary action: Run an audit on a deployed URL

Now compare the contract with the first screen. A new visitor should be able to answer three questions without interpreting brand language:

• What is this page about?
• Is it meant for me?
• What useful action can I take?

If the answers appear only in metadata, a footer, or an animation that may not run, the visible page is not carrying its part of the contract. Rewrite the main heading and opening paragraph first. The HTML heading structure guide shows how to preserve that meaning in the document outline.

The W3C cognitive accessibility pattern for making a page's purpose clear recommends placing a clear purpose in the title, main heading, and other cues people use to orient themselves. A clear page job helps scanning, accessibility, search understanding, and review because every section has something concrete to support.

Remove placeholder and demo content

Search the delivered page for obvious residue such as lorem ipsum, coming soon, your company, example product, unfinished TODO text, fake people, and statistics with no value or source. Also inspect content that appears after hydration, menu expansion, validation, and failed requests.

Do not replace one placeholder with another polished placeholder. A sentence such as “Trusted by innovative teams everywhere” is still incomplete when the page names no team, result, case study, or verification path. Choose one honest alternative:

• Name a real customer or example with permission.
• Link to a reproducible demo or public report.
• State a measured result with its scope and source.
• Describe the mechanism without making a performance claim.
• Remove the claim until evidence exists.

For a small site, browser find and a careful read may be enough. For a component library or content system, keep a short denylist of project-specific fixtures and staging phrases. Review matches manually because words such as “example” can be legitimate in documentation.

Replace generic claims with useful proof

A website copy audit should connect important claims to evidence a visitor can inspect. Review superlatives, guarantees, broad trust language, and claims that hide the mechanism.

Vague: The smartest platform for effortless website quality.
Specific: Scan one public page for crawl, browser, accessibility, and content evidence.

Vague: Used by leading developers.
Specific: View a public sample report with the checks and evidence fields.

Specific copy does not need a number in every sentence. It needs enough detail to explain what happens, where the boundary sits, or how someone can verify the statement. Link to documentation, methodology, a sample, a changelog, or a named source when the claim depends on outside evidence.

Google's guidance also recommends clear sourcing and accurate authorship information. Add the appropriate owner, byline, company identity, or support route for the page rather than relying on a logo as the only trust signal. The website audit report example demonstrates how evidence, impact, and a fix can travel together.

Find repeated and mismatched copy

Templates make publishing consistent, but they also spread copy that belongs to another route. Compare normalized sentences across the page and its neighboring pages. Watch for:

• The same hero paragraph under different H1s.
• Feature cards that repeat one claim with different nouns.
• A pricing CTA copied onto a documentation route with the wrong destination.
• An old product name in legal text, metadata, alt text, or a dialog.
• A title and H1 that target different tasks.
• Testimonials or statistics copied from a starter template.

Treat repetition as a review signal, not an automatic failure. Navigation labels, legal disclosures, and shared instructions can repeat for good reasons. The issue is repeated promotional or explanatory copy that prevents a route from answering its own intent.

Check the document title and meta description during the same pass. The title tag and meta description checklist covers source HTML, rendered metadata, practical review ranges, and route-level uniqueness.

Make the primary action specific and reachable

The main action should name the next step without depending on surrounding marketing copy. “Run a website audit” is clearer than “Get started.” “Read the API authentication guide” is clearer than “Learn more.”

Then verify the destination. A good label still fails when it points to #, a missing fragment, a stale route, or a button whose state change is not available to keyboard and assistive technology users. The W3C explanation of link purpose says users should be able to determine what a link does from its text or programmatic context.

For release QA:

1. Identify the one action that represents the page's main task.
2. Read its accessible name, not only the visible icon.
3. Resolve its final route or in-page target.
4. Confirm the target works without an unexpected login, error, or redirect loop.
5. Repeat the task at the narrowest supported viewport.

Use the broken link check for route and fragment coverage. Use the keyboard accessibility checklist when the action opens a menu, dialog, or other interactive state.

Keep the content QA checklist in CI

Automate contracts that are stable and objective. Avoid encoding subjective prose rules that produce noise on every edit. This Playwright test checks a route's page identity, primary action, support path, and known placeholder fixtures:

import { expect, test } from "@playwright/test";

test("homepage keeps its content contract", async ({ page }) => {
  await page.goto("https://example.com");

  await expect(
    page.getByRole("heading", { level: 1, name: /website audit/i }),
  ).toBeVisible();

  const primaryAction = page.getByRole("link", { name: "Run a website audit" });
  await expect(primaryAction).toHaveAttribute("href", "/audit");
  await expect(page.getByRole("link", { name: /contact|support/i })).toBeVisible();

  const visibleText = (await page.locator("body").innerText()).toLowerCase();
  for (const placeholder of ["lorem ipsum", "your company", "coming soon"]) {
    expect(visibleText, `remove placeholder: ${placeholder}`).not.toContain(placeholder);
  }
});

Keep the denylist short and owned by the project. Add assertions for approved names, plan facts, legal links, or release-specific statements only when the team can maintain them. Put the stable checks beside the website regression testing suite and keep editorial judgment in review.

The W3C's writing for web accessibility guidance recommends informative titles, meaningful headings, clear instructions, concise language, and descriptive link text. Automated assertions can confirm that required elements exist, but a person still needs to judge whether the wording is accurate and understandable.

Run a website content audit with Slop Audit

Run a Slop Audit on the deployed page to collect content evidence alongside crawl and browser findings. The bounded audit checks for common placeholder phrases, possible demo residue, repeated normalized phrases, clusters of generic promotional language, a proof or documentation path, a support or ownership path, and a specific primary action with a resolvable destination. When the language stage is available, it also reviews whether the visible evidence identifies the product, audience, and concrete outcome.

Slop Audit does not fact-check every claim, proofread an entire site, enter credentials, invoke unsafe or side-effecting actions, or certify that copy is accessible, original, or likely to rank. Heuristic and language-assisted findings need review. Use the quoted evidence to locate the problem, fix the source component or content record, deploy it, and rerun the same URL.

Website content audit sign-off

Before release, confirm that:

• The page identifies its offer, intended audience, and main outcome.
• The title, H1, opening copy, and primary action support one intent.
• No placeholder, fixture, demo identity, empty statistic, or staging reference remains.
• Important claims have a named example, source, methodology, or documentation path.
• Repeated template copy is intentional and does not hide route-specific meaning.
• Links and controls have descriptive names and working destinations.
• Visitors can find support, contact, documentation, or ownership information.
• The rendered mobile and desktop states match the approved content.
• CI protects stable facts while human review covers meaning and truth.

Save the route, evidence, owner, and expected correction with each finding. “Replace your company in the pricing footer and verify /contact” is a release task. “Improve the content” is not.