Technical SEO audit order: crawling, indexing, rendering, and site structure

When an SEO report contains hundreds of red warnings, the hardest part is often deciding what to fix first, not learning the terminology. An unavailable home page, one image without a description, and a few missing speed-test points have very different effects on readers and the site.

Think of technical SEO as a basic check before content enters the search process: can a URL be found, does it return the right response, is its main content readable, and do different versions point to sensible destinations? This guide turns those checks into an audit a maintainer can act on, with a scope, evidence, and acceptance criteria for each issue.

Define the site scope and representative pages first

After a bakery studio redesign, the site may have a home page, a course list, individual courses, articles, a contact page, and a member area. Mark which pages should be publicly searchable and which are only for signed-in students. An unindexed member area may be working as designed; not every unindexed URL is an error.

Choose representative URLs for each page template, then add recently created, moved, and previously broken pages. For the course template, include one open for enrollment and one completed course; for articles, include one with charts or diagrams and one with text only. Sampling should reveal shared-template problems, not justify assuming the whole site works because one page does.

Create a worksheet with at least the URL, page type, intended public access, check time, observed problem, and affected scope. Also note which themes, plugins, domains, or paths changed during the redesign. That lets you compare later failures with actual changes instead of guessing across every possible cause.

Layer one: verify that the right content can be fetched

Google's basic technical requirements include not blocking its crawler, returning a successful response, and providing indexable content. Meeting them still does not guarantee indexing. But if a course page intended to be public returns an error or demands a login, remove that entry barrier first. Restore usable content before polishing search appearance.

Open representative URLs in a signed-out window and confirm the correct page appears. Ask the maintainer to check the HTTP status, redirects, and firewall response as well. Seeing a course title on screen does not prove that the server response is correct. Conversely, a successful response that only displays a blank page or verification screen does not meet real reading needs.

Separate site-wide, template-wide, and single-page failures. If every course page sends visitors to a login screen, inspect shared access settings; if only an old course fails, inspect its path mapping. Save both the starting URL and final destination so a redirect fix does not send visitors into another loop.

Layer two: check indexing directives and version selection

Inspect the page's robots meta tag, related response headers, and robots.txt to ensure they match the intended public access. Staging sites often block indexing; if that setting is not checked before launch, production articles may be excluded too. Inspect the actual output rather than trusting that an admin toggle was turned off.

For multiple URLs serving the same content, compare the canonical declaration, Sitemap, internal links, and redirects. Google treats these as canonicalization signals of different strengths, not as absolute commands from the site. Avoid listing one version in the Sitemap while the page declares another, or pointing different courses all at the home page.

In Search Console, inspect the canonical information for the indexed version, then use the live test to check the current page. They answer questions about different points in time; Google's documentation says the live test cannot predict which canonical version Google will ultimately select. For acceptance, record separately whether current output is fixed and whether indexed data has updated.

Layer three: inspect actual rendering and internal paths

If JavaScript loads the main content, inspect rendered HTML, the visible page, and failed resources. Google can run JavaScript, but blocked resources or code errors can still interfere; other tools may not have the same capabilities. A page loading on your own previously used computer does not prove that every first-time visitor sees the same content.

For a bakery course page, check the name, schedule, location, materials, and enrollment entry point one by one. Before putting all course information behind an interface that appears only after interaction, confirm what the checking tool can retrieve. If the source response contains only a shell, ask a developer to review rendering and assess whether server-side or pre-generated content fits the page.

Follow the path from home page to course category, individual course, and related articles. Confirm important pages have crawlable link entry points. Record orphan pages, wrong destinations, and excessive redirects instead of merely counting menu levels. Acceptance should consider whether readers understand where to go next as well as whether crawlers can find the URL.

Layer four: schedule experience and search-appearance improvements

Once the basics work, check mobile loading, responsiveness, and layout stability. Core Web Vitals currently cover LCP, INP, and CLS for those aspects. First find real problems such as a course image shifting an enrollment button or a click doing nothing, then use tool data to locate the cause. A single speed-test score is not a substitute for user experience.

If the site uses structured data, check that its markup matches visible page content and the official rules for that type. Do not invent ratings or add information the page does not show just to obtain a search feature. The Rich Results Test can reveal technical issues, but passing it does not guarantee that the corresponding appearance will be shown in search.

Break improvements into small tasks, such as reserving space for course images, fixing one shared data field, or reducing an oversized resource. Keep before-and-after examples for each task and make sure enrollment and reading still work. This makes costs easier to plan and helps trace which change caused an unexpected result.

Write an audit report that can become finished work

Prioritize issues by whether they block important content from being read, affect some entrances or information, or concern quality and maintenance. Mark the number of affected pages and repair risk separately. This is a management classification, not a score published by Google. If two issues are equally serious, handle the one affecting a core service with a clear cause first.

Each work item needs reproduction steps, the expected result, current result, affected URLs, and acceptance criteria. For example, 'A signed-out visitor sees the correct schedule on the course page, receives a successful response, and finds no unintended noindex' is easier to verify than 'improve SEO.' After fixing a shared template, sample other pages that previously worked too.

At the end of the report, list completed fixes, pending index updates, and outcomes still under observation separately. A technical task can be complete once site settings pass their checks; if search data has not updated, keep a follow-up date rather than claiming a ranking gain during the wait. The same representative pages can serve as an acceptance baseline for the next redesign.

1. Define the public scope and representative URLs for each page type; record what changed in the redesign.
2. Gather evidence in order: access, indexing, rendering, links, and experience.
3. Record the impact, owner, and reproducible acceptance criteria for each issue.
4. Retest affected templates after repair; track index and search data separately.

Examine crawl efficiency and site logs in depth

Back up the site before a redesign

• Tutorials
• Apps & software
• Marketing & SEO
• SEO