Technical SEO
Indexing optimisation
I start by gathering information about the site, obtaining access to indexing and error data, and establishing who implements changes and how (including on a test environment). I then measure the state of indexing and organise the URL types, and check HTTP statuses, redirects, robots.txt, the sitemap, canonicals, duplication, linking and content accessibility; optionally, I analyse the server logs.
About the service
Indexing optimisation: diagnosis, URL inventory and an implementation plan for the changes
About the indexing optimisation service
A few service details- Organising access and data
- Agreeing the implementation and testing process
- Measuring the index vs. the site’s resources
- Inventory of URL types and parameters
- Verifying robots, sitemap and HTTP
- Assessing canonicalisation and linking
Work process
The indexing optimisation process: from diagnosis to implementation and checks
I start the cooperation by gathering information and putting access in order, so that the diagnosis is based on data. I then measure the state of indexing and organise the URL types. On that basis I plan the order of work and move on to implementation, with verification before and after publication.
- 01/ 03
Access and arrangements
I gather information about the site, organise access to the data, and we establish who implements changes and how (testing, approval, publication).
- 02/ 03
Measurement and URL inventory
I collect the baseline, carry out a URL inventory and analyse the errors and problem patterns, including HTTP statuses, redirects, robots, the sitemap, canonicals, duplication and internal linking (optionally logs).
- 03/ 03
Priorities and implementation
I set the priorities depending on the limitations of the CMS and the publication process, and verify the fixes on the test environment and after implementation to confirm that the changes work.
Getting started and access: key steps in indexing optimisation
At the start of indexing optimisation I gather information about the site and organise access to the data needed for a reliable diagnosis. We also agree how changes will be implemented and the environment on which fixes can be verified safely. In practice, this means specifying who implements changes in the code/CMS and how publication proceeds (e.g. testing, approval). This stage makes it possible to plan the work so that the later recommendations can be carried out and checked.
What is required is data and access that show the real state of indexing and errors and allow the key elements to be verified technically. I need access to indexing and error data, a URL map or the site structure, and the ability to check HTTP headers. The scope also includes verification of robots and the sitemap, while server log analysis is optional, if logs are available. Without data and access, the indexing diagnosis is incomplete, which is why this step is treated as a condition for doing the work properly.
The real scope of the results depends on whether the changes can be implemented and on what the publication process looks like. If the site has a test environment and a clear approval path, it is easier to carry out quality control before implementation and after publication. If implementation is limited by the CMS or by the process on the team’s side, the priorities and the order of work must take this into account. These arrangements affect how quickly it is possible to move from diagnosis to corrective action.
Measuring the state of indexing: URL analysis and inventory
Measuring the state of indexing consists of collecting the baseline and organising what actually reaches the index compared with what exists on the site. I analyse the number of pages in the index vs. on the site, the types of error, the trends and the recurring problem patterns in templates and URL parameters. This stage makes it possible to capture which areas of the site generate risk for crawling and indexing. As a result, further decisions and recommendations can be based on data rather than on assumptions.
The URL inventory consists of collecting and organising the key types of address on the site. This includes, among other things, landing pages, categories, products or articles, pagination, filters, parameters and internal search results. Order in the URL types is the basis for assessing where duplicates, errors and unwanted indexing appear. On that basis it is also easier to indicate which templates and sections require separate rules.
As part of the technical analysis I check the server responses and the consistency of redirects and URL versions. The assessment covers 2xx/3xx/4xx/5xx statuses, redirect chains, incorrect redirects and the consistency of URL versions. In parallel, I verify the robots directives and the quality of the sitemap: completeness, freshness, URL response codes and consistency with the canonical addresses. These elements often decide whether bots reach the right pages and whether they are being directed to outdated or incorrect resources.
The next part of the measurement covers the assessment of canonicalisation, duplication, internal linking and the accessibility of content to bots. I check the canonical tags, the sources of duplication (e.g. parameters, sorting, URL versions) and the consistency of internal linking with the canonical addresses. I also analyse whether important pages are reachable via links, whether there are no orphan pages and whether pagination and facets are not generating excessive crawling. In addition, I verify rendering and the accessibility of content and links, in order to rule out technical barriers that may hinder indexing.
If server logs are available, the measurement can be supplemented with an analysis of the bots’ real behaviour. This makes it possible to check which sections are crawled most often, where errors appear and whether the crawl budget is not being wasted on parameters and duplicates. This step is optional and depends on whether the data can be made available. The results from the logs can confirm problems visible in other sources and help to specify the priorities for further work.
Diagnosis and priorities: making the key indexing decisions
Diagnosis and priorities consist of collecting the detected problems into an implementation list and setting the order of work by risk and expected impact on indexing. At this stage I organise the issues by section and template, so that it is clear where specific problems occur and what they concern. In parallel, I define the consequences for crawling and indexing, so that the priorities do not result solely from individual cases but from recurring patterns. The result is an organised action plan that can be transferred into the implementation process on the code/CMS side.
A key part of the diagnosis is deciding what is to be indexed and how to handle parameters, facets and pagination. We establish the target set of pages that are to reach the index and the URL types that should be excluded (e.g. filters, internal search results, duplicates, basket, account). I define the approach to filters and sorting: whether to index selected combinations, or to limit crawling and indexing by means of canonical, noindex, linking and URL rules. In addition, I set the rules for pagination and listing pages, so as to limit duplication and empty pages and maintain consistent linking.
As part of this stage I hand over a complete set of materials for making the changes and for their quality control. This includes a Diagnostic report with the list of problems, their location and the recommended fixes, as well as an Implementation list (backlog) with priorities, acceptance conditions, example URLs and the suggested method of implementation. I also deliver Specifications for dev/CMS, which set out the rules for templates and URL rules (including canonical, noindex, redirects, sitemap generation, linking and pagination). As a result, the changes can be implemented consistently, without guessing the intent for individual URL types.
Implementing the changes: carrying out the technical fixes
Implementing the changes consists of carrying out the agreed fixes on the site and in the configurations that affect crawling and indexing, together with validation after publication. This stage is based on the previously agreed decisions about what is to be indexed and in what form the URL rules are to work. The work is carried out within the scope that can be implemented in the code/CMS and in line with the adopted publication process. In practice, this means turning the backlog and the specifications into specific changes to templates, URL rules and the technical elements of the site.
As part of the technical indexing fixes, actions are implemented that remove barriers on the server side and in the URL structure. This includes fixing 4xx/5xx errors, shortening redirect chains, eliminating incorrect redirects and standardising the URL versions. In addition, changes are made that increase the accessibility of pages to bots, including corrections to headers and to elements that affect the availability of resources. The aim is to arrive at consistent technical signals that do not block crawling and do not introduce URL ambiguity.
In parallel, the exclusion and inclusion rules are implemented and the signals directing bots to the right URLs are put in order. Robots directives are set where limiting crawling is justified, and for pages that are to be accessible but should not reach the index, noindex and/or canonical are applied as agreed. Sitemap optimisation includes preparing sitemaps that contain only canonical, indexable addresses, removing incorrect and outdated URLs, and splitting into sections if needed. In addition, the internal linking is put in order: paths to priority pages are strengthened, links to excluded pages are limited, and the navigation, pagination and links in listings are tidied up.
Validation and checks: post-implementation tests and checklists
Validation and checks consist of verifying after implementation whether the site returns the right responses and whether the indexing signals are set as agreed. I verify whether pages return the correct codes, whether the directives are consistent and whether the sitemap leads to the right addresses. The check also includes verifying whether the indexing problems are decreasing in the indexing and error data. The purpose of this stage is to catch discrepancies between the specification and the actual behaviour of URLs after publication.
I carry out the post-implementation tests on URL samples, so as to confirm that the key rules work correctly across different URL types. Both the technical elements (statuses, redirects) and the signals that steer indexing (canonical, noindex, robots) are checked, as well as the accessibility of content and links. I also check the consistency of internal linking with the canonical addresses and whether the right pages are in the sitemap. The scope of the samples and test areas follows from the changes implemented and from where problem patterns were identified earlier.
- response statuses (2xx/3xx/4xx/5xx) and the correctness of redirects
- canonical and the consistency of URL versions in linking
- noindex and robots rules in the context of the agreed exclusions
- accessibility of the content and links relevant to indexing
- presence of the right URLs in the sitemap and the correctness of their response codes
As part of this stage I hand over a Validation checklist, which makes quality control easier before and after the publication of subsequent changes. It contains the list of tests to perform, the designated test URLs, the expected responses and the conditions for correctness. The checklist is prepared so that it can be used for subsequent implementations concerning URL rules, sitemaps, canonical, noindex, redirects and linking. As a result, verification is not based on individual cases but on a repeatable set of checks.
Monitoring and iterations: regular analysis of indexing trends
Monitoring and iterations consist of regularly analysing indexing and error trends and refining the rules when the site changes or new URL types appear. I observe whether earlier problems persist in the indexing and error data or whether new patterns appear in specific sections and templates. As part of the iterations, the rules for parameters, facets, pagination and exclusions are adjusted if new URL combinations appear on the site. Monitoring also supports a quick response to changes in publications and configurations that affect crawling and indexing.
Iterations mean returning to the diagnosis and the priorities when new data points to different risks or the site’s technical conditions change. On that basis the order of work and the scope of the URL rules are updated, so as to limit duplication and the wasting of crawl on unwanted addresses. There is no guarantee of indexing, because the decision and the pace of change depend on the search engine and on processing time. For this reason, monitoring is part of the work even after the correct technical signals have been implemented.
The scope of monitoring and the number of iterations depend on factors such as the size of the site, the number of templates, the number of language versions and the share of parameters and facets. The frequency of content changes and the complexity of implementation in the code/CMS also matter, because they affect the number of areas that need checking. If access to the server logs is possible, this can support the assessment of the bots’ real behaviour and the detection of places where crawl is being wasted on parameters or duplicates. These conditions are taken into account when planning which areas to analyse regularly and how quickly to refine the rules.
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.