Consulting
SEO for in-house teams
I gather the context of the site and set the framework for in-house SEO cooperation: the SEO, content and dev roles, ownership of areas, meeting rhythm, communication channels, and the rules for prioritising and signing off changes. We agree on the support model and the access needed to analytics, indexing data, the CMS and the environments for auditing and QA.
About the service
In-house SEO onboarding: cooperation model, roles, sign-off process and required access
About the SEO for in-house teams service
A few service details- Establishing roles and ownership
- Meeting rhythm and communication
- Priorities and sign-off of changes
- Choosing the SEO support model
- Scope of changes to the site structure
- Access: CMS, analytics, indexing
Work process
How I work on SEO: onboarding, diagnosis and iterative implementation
I start the cooperation by establishing roles, communication and the rules for signing off changes. I then collect the access and data needed for the audit and diagnosis of the site. From there we work in recommendation–implementation–QA cycles, in line with your release process.
- 01/ 03
Onboarding and model
I establish the SEO/content/dev roles, the meeting rhythm, communication channels and the rules for prioritisation and sign-off, and we choose a support model that fits your team.
- 02/ 03
Access and audit
I ask for access to analytics, indexing data, the CMS and the repository and/or test environments (as well as logs/monitoring, if available) in order to carry out the audit and identify barriers and risks.
- 03/ 03
Implementation and QA
I turn recommendations into requirements for development and content, help resolve blockers, and verify the changes before publication or in production, depending on your release windows.
Onboarding and setting up the cooperation in in-house SEO
Onboarding in in-house SEO means quickly gathering the context of the site and agreeing on a way of working together so that the work can be planned and followed through within the team. At this stage we clarify the roles on the SEO, content and development side, and who owns the individual areas of the site. We also agree on the meeting rhythm, the communication channels and the rules for prioritising and signing off changes. As a result, the next steps (diagnosis, plan and implementation) have a clear operational framework.
As part of onboarding we decide on the “Support model” and match it to the way your in-house team works. Three modes are possible: consulting and oversight (the in-house team implements), co-delivery (joint implementation) and intervention mode (incidents, drops, migrations). Choosing the model defines how we work on recommendations, what ongoing support looks like and how blockers are resolved during implementation. It is also the starting point for the later planning of priorities and responsibilities.
The cooperation also requires agreeing on the sign-off process and ownership, especially when changes to templates, navigation or information architecture are involved. A clear sign-off path and assigned owners of sections and content affect the scope and pace of implementation support. In addition, we discuss whether structural changes are planned (e.g. to URLs, templates and architecture), because they increase cost and risk and raise the need for QA and a redirect plan.
- Establishing roles: SEO, content, dev and the owners of areas of the site
- Meeting rhythm and communication channels
- Rules for prioritising and signing off changes
- Choosing the “Support model”: consulting and oversight / co-delivery / intervention mode
- Decision on the scope of structural changes (architecture, templates, URLs) as input for the later stages
Access and analytics data
Access and analytics data are required to carry out the audit, the diagnosis and the later QA of implementations on the basis of real signals from the site. Providing access covers analytics data and indexing data, as well as the ability to verify the implementation at CMS level. Where possible, we also use logs or monitoring, if they are available in the organisation. We match the scope of access to the needs of the audit and quality control, without requesting anything that is not necessary.
In practice I ask for access to the CMS and to the repository and/or test environments to the extent needed for the audit and QA. This makes it possible to check changes before publication or directly in production, depending on your release process. Indexing and analytics data are the basis for identifying barriers and risks and for verifying the effect of implementations in the indexing data. As a result, recommendations can be turned into specific requirements for dev and content, and then checked in a controlled way.
- Access to analytics data
- Access to indexing data
- Logs/monitoring (if available)
- Access to the CMS
- Access to the repository and/or test environments to the extent needed for the audit and QA
Diagnosing the state of SEO and identifying barriers
Diagnosing the state of SEO means reviewing the data and the site in order to identify technical barriers, indexing risks, and topical potential and landing pages to develop. At this stage I combine observations from different areas of SEO into a coherent picture: what is blocking visibility, what is limiting indexing and where there are untapped opportunities in content and architecture. The result of the diagnosis is a set of problems and opportunities organised in a way that allows the implementation to be planned. In parallel I identify the areas where a lack of implementation may create risks for indexing and for the stability of visibility.
The scope of the diagnosis covers technical and indexing analysis, architecture and internal linking, content and intent, a benchmark of the search results (SERP), and performance and UX elements relevant to SEO. Each of these blocks provides lists of observations and recommendations, which I then combine into a single document for implementation decisions. The final result is the “Diagnosis report + list of problems”, with an assessment of the impact on visibility, a description of the recommended fixes and the risks if they are not implemented. This report is the input for the next stage: the action plan and priorities.
- Identifying technical barriers and indexing-related risks
- Identifying topical potential and landing pages
- Combining conclusions from the areas: technical, architecture, content, SERP, performance/UX
- The “Diagnosis report + list of problems” as material for planning and implementation
Technical and indexing analysis
Technical and indexing analysis means checking whether the site is crawled and indexed correctly and whether the technical signals introduce any limitations or errors. I verify the elements that affect crawlability and indexability, and how the site communicates canonical versions, redirects and statuses to the search engine. I also check the areas that often create a risk of excessive indexing or of losing control over the structure, such as URL parameters and pagination. The aim is to pinpoint which elements need fixing and how they may affect visibility.
Within this block I also analyse the configuration of sitemaps and robots, as well as the presence and correctness of structured data. An important element is identifying duplication problems and sources of ambiguous signals (e.g. parallel URL variants or incorrect canonicalisation). The conclusions are described in a way that makes it possible to turn them into specific implementation tasks and to control the risks if they are not implemented. The result of this analysis is part of the “Diagnosis report + list of problems”, together with the recommended fixes.
- Crawlability and indexability
- Canonicalisation
- Redirects and statuses
- URL parameters and pagination
- Sitemaps and robots
- Structured data
- Duplication problems
Analysis of architecture and internal linking
The analysis of architecture and internal linking assesses whether the site structure leads the user and the search engine crawler to the right landing pages in a logical and consistent way. I verify the structure of categories and sections and how the site navigation is built. I also check click depth, to identify places where important pages sit too “deep” in the structure. This makes it possible to show where the architecture limits access to landing pages.
In this block I analyse contextual links and the consistency of the paths leading to key landing pages, and I detect orphan pages. I also assess whether internal linking supports the priority sections and whether there are gaps in the flow of internal links. The conclusions are recorded as specific observations and recommendations to be implemented in the further work. These elements go into the “Diagnosis report + list of problems” as the basis for planning tasks.
- Assessment of the category/section structure and navigation
- Analysis of click depth and access to landing pages
- Review of contextual links and the consistency of paths to landing pages
- Identification of orphan pages and gaps in internal linking
Action plan and task prioritisation
The action plan and task prioritisation turn the findings of the diagnosis into an implementation order, responsibilities and a way of monitoring. At this stage I arrange the actions so that the in-house team can deliver them in implementation cycles. I assign owners to tasks and agree which areas require decisions on the organisation’s side. In parallel we choose the metrics that will be used to monitor results and stability after the changes.
The key result is the “Task backlog (ticket-ready)”, prepared in a form that makes it easier for dev and content to plan the work. Each task contains a description, acceptance criteria, dependencies, risk and expected impact, in order to limit ambiguity during implementation and acceptance. Prioritisation takes into account the impact on indexing/traffic, the cost of implementation and the dependencies on releases and available resources. In the plan we also clarify whether the scope includes structural changes that require intervention in the information architecture, templates and URLs, because this affects cost, risk and the need for later QA and a redirect plan.
- Arranging the actions in implementation order and assigning owners
- Choosing the metrics for monitoring results
- “Task backlog (ticket-ready)”: description, acceptance criteria, dependencies, risk, expected impact
- Prioritisation by impact on indexing/traffic, cost of implementation and dependencies on releases and resources
- Decision on the scope of structural changes (information architecture, templates, URLs)
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.