- Use cases
- Customer Success
- LOG IN
- Start free trial
SEO in Orbit is the first webinar series sending SEO into space. Throughout the series, we discussed the present and the future of technical SEO with some of the finest SEO specialists and sent their top tips into space on June 27th, 2019.
Watch the replay here:
An artist and a technologist, all rolled into one, Michael King recently founded boutique digital marketing agency, iPullRank. Mike consults with companies all over the world, including brands ranging from SAP, American Express, HSBC, SanDisk, General Mills, and FTD, to a laundry list of promising startups and small businesses.
Mike has held previous roles as Marketing Director, Developer, and tactical SEO at multi-national agencies such as Publicis Modem and Razorfish. Effortlessly leaning on his background as an independent hiphop musician, Mike King is a dynamic speaker who is called upon to contribute to conferences and blogs all over the world. Mike recently purchased UndergroundHipHop.com a 20 year old indie rap mainstay and is working on combining his loves of music, marketing and technology to revitalize the brand.
This episode was hosted by François Goube, co-Founder and CEO at OnCrawl.
Back in the day, the thinking was that for SEO, you needed a completely different static version of the page in order to work with search engines, but that’s no longer realistic. Because much of the web has adopted this type of interactivity, search engines have needed to keep up.
Rendering addresses how a webpage is seen by different user agents.
This contrasts with a fully-rendered version of the page, which corresponds to how a user sees it in the browser.
Search engines can now crawl in a headless format, which allows them to see what users see in a browser. However, they don’t always do this. Rendering is still a different process from crawling. Rendering may or may not be carried out, or it may be carried out at a later time.
Essentially, you use AJAX to repopulate parts of the page using JSON objects. This is a lot faster than having to download every resource on the page.
This makes for a better web, and allows applications, from OnCrawl to Gmail, to exist.
There are instances of sites that use frameworks when they could have just been flat HTML. There are also examples of sites that use JQuery to update a single object, where there’s no need to download and use the whole JQuery library.
This comes down to the same issue we’ve always had to deal with in SEO: are people using the right tools in the right ways to create optimal experiences?
Because of the current cost, Google has to determine whether or not it’s worthwhile to render pages. Some pages have little to no material differences in content. It isn’t necessarily worthwhile for Google to render pages like this; they need to make sure that when they do render pages, it really is necessary to do it.
One of the main technical issues for SEO is the disparity between rendered and non-rendered versions of content.
|HTML (non-rendered) version||Computed DOM version (rendered version)|
|Blocks of content not shown||Resources loaded after the "document ready" state
User action required to load content
Mike also often sees issues concerning the implementation of SSR architecture. Many solutions require a cache refresh, which can take a long time. If the page is visited by Google during the cache refresh, Google may see it as a 5xx error, and that URL may fall out of the index.
Despite the fact that Google keeps encouraging people to do dynamic serving, progressive enhancement is still the better way to do it in order to ensure that the bulk of your content is available to any user-agent that come to your page.
Almost all modern frameworks have solutions for SSR. Some use add-ons; others, like React, have native options like render to HTML string.
If your framework doesn’t have support for SSR, you can use solutions like Rendertron or Prerender.io in order to effectively create HTML snapshots.
Mike recommends using SSR. When you add another server for third-party rendering, you’re adding latency. We want the site to be as fast as possible. This also creates another point of failure in the process.
In the beginning of 2017, the team of TutorFair.com asked for Omi Sido’ SEO services to help them. Their website was struggling with rankings and organic visits.
Consider whether you’re using a new framework just because it’s new. Angular and React, for example, are pretty entrenched at this point. There’s code and experience out there that can be leveraged.
Pick something that is both tried and true and that will be around in five years.
For Mike, React seems to be the way to go at the moment. He prefers native SSR. However, you can create snapshots with a variety of different tools, so you do have a choice depending on your technical requirements. He doesn’t believe any of the major known frameworks have any specific issue that means you might want to avoid them entirely.
Up until the latest versions, Angular was not as good as React for a number of reasons. This is curious, because Angular comes out of Google itself. However, recent versions have helped bridge this gap.
Bing has recently stated that they now accept websites that push their content to the search engine through the API, removing the need to render that content. In some ways, this makes a lot more sense.
This is essentially going backwards: we used to notify search engines to come take a look at a given URL. But this actually has the advantage of speaking to an architecture for web applications that make them more portable. It makes sense for everything (app, mobile app…) to be built from a central source in the form of micro-services in which you’re able to push everything out from a single API.
For Mike, if the web goes that way, it increases portability to new modes of consuming content, and makes a lot of sense.
It would also cut down on the computational expense of crawling from the search engine’s side.
Mike expects developers to understand how the choice of framework and implementation affect SEO. Furthermore, he sees more and more that developers are aware of SEO concerns associated with site technology choices.
For a long time, developers took the position of “Google will figure it out”, but there’s a growing awareness that possibly stems from client-side rendering being so problematic for so long.
For example, libraries that support SSR, like NextJS, are things that come out of the developer community, rather than from an SEO initiative.
Mike doesn’t have a specific method to evangelize technical SEO for developers, but usually takes an approach that can be applied to anyone.
To get someone to do something for you, you appeal to their self-interest. What are developers measured on? What do they care about? Mike then tries to align SEO with these things and to demonstrate how this impacts developers’ abilities to meet their own goals. You need to show what the value is going to be to a developer’s career, to short-term OKRs… This makes implementing SEO as valuable to developers as it is to SEOs.
Mike is known for his position on the “technical SEO renaissance“.
At the heart of this change is how SEO works. You don’t have to be a developer to do SEO, but being able to understand and communicate with developers is critical. Skills that matter include:
If Mike had to choose between a marketer and a developer to turn into a great SEO, he’d probably go with the developer, for the following reasons:
The payload, while critical, is what you want to focus on once you know that the content is accessible.
This is a trick from several years ago.
It consists of using the GA API to find the page that the user is most likely to go to based on the current page, and doing rel=prerender with that.
There are a lot of Googlebot User Agents that people aren’t mindful of.
If your website or your CDN blocks these user-agents, it can prevent your ability to take advantage of search features and tools. This includes:
Most things to make a site super-fast come from the server side:
On the front end, though:
The way React routes URLs, it’s easier to use a rel=canonical than to set up a 301 redirect from one URL to the other.
For interpreting hreflang, Google says they use pre-DOM HTML. Mike believes that Paul Shapiro was testing this recently and might have found a different answer.
The bottom line: use pre-DOM, because you never know whether Google will render the page or not.
You might even want to consider placing hreflang in the header to be sure that search engines will always see it, no matter what.
“As an SEO you need to be able to communicate with developers.”
If you missed our voyage to space on June 27th, catch it here and discover all of the tips we sent into space.