One way to get a handle on understanding semantic search (the underlying principle of Hummingbird which I covered last month) is to compare and contrast it with old-fashioned search-sometimes called programmatic or literal search.
We can start by comparing the kinds of results each kind of search returns. After all, results, or the user experience, is something SEO professionals should care about.
Literal or programmatic search is sort of like doing research with a card catalog (anyone remember those?). In the really old days, when people found information in libraries, sources of information (books) were catalogued in drawers full of little cards. You could search by topic or author, and what you found was a group of cards listing sources within the library on the topic of your interest.
So, using the card catalog was a three-part process:
- Ask a question
- Get a list of sources
- Look for your answer in the sources
The results from literal search engines are a little like this – you get a list of blue links to sources that might contain what you’re looking for. The search engine returns your list of sources, but then you get to do the digging for your answer. It’s a three part process.
Semantic search is going to improve the list of blue links you receive. But it also has the potential to return direct answers to your query right there on the page. This is new.
Although it’s still in its infancy, The Google Knowledge Graph is already returning answers like this. If you type in “How tall is Mount Kilimanjaro?” you’ll get an answer right there above or beside the SERPs. In this way, the semantic part of Google is making Google itself into the mother of all information sources.
This is a two step process:
- Ask a question
- Get an answer
Now let’s look at some of the ways literal and semantic search operate differently on the back end.
Who Will Read the Content?
It’s important to realize, especially for the future, that semantic also differs from literal in who or what will consume the content for each. Ultimately all search functions are there for the benefit of humans, of course. But content written for literal search engines is meant to be read by humans, while content for semantic search has to be readable by machines and/or programs that make the connections that deliver the more nuanced results.
The Tool of Comparison
In past posts I’ve already described that literal search is about matching keywords, and semantic is about understanding those keywords in context and intent. It’s primarily about relationships between keywords and the layer of semantic relevancy search engines can then use to make adjustments. Both are operating on some kind of comparison system.
Literal search finds the results to return by indexing, while semantic search functions in a very different way: by comparing search queries to information stored in vast, pre-organized databases of knowledge and returning results from that pool. These databases store knowledge, but they also relate pieces of knowledge to each other, showing rational relationships that at a very basic level perform “reasoning.”
The Unit of Comparison
Literal search uses the keyword as the unit of comparison.
Semantic search uses something called entities.
Both of these units are kinds of data, but with literal, this data is said to be “unstructured.” That means it hasn’t been organized or classified in a pre-defined way to help the search engine understand it. That’s because data for literal search engines is primarily readable for humans.
Content for semantic search engines has to be readable by machines. It’s machines that interpret the meaning, intent, and context, and draw conclusions about how data relates.
To enable this kind of relationship-building, semantic search technologies have to compare apples to apples. And the way this happens is by turning data into “entities.”
Structured and Unstructured Data
Entities are still basically pieces of data, just like keywords or phrases are, but with an important difference: they have pieces of code around them telling the search engine how to understand and interpret them. The code used to create this language is called semantic markup, and the result is called “structured data.”
Structured data means information is marked up in consistent, predefined ways into consistent predefined categories. These categories, also called types or schemes, allow search engines to compare apples to apples. There are hundreds of types of fields or schema, including book, movie, song, person, place, thing, review, event, organization, local business, restaurant, date, time, article, blog post….the list goes on.
You can see how adding code to tell the search engine how to understand data in this way could lead to all kinds of new potential uses for the data. Even 10 years ago we did not have the technology to process data this way, but things are different now.
Reminder: both kinds of search are still relevant. Keywords still matter; they just aren’t the only game in town. Over time, keywords as a standalone signal of relevance will decrease relative to the relationship between entities.
What are some practical implications of semantic search to your future customers:
- Search queries will improve based on contextual relevance
- Substitute, secondary, and co-occurring terms will become more prominent & useful
- Mobile & tablet searches, especially, will benefit from entity-based relationships
So what should you start to do differently:
- Promote the schema.org tagging protocol with your web teams
- Look through the top 10-20 search results for co-occurring terms and whether you can modify content for these too
- Evaluate your common mobile, tablet, and location-based queries as entity search is ready-made for non-desktop SERP improvements
- Improve listings for your most common products & people in Wikipedia and other well-accepted sources, as those are the primary content populating the Knowledge Graph
- Check out the Google Autocomplete (formerly called Google Suggest) filtering and whether your brand content ranks for additional terms. Replace your keywords in this URL
- Use keyword tools like LSI Keywords or Uber Suggest to understand the entity relationships of your top keywords
- Use internal linking, anchor text, & social citations as addition signals to establish contextual relationships
In my view, semantic markup is evolutionary not revolutionary – a new form of keyword optimization with the entity as a new type of keyword. If you’ve designed websites based on strong product & solution relationships, simply provide more context to engines and then stay current with future recommendations.
The science of information retrieval & processing is still in it’s early years in my opinion. It’s exciting to think of the potential as the sweet spot between computer processing power, computer science algorithms, and digital marketing expertise expands. As modern marketers, it’s critical to work with your teams now on improving entity relationships between your digital assets so you’re moving in the direction of the future.
In part one a few weeks ago, we discussed what brand TLDs (top level domains) are, which brands are applying for them and why they might be important. Today, we’ll take an in-depth look at the potential benefits for brands, and explore the challenges brand TLDs could help solve.
In 2017 it is essential that SEO professionals secure the buy-in they need from their business leaders so they can accomplish their professional goals.
Dating back to Ancient Greece and Egypt, monumental structures have relied on the strength of stone pillars, working together to support an immense amount of weight and pressure.
This past November Google announced that it was starting to test indexing their mobile index as the primary index above desktop.