Audits & strategy
Technical SEO audit
I carry out a technical audit in which I match the level of detail of the analysis to the number of URLs, the page types and how often things change (including dynamic URLs). I collect the list of URLs, crawl the site and verify, among other things, linking, metadata, canonicalisation and HTTP statuses. I report the findings so that they can be turned into tasks.
About the service
Technical SEO audit with a URL inventory and a crawl matched to the size of the site
About the technical SEO audit service
A few service details- Scope matched to the size of the site
- URL inventory and sampling
- Crawling with indexing in mind
- Internal link verification
- Metadata and canonicalisation checks
- Attachments: URLs, errors, screenshots
Work process
The technical SEO audit process: from kick-off to report
I start with a kick-off to specify the goal and scope of the analysis and to agree on the form of the results. I then collect the necessary access and input data, so that the audit does not rely solely on external observation. Next, I carry out the inventory and verification of the site, and organise the findings in a report and a task list.
- 01/ 03
Kick-off and scope
I establish the page types and site versions to be audited, and the priorities — such as indexing, a migration or drops in visibility.
- 02/ 03
Access and data
I collect indexing and diagnostic data, information about the CMS and hosting, the URL map and the change history — and, optionally, server logs.
- 03/ 03
Inventory and report
I crawl the site and build a URL inventory, verify response statuses, metadata, canonicalisation and linking, and deliver the result as a report and a prioritised task list.
Kick-off and defining the scope of the technical audit
The kick-off and defining the scope of the technical audit mean specifying exactly what will be analysed and in what form you will receive the results. At this stage I establish the page types on the site and the site versions to be included in the audit (e.g. language versions or subdomains). We also define the priorities — such as indexing, a migration or drops in visibility — so that the analysis is aimed at the real problem. We agree on the form of the results too: a report and a task list.
I match the scope and level of detail of the audit to the size of the site. In practice this depends on the number of URLs, the number of page types, how often things change and whether the site generates URLs dynamically. These decisions determine how broad the URL inventory will be and how deep we go into problem samples. As a result, the reporting is consistent with how your website works and changes.
Access and input data: the key requirements
Access and input data are a key requirement, because without them the audit may be limited to external observation. To start, I need access to the site’s indexing and diagnostic data and information about the CMS and hosting. A URL map (if one exists) is also helpful, as is the change history, which makes it possible to link problems to modifications on the site. Depending on the goal of the audit, server logs may be needed as well.
It makes it easier to crawl the site and collect a reliable list of URLs for verifying response statuses, metadata, canonicalisation and link structure. If logs are available and justified by the goal of the audit, they make it possible to confirm how crawlers really behave (visit frequency, errors and wasted budget). That translates into more accurate prioritisation of fixes in the later stages.
- Access to the site’s indexing/diagnostic data
- URL map (if one exists)
- Information about the CMS/hosting
- History of changes on the site
- Server logs (optional, depending on the goal of the audit)
Audit scope depending on the size of the site
Audit scope depending on the size of the site means that the level of detail of the analysis is matched to how large and complex your website is. The choice is driven above all by the number of URLs and the number of page types that need a separate assessment. How often the site changes matters too, because it affects how stable the structure is and how often new or modified URLs appear. If the site generates URLs dynamically, I take that into account when planning the sample and the way problems are mapped.
In practice, the size of the site determines how broad the inventory will be and how deeply I go into the analysis of individual sections and page types. It also shapes the reporting, so that the conclusions can be implemented given the real number of URLs and URL variants. As a result, the findings are organised in a way that makes it easier to turn problems into tasks later. This model keeps the structure of the site consistent with the way the recommendations are described.
URL inventory and the crawling process
The URL inventory and the crawling process consist of collecting a list of URLs and scanning the site to detect technical problems and elements that affect indexing. At this stage I identify the link structure, metadata, canonicalisation and HTTP response statuses of the scanned pages. The crawl is the basis for further verification, because it shows what the site looks like “from the inside” at the level of URLs and their relationships. The collected data also makes it easier to catch recurring patterns within page types.
The results of the inventory are documented in a way that makes it possible to reproduce the problem on the technical side and turn it into specific actions. As supporting material I prepare evidence and samples, such as example URLs, lists of detected errors and screenshots of selected configuration elements relevant to the diagnosis. Such attachments help a developer or administrator quickly locate the source of the problem on the site or in its settings. The crawl data is then used as the starting point for the next checks in the audit.
- Collecting the list of URLs for analysis
- Scanning the site for technical errors
- Verifying the internal link structure
- Checking metadata and canonicalisation
- Reading and organising HTTP response statuses
Verifying indexing and content coverage
Verifying indexing and content coverage means comparing what actually exists on the site with what is visible in the index. Based on the collected URL map and diagnostic data, I identify pages that are not indexed and pages that are in the index although they should not be. In this part of the audit I also catch problematic pages, including URLs with parameters that can undermine control over what is meant to be indexed. The results of this verification are one of the key inputs for prioritising fixes later.
The outcome is coverage problems organised in a way that can be turned into specific implementation tasks. I describe which URL groups need clearer indexing rules and where the structure of the site and the state of the index diverge. I also point out the areas that should be excluded from the index or brought into line with what the crawler is meant to see and process. This breakdown makes later decisions about the order of fixes easier.
- Comparing the site’s resources with what is indexed
- Identifying pages that are not indexed and pages that should not be in the index
- Detecting problematic URL groups (e.g. URLs with parameters)
- Pointing out areas that need tidying up in terms of coverage
Checking the crawler-control rules
Checking the crawler-control rules includes verifying whether the blocking and signalling mechanisms are consistent with what the site is meant to make available for crawling and indexing. I verify the rules in the files and settings that control crawlers, including robots, meta robots and headers that can affect crawler behaviour. I also check the sitemaps and whether they match the actual URL structure. The aim is to catch inconsistencies that can cause wrong signals, blocks or uncontrolled indexing.
As part of this check I point out where the control rules contradict the observed state of the site and its URLs. I describe which configuration elements need correcting and where the URL structure does not match the sitemaps or the blocking rules.
The conclusions are prepared so that they can be reproduced and implemented in the site’s configuration or templates.
- Checking robots, meta robots and crawler-control headers
- Checking sitemaps and their consistency with the URL structure
- Detecting inconsistencies between the rules and the real URLs on the site
- Pointing out the places where the control configuration needs correcting
Testimonials
What clients and the industry say
Feedback from clients and industry people I have worked with on SEO projects.
I had the chance to work with Kuba at Kulturalnie o SEO, an event I organise. Kuba did a great job as a speaker and received high marks from the audience. He showed professionalism and broad knowledge. In other projects at Vestigio, Kuba shows enormous commitment, a willingness to explore and implement new ideas, and excellent organisation of his work.
01 / 08
You talk to me, not a salesperson
Tell me what you want to achieve. I’ll reply personally
I work as a freelancer: the same person reads your message, prepares the quote and then runs the project. No sales team in between.