Audits & strategy
SEO implementation plan
I run a kick-off workshop at which we agree the scope of the SEO implementations: technical work, content, site architecture and linking. We clarify the organisational constraints, communication, and the rules for approving and signing off tasks. I collect access and materials, crawl the site and compile the data for the diagnosis and the backlog.
About the service
SEO kick-off and setting the implementation framework: scope, process and required access
About the SEO implementation plan service
A few service details- Kick-off and collaboration framework
- Confirming the implementation scope
- Agreeing communication and approvals
- Collecting access and materials
- Site crawl and URL status analysis
- Preparing data for the diagnosis and backlog
Work process
How we work together on SEO implementations: from kick-off to backlog
I start with a kick-off, where we clarify the scope of the SEO implementations, the organisational constraints, and the rules for communication and approval. I then collect access and materials, crawl the site and, based on the data, prepare a prioritised backlog.
- 01/ 03
Kick-off
I agree with you the areas of work (technical, content, architecture, linking), the constraints and how decisions about priorities will be made.
- 02/ 03
Access and inputs
I obtain access to traffic and indexing data, information about the URLs, the CMS and the implementation process, and a list of key pages or products.
- 03/ 03
Crawl and backlog
I crawl the site, analyse URL statuses, linking and metadata, and turn the observations into implementation tasks with acceptance criteria, to be carried out in the agreed order.
Kick-off and agreeing the scope of SEO implementations
The kick-off and agreeing the scope of SEO implementations is a start-up workshop in which we specify which areas the work will cover and what the collaboration will look like. At this stage we confirm whether the plan covers technical implementations, content, and site architecture and linking. We also establish the organisational constraints that may affect the order and manner in which changes are carried out. In parallel, we clarify how we will communicate and the rules for approving and signing off tasks.
The outcome of the kick-off is a shared understanding of what will be diagnosed and how the implementation tasks will be prepared. The arrangements made at this stage help avoid a situation in which recommendations are prepared without taking the real implementation process into account. As a result, the next steps — collecting data, diagnosing problems and preparing the backlog — rest on a previously agreed framework. This is also the moment to define how decisions about priorities will be made depending on risk and available resources.
Access and input materials: the key to success
Access and input materials are key, because they make it possible to collect data and analyse the site for the SEO implementation plan. On the client’s side, access to traffic and indexing data is needed, along with information that makes it possible to assess the state of the URLs, errors and redirects. A list of key pages or products is also important, so that the diagnosis and backlog relate to real business priorities. In addition, information is collected about the CMS and about what the implementation and approval process looks like.
Based on these inputs, the site is crawled and data is obtained on URL statuses, link structure and basic metadata.
The information provided about the CMS and the implementation process is needed so that the later specifications can actually be implemented in practice. These materials are the foundation for turning observations into specific tasks with acceptance criteria.
Data collection and site analysis
Data collection and site analysis means obtaining information about how the site is indexed and how its URLs behave in practice. I analyse the site to collect data on URL statuses, redirects and errors that may hinder crawling or lead to unwanted versions of pages. In parallel, I check the internal link structure to understand how crawlers and users move around the site. This is supplemented by basic metadata, which can later be related to problems with duplication or with matching content to queries.
The result is a set of input data on which further diagnosis can be based and observations turned into implementation tasks. The analysis includes, among other things, detecting ambiguous HTTP statuses, incorrect redirects and signals that lead to faulty indexability. I also check the elements that affect the consistency of URLs and their versions, including canonicals, as well as the basic relationships between page types and their metadata. This information is then used to identify areas that can realistically be turned into work on the CMS, the templates or the content.
Diagnosis: identifying problems and opportunities
Diagnosis: identifying problems and opportunities is the stage at which I point out the elements blocking visibility and the areas for improvement that can be turned into specific implementation tasks. I work with the data from the site analysis and organise it into observations concerning technical matters, architecture and content. The aim is to catch both critical problems and improvements that are justified in the context of indexing and URL behaviour. This stage creates the basis for building the implementation backlog.
The diagnosis covers several parallel analyses that make it possible to describe unambiguously what needs to change and why. In the technical analysis I assess, among other things, indexing and crawling, HTTP statuses, canonicalisation, sitemaps, robots, pagination, duplication, URL parameters, language versions, and performance and rendering. In the architecture and linking analysis I check the structure of categories and pages, click depth, internal linking, breadcrumbs, navigation and orphan pages. This is supplemented by content analysis and intent analysis (topic coverage, keyword cannibalisation, quality, titles and descriptions, headings, schema where justified), as well as SERP analysis and market comparison, i.e. verifying the result types and user expectations for key topics and identifying gaps in content or structure relative to the search results.
Creating the implementation backlog
Creating the implementation backlog means turning the conclusions of the diagnosis into a list of specific tasks to implement, together with the sign-off rules. I describe each task so that it is clear what exactly needs to be changed, where (on which page types or URLs) and how to check that the implementation works correctly. In the backlog I also take into account the dependencies between tasks, and the risks and possible side effects, including the impact on traffic and indexing. In parallel, I estimate the potential SEO impact and the difficulty of implementation, taking into account the complexity of the CMS, system dependencies and the development or content work required.
The outcome of this stage is material that can be handed directly to the implementation team for delivery. We set the implementation priorities based on impact, risk and resources, and the order may follow, for example, this approach: indexing blockers → critical errors → architecture → content. At this stage we also clarify who implements and in what mode — whether the implementation is on the client’s team or expert support is needed — and how responsibility for making the changes is handed over.
- SEO task backlog: description, priority, dependencies, risk, owner, status, acceptance criteria and method of validation.
- Implementation guidelines: specifications for developers and editors (including URL rules, redirects, canonicals, meta, headings, content templates, internal linking, schema — where justified).
Implementation roadmap: planning and schedule
Implementation roadmap: planning and schedule means arranging the backlog into implementation waves, taking into account dependencies, deployment windows, testing and sign-offs. At this stage I plan the phasing of the work so that tasks can be carried out in a coherent order, without later changes being blocked by unresolved dependencies. The roadmap shows what we implement first, when QA is scheduled and what the conditions are for moving on to the next wave. This arrangement makes it easier to coordinate work across the technical areas, site architecture and content, without blurring responsibilities.
The pace and actual order of the work depend on the availability of implementation resources and on the process for approving and publishing changes. If the recommendations require changes to templates, integrations or systems, this affects the cost, risk and priority, which must also be reflected in the roadmap. Safe testing and SEO sign-off depend on being able to verify changes before publication and on control over the release process. The roadmap is also the basis for planning the points at which clarifications and consultations are needed for the dev and content teams.
- Implementation roadmap: the phasing plan, dependencies between waves, QA dates and the conditions for moving on to the next stages.
- Taking resources and deployment windows into account: order and pace matched to the availability of the development/editorial team and the approval process.
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.