This shouldn't be too tough, you reason. After all, all your web development team needs to do is start using absolute URLs in their code instead of relative URLs, and your on-page SEO will increase. You might think that all they have to do is write the whole URL instead of the route. How difficult could it possibly be?
So you set up a meeting with the web development team at your organisation to get things started. The team first discusses how relative URLs allow them to send code directly from the sandbox site to the live site. On their end, what you're asking for adds a logistical complexity. Instead of pushing the /my-page link straight from the staged to the live environment, they'd have to modify
They ask you to enter the request in their problem management system since you insist. Then they warn you that it could take up to six months to complete. After all, you have a large amount of requests ahead of you. But first, it needs to be approved by a number of executives.
Multiply this occurrence by additional SEO concerns such as site performance, click-depth issues, or Javascript rendering, and so on. Suddenly, you're inundated with budget ideas, project plans, emails, and meetings, all of which are impeding your SEO strategy.
Additional SEO requirements will cause more effort and friction for the IT team in many cases because important web infrastructure decisions have already been made. As a result, "No," "Let's wait," or "We may be relaunching the site anyway" will be heard far more frequently than "Yes."
But, before you get too worked up, take a step back and reconsider your strategy. Once you understand how your web development team performs, you can effectively partner with them to execute your priority tasks without affecting theirs.
Continue reading to find out how we overcame the most frequent IT barriers that sabotage business SEO efforts.
Key Points
Managing an organization's IT requirements is no easy undertaking. Not only do they have to deal with external software, but they also have to think about their own workflow and goals. That workflow, like your
team's, does not include abandoning their weekly priorities in order to accept the first request that comes their way.
Beyond that, there's frequently a mismatch between what you're asking them to do and what they're capable of.
Take the previous example of absolute vs. relative URLs. Will it be worth it for them to change the entire structure of their code-pushing process to accommodate this request if the only context you can supply is "It's better for SEO"? Most likely not.
Every project takes longer than you expect it to take. That is something you must really comprehend and internalise. Because it will make the "compromise" phase a lot less difficult. Consider the ludicrous expectations that enterprise SEO teams are subjected to when it comes to timeliness. These are also encountered by your developers. Don't be the worst customer they've ever had.
It's all too easy for us to assume that a "No" or a "Please submit a ticket" means "I'm being intentionally unhelpful." However, this is a rare occurrence. Your web development team, on the other hand, is undertaking triage. Before they can incorporate your request into their workflow, they must assess it against all of their other priorities.
If you give your IT/web development staff the courtesy of seeing things from their perspective, they owe you the same courtesy. Want to know what makes that a lot easier? Between SEO and web development, departmental silos must be broken down. The more closely your departments collaborate, the better they'll understand what it takes to achieve your individual objectives.
Maintain a basic level of education that is consistent across departments. Your SEO team can educate the development team on the technical components of corporate SEO. The web development team can also train the SEO team how to use the CMS to its full potential. And how to submit tickets in a way that keeps coding projects structured and prioritised. A working understanding is the result of having a working knowledge.
It might also be a good idea to make departmental workflows more transparent. Give each team full access to the same project management software, or send a weekly update or an online dashboard to everyone. This will make each team's responsibilities more visible.
Sprints are used by agile IT/web development teams. They specify their outcomes before adding a project to their sprint cycle. What do they hope to see in a new version? What are their objectives and key performance indicators (KPIs)? If your SEO project takes up 20 percent of their next three sprints, you’re asking them to make a compromise between known and unknown consequences.
Define the business outcomes and KPIs for your project as specifically as you can. This is especially crucial with top executives. They can prevent the entire department from taking action if they don't understand the ROI of SEO.
Because so many technological components interact to affect traffic, defining results for specific technical changes may be difficult. However, it's vital to provide development with a well-informed, data-backed estimate. Make use of your previous knowledge of websites that have made comparable adjustments. As a proof of concept, make the adjustment on a small number of pages. Use the data to support a site-wide change. Everything you can should be tied to a revenue-generating KPI, such as traffic or conversions.
You may need to convert your KPIs into the same language that your web development team employs when discussing results, depending on your team. For example, at Stridec, we worked with an enterprise customer that used percentages of predicted lift to forecast the results for each project. We gave rough percentages of predicted traffic boost to each planned activity before requesting adjustments from the customer's development team. Despite the fact that the customer knew we were making an educated guess, the forecasts provided them with something concrete to compare to their previous projects.
As a result, the project was hurried to completion.
We started working with that same customer by conducting an SEO audit on their website. And, as you might expect from a business site, our list of recommendations was enormous. We're talking 18,000 redundant title tags, over 500,000 duplicate pages in the index, and a page speed score of 1... regrettably, enterprise audits aren't uncommon.
The volume of recommendations was overwhelming to the customer's development team, as you might expect. It's difficult enough for your SEO staff to prioritise all of this work. It's cruel and unusual punishment to simply hand it over to the web development team and say, "Fix this."
Rather than enlisting the help of another team to figure out the workflow, do all of the prioritisation work yourself. Break down each activity into manageable chunks. Indicate what will have the greatest impact on the company's bottom line. You may justify seeking extra work if you have some outcomes.
Is your company aware of the importance of organic search to its bottom line? Traffic, acquisition costs, new consumers, revenue, and stock price are all factors to consider. If that's the case, you might be able to use some of your marketing revenue to hire a "in-house" developer. Content/SEO teams frequently have their own designers. It's possible that you'll be able to justify hiring a developer as well. So long as you're able to convince the correct people of the value of SEO.
Let's start with the question itself. Compromise is the key here. If you don't waste bandwidth on minor difficulties, you'll be more likely to receive assistance for major issues.
Gather all of your technical needs and enter them into a spreadsheet. Estimate the time it will take for each request next to it. Assign the business impact after that. The "lift vs. impact" paradigm is a useful tool for determining which work should be prioritised first.
Is your website's URL structure difficult to navigate and SEO-friendly? Although this is a high priority, it is also a large-scale project that will require C-suite support. If you can't attach alt text to photos, on the other hand, that project may have to be put on hold until the greater issues are resolved.
As an aside, it's usually advisable to keep emergency circumstances distinct from the rest of the list.
If you run your website through a page speed testing tool and then deliver the program's entire list of recommendations to your developers, they won't know where to start. So, as you're breaking down the task, keep an eye out for items that your SEO team can take care of instead. You may, for example, look for a plugin that compresses photos so your developer doesn't have to.
You might just require five hours from developers instead of 20 if you delegate some of the job to your own team.
The same terrible implementation on 100K pages can be as simple as pie on each page as it's built. So, rather than troubleshooting, your primary purpose should be to educate (and proactively reduce the need for retrofitting). Never enter tickets into your problem-solving system at random. Your job isn't done until the web development team knows why you're making the suggestion and how they can include it into their workflow in the future.
Assist the web development team in establishing standards for unused code in their CSS and Javascript libraries. Teach them the importance of canonical tags. As part of their upload procedure, teach students how to compress files. You'll accomplish a couple things by assisting them in incorporating SEO into their approach.
Because you'll be eliminating difficulties first, you'll steadily reduce the number of requests. Following that, your engineers will get a better understanding of enterprise SEO and web development, making them more responsive to requests.
Finally, what if your web development team notices that you're proactively managing requests and reducing their SEO-related workload? They may do you a favour and provide you the absolute URLs.