An SEO audit is useful when it produces a list of observable problems, owners and ways to verify the fixes. A score from one tool is not the outcome. Start with important pages: can people open them, navigate to them and complete their task? Then investigate crawl and indexing signals, content, internal links and mobile usability.
This walkthrough is designed for an initial audit of a small site. A large migration, complex catalogue or major traffic loss may require deeper investigation with developers and search specialists. An audit creates testable hypotheses; it does not guarantee higher rankings.
1. Define the scope and baseline
Write down the goal, domain, target audience, region and observation period. For example, you may want to verify important service pages after a redesign. Compare equivalent periods where possible and note seasonality, advertising and changes to the site.
Select the home page, priority services or categories, a few product pages, articles and known problem URLs. On a large site include examples of different templates, filters and pagination. A sample can reveal recurring patterns but is not a complete URL inventory.
If available, use your search-engine webmaster accounts, site analytics and a crawler. Without account access, begin with manual browser checks and clearly record what you cannot establish. A search operator or an external test is not a complete list of indexed URLs.
Create a working table with the URL or template, observation, evidence, date, likely impact, owner, task and retest status. Do not put passwords or visitors' personal information into it.
2. Check access and responses
Open selected URLs in ordinary and private browser windows, on desktop and mobile. Is the main content visible without an unexpected login? Do important links reach their stated destination? Test forms in an appropriate safe way and compare the address before and after navigation.
Use a diagnostic tool or ask a developer to inspect HTTP responses. A page that exists should normally return a successful response; a redirect should lead to an appropriate final URL. Investigate server errors and long redirect chains. Do not redirect every missing URL to the home page merely to make a report look cleaner.
Agree on the preferred host and protocol with the team. Check whether internal links and redirects consistently lead there. Before changing server rules, map affected addresses, test the change and prepare a rollback.
3. Investigate crawling and indexing
In the relevant webmaster tools, inspect several priority URLs. Look at whether the system knows the page, the reason given for any exclusion and the date of the available information. Reports may update at different times, so compare them with the current page and recent changes.
Check for login requirements, network restrictions or robot rules that might block important public content. A robots.txt restriction controls crawling; blocking a URL from crawling is not the same as reliably removing it from an index. Consider a noindex directive in the context of whether a crawler can access the page to see it. Consult the current documentation for the relevant search engine before making changes.
Do not open private or administrative areas just to reduce the number of warnings. Determine why a restriction exists and involve the responsible developer.
If an important URL is absent from search, test more than one possible explanation: accessibility, crawl permissions, content, links and canonical signals. Record what each test establishes and what remains uncertain.
4. Compare sitemaps and preferred URLs
Find the XML sitemap actually used by the site and open it. Sample addresses from multiple sections. Compare sitemap URLs with their final destinations after redirects and with internal links. Do not indiscriminately include every filter or administrative URL without deciding whether it belongs there.
Where a canonical link is present, check that its target exists and corresponds to the content. A canonical is a signal of a preferred version, not a guarantee that a search engine will select it. Similar templates do not automatically make distinct products or articles duplicates.
Look for conflicting signals among navigation, sitemaps, redirects and canonical links. After a template fix, verify representative real URLs rather than assuming the setting resolved every case.
5. Follow the user's path
Choose an important service or article and try to reach it through the menu, its section and related pages. Is the path understandable without searching the site? Record broken links, pages without meaningful internal links and anchor text that does not describe its destination.
Do not link every page to every other page. A relevant link is one that helps a reader move from a question to the next useful answer. Update links when their destination changes or no longer delivers what the text promises.
For each priority page, write down the reader's question and expected action. A service page needs useful conditions and a next step; a tutorial needs prerequisites, steps and limits. Check whether the title promises a comparison or checklist that the content fails to provide.
Review facts, contact details and images for accuracy. Similar queries or headings are a reason to compare page purposes, not automatic proof that one URL should be deleted. Before consolidation, consider inbound links, analytics and a redirect plan.
6. Check mobile usability and performance
Use a real phone where possible. Check readable text, navigation, forms, tap targets and tables. Pop-ups should not prevent access to the main content. Review several templates, not just the home page.
Combine available real-user data with a lab performance test. Record the URL, device, conditions and date: a single run depends on the network and environment. Investigate large images, third-party scripts, delays and unexpected layout movement, and give developers reproducible examples.
A high score from one test does not prove that the whole site is easy to use or promise improved rankings. Prioritise issues that prevent a page from loading or a visitor from completing an important action, then repeat the same scenario after a fix.
7. Compare search and analytics data carefully
When access is available, compare impressions, clicks and landing pages across comparable periods. Segment by device or region when it matters. Reports can use different definitions and update schedules, so avoid combining metrics without understanding them.
For example, fewer visits to a service page should trigger checks of page availability, demand, URL changes and other changes. It does not prove a single cause. Preserve baseline values and formulate testable hypotheses.
New articles, seasonal categories and the home page have different roles. Interpret a metric alongside the task the page is meant to support instead of applying one universal threshold.
Turn findings into a plan
The following is a hypothetical prioritisation example, not an audit of a real site:
| Observation | Next check | Initial priority |
|---|---|---|
| A key service page intermittently returns a server error | Record URL and time, inspect logs and repeat the request | High: customers may be unable to open it |
| Navigation reaches the service through several redirects | Verify the final URL before changing the internal link | Medium: affects navigation and maintenance |
| An old article has an unclear search description | Compare its content and metadata; evaluate whether an update matters now | Lower if it is not a current priority |
Assign each issue an owner, evidence, impact, proposed action and retest. Address confirmed problems on critical pages first, then repeated template issues. Changes to addresses or access rules warrant developer review, a backup and a rollback plan.
Final checklist
- Scope, sample URLs and the observation period are documented.
- Key pages open and server responses and redirects are understood.
- Indexing reports and crawl restrictions are checked in context.
- Sitemaps, internal links and preferred URL signals are compared.
- Navigation and broken links are checked on representative templates.
- Content answers the intended task and important information is current.
- Mobile flows and performance are tested under recorded conditions.
- Search and analytics trends are interpreted with their limits.
- Every fix has an owner and a defined way to verify it.
After changes, repeat the same tests on the same examples and record the result. A change log helps the team understand what was fixed and avoid attributing every later fluctuation to a single edit.
Russian original: https://morlix.ru/blog/seo-audit-sayta-svoimi-rukami-prakticheskiy-chek-list
Top comments (0)