A firm publishes a strong practice-area page, but Google still shows an older URL. A redesigned location page returns an error. A browser displays the attorney biography, yet its main content isn't present in the version a crawler receives.

Technical search engine optimization, or SEO, helps search engines access and interpret your pages. An audit should show you what the site actually delivers to search engines, which important pages they can discover, and what needs fixing. You shouldn't have to guess how a warning in the report relates to the firm's website.

This guide focuses on those checks. A broader website review also needs to examine the quality of the copy and intake experience; technical eligibility alone doesn't make a page useful or guarantee its ranking.

Key takeaways

  • Check important pages’ actual responses, crawl/indexing directives, rendered content, and internal links.
  • Distinguish Google’s stored index from a successful live test, and treat canonical signals and performance measures accurately.
  • Turn findings into assigned repairs with expected readbacks, then verify the ordinary public pages.

Begin with the pages the firm needs people to find

Identify important practice, location, and attorney pages. Record their intended URLs and purpose. Include recently changed pages and any that appear to have lost visibility.

A crawler is a tool that follows the site's links and checks its pages. It can help you spot repeated problems, but open examples to confirm what happens. Before putting a warning in the repair plan, find out which important pages it affects and what the failure means for them.

A useful finding might say: “The menu links to the former office page, which returns a 404 page-not-found response. The current office page loads successfully with a 200 response and the correct address.” Now the developer knows which link to change and how to check the repair.

Distinguish crawling from indexing

Robots.txt controls crawler access. It isn't a dependable way to keep a known URL out of search results. A noindex directive needs to be accessible to the crawler so it can be read.

Check the actual response and directives. An accidental noindex on a production service page can exclude it even if the page looks normal in a browser. Conversely, removing a block doesn't guarantee Google will index it immediately.

In URL Inspection, compare the information Google has in its index with a live check of the page. Record when you checked each. The live page may be repaired while Google's stored version is still older; a successful live test doesn't mean the index has caught up.

Review duplicates without inventing a penalty

Similar pages aren't automatically a duplicate-content penalty. Google uses canonicalization to choose representative URLs. Inspect declared canonicals, redirects, internal links, and sitemap entries together.

The canonical guidance treats these as signals, not an instruction Google must always obey. A canonical pointing to another page can also be wrong for the intended content.

For example, a substantive motorcycle-accident page shouldn't automatically canonicalize to a car-accident page merely because both address injury matters. Determine whether each serves a distinct purpose and whether the implementation reflects that decision.

Check what the rendered page contains

Compare the HTML the server sends with the page a visitor sees after its scripts run. Is the important service explanation present? Do links and controls work reliably? Test the actual page, because one JavaScript problem on another site doesn't establish what's happening here.

Check mobile content as well. A design may collapse navigation or tables appropriately, but it shouldn't silently remove the service explanation a reader needs. Test at small, intermediate, and larger widths using realistic headings and content.

Forms and phone links need functional checks. A technical audit can confirm whether the contact route works; it doesn't establish that the copy attracts suitable matters.

Use performance measurements with context

Core Web Vitals describe loading, responsiveness, and visual stability. Field data reflects actual visitor experience when enough data exists; a lab test runs under a chosen environment. State which you're using.

Investigate an observed issue, such as a large image delaying main content or a script making a menu unresponsive. Confirm the cause before prescribing a replacement. A low lab score isn't by itself proof that every visitor has the same experience.

Google's page-experience guidance doesn't promise rankings for passing every metric. Record whether the repair improved the experience measured and what remains unknown about search outcomes.

Check structured data against the visible facts

Markup should describe accurate information visible on the page. Validate syntax and check eligibility for the particular Google feature being considered. The existence of a schema type in Schema.org doesn't mean Google offers a rich result for it.

Google's structured-data policies also make clear that valid markup doesn't guarantee display. Don't promise review stars or FAQ appearances simply because a plugin can generate the code.

Review names, office information, and article authorship carefully. Correct syntax carrying inaccurate credentials is still inaccurate.

Turn findings into verifiable repairs

Group repeated issues by the component or rule causing them. Repairing a shared navigation link can resolve a problem across many pages; editing every page individually may be unnecessary.

For each repair, identify the affected URLs, the owner, and the expected readback. Preserve existing URLs unless a replacement is deliberately approved. When changing one, have the destination and permanent redirect ready together, then verify a direct 301/308 to a 200 destination, internal links, canonicals, and sitemap references.

After release, try the public page again, because a correct preview on the developer's computer doesn't prove that visitors receive the repair. If a cache is still serving an old page, or Google's index hasn't updated, record that separately so the team doesn't mistake it for a failed fix.

Bring the pages you need people to find and the symptoms you've observed. Morpheus Consulting Inc. can help scope a technical audit around evidence the team can act on.