The first Tuesday of the month means another Melbourne SEO Meetup! The May 2019 Meetup was interesting for the Melbourne SEO Meetup and exciting for me because it is the first time in almost a year in which I get to present!
I love geeking out with my fellow SEOs as we nerd out over structured data and schema.org. It is a topic that even experienced developers have trouble with as the documentation isn't exactly a frictionless experience. This is why I was so excited to present, as I can do the hard part of reading the documentation and the W3C specification so they don't have to.
The Search Marketing Summit being held in Sydney took away some of our regulars, but over 60 people attended this month which continues to showcase the amazing reach and inclusiveness of the Melbourne SEO Community.
This event was hosted by James Richardson and the fine folks of Optimising in their wonderful Richmond offices, with pizza and alcohol provided.
They do an amazing job hosting with their team accommodating all the attendees and they will host again in June.
There were two presentations this month, with Iain Calvert talking about getting value from SEO, providing lessons from his vast experience with practical advice.
You also have me, talking Structured Data and schema.org.
Mingling and Chit-Chat with the Melbourne SEO Community
I say it almost every month, but Melbourne SEO community is second to none. It is fantastic to catch up with everyone and to see how everything is going both professionally and personally.
I got to catch up with my fellow Croatian Filip Karinja from Smallcaps, my dear friend Sanket Bhasin from Communicate This, Nik Pasic, Nik Ranger, Crystal Wong, Lauren Reece, Jasmin Ayles, David Pagotto, Harris Panayi, Adam Potaznik, Maryse Dubois and many more.
The Melbourne SEO community is unrivalled with their sense of belonging, inclusiveness and willingness to share information. It was an absolute pleasure to present to them.
A big thank you to Saijo George, Jamie Gemmell, Pamela Alison Meagher for organising this month, top work as always.
Turning SEO into Gold by Iain Calvert
Iain's Slides on 'How to turn SEO into Gold' are available here
Iain Calvert did a great presentation and provided real insights on the practical ways to scale an SEO operation and get value. Useful, useful stuff, especially for the Agency-side people in the audience.
He began his presentation with a little humour, poking fun at the unreasonable demands of some clients and bosses on how they handle SEO.
Iain provided 5 tips on his presentation on how to get value from SEO.
Tip #1 - NEVER assume your client or boss knows what you think is obvious
Iain mentioned the dangers of having specialised knowledge and making presumptions on what is considered 'obvious'. He also mentioned how to share what is seemingly obvious pieces of information that may be truly valuable to the person you are with - whether they be boss or client.
Tip #2 - Make it simple with analogies
He emphasised the importance of using analogies in communicating SEO information to people in an easy to digest manner.
Iain provided three examples:
- SEO Is Like Drilling Holes In A Dam: Here, SEO is provided as an example of a lot of work to get tiny results - but can become overwhelming when the dam's infrastructure breaks. Every little bit of work counts and produces results long term in an overwhelming rush of water.
- Links Are Like Recommendations Not Votes: Here, Iain used the example of taking financial advice from a crazy guy on the street. How likely are you to follow their advice? The same can be true from links - 100 crazy people telling you to do one thing vs the leading expert in the field telling you otherwise, who would you go with?
- Putting The Right Car In The Google Race: This example showcased two cars - one beat-up bomb that has been modified and a fancy racecar. The analogy here is regarding platforms, and how having the right platform will allow you to compete in the SERPs rather than over-working a website that isn't capable of competing in the first place.
I thought the analogies work well, though as an SEO person I do tire of the car analogy. My favourite analogy that I use is regarding how the SERPs work like a local business.
Ranking #1 in Google on a good query is like having prominent real estate on a busy street full of potential customers. Ranking high for the wrong keyword would be having an unrelated business like a comedy club on the way to a busy stadium. Ranking high for a low volume keyword would be like having prominent real estate on a deserted street.
Concepts like this 'connect' with the minds of businesspeople when they are explained in these terms. It makes it based in reality and the ideas stick.
Tip #3 - Know Your Numbers
This was not a discussion on metrics or KPIs, but rather specifically the numbers in running an agency. Iain mainly spoke about the revenue too salary ratio, and where the ideal value is. Too little revenue means too little work whilst too much vs salary means you don't have enough people.
Tip #4 - Offshore Properly
This was an interesting an unexpected turn in the presentation as Iain went in-depth on the offshoring process too take care of menial tasks and maximise the value you are providing to clients.
Iain spoke highly of Filta, an offshoring agency with an outstanding looking office in Manila, Philippines.
From what I understood, they provide a service to help build your high-performance offshore team. Whilst not directly relevant, this was certainly interesting to the audience and became a major part of the presentation.
Iain's final list of advice on offshoring was these key points:
- Dedicated team: Have a team, not freelancers who can work together with team and each other.
- Don’t do content: Even though the Philippines have a high level of English proficiency, quality matters and there is so much within the context of Australia that makes having local writers important. Even offshoring to primary English speaking nations such as USA or America do not compare to Australia writers.
- Process work: Assign the offshore team with process work to make your job more easier and more scalable.
- Brains here braun there: Rely on strategic think with your in-house team whilst simple, time-consuming tasks can be offshore. This provides the best value to yourself and clients.
- Save 63%: Offshoring can make significant savings for the team and allows you to work on the balance of revenue vs salary as you scale your agency.
Tip #5 - How To Get More Time To Implement
Iain begun this part of the presentation with a little bit of humour:
- Don’t be a well known 3 letter Melbourne based SEO Company
- Get shit done
Certain 3 letter Melbourne based SEO companies have... let's say, a questionable reputation amongst search professionals.
The second point was the meat of this section, which was to be productive.
Google Data Studio for dashboarding will save a lot of time in doing analysis and providing reports to clients. Having various data sources such as Google Analytics and Google Sheets can present rich data visualisations that provide value to clients.
Answer the Public is a service that shows questions related to keywords. Using this tool, you can use this to form some topic-based keywords to produce content alongside your client. I personally prefer Scrapebox for this type of research, but I am old school.
Tip #6 - Don’t Charge By The Hour
There is no gold in SEO by charging by the hour, according to Iain. He showcased a graph showcasing that the more hours and more people are involved in a project, the more complex it becomes. It is not economically feasible to charge by hour when tackling difficult projects that require lots of people with different specialties.
Instead, Iain insists that you charge by value.
- Work out what they value (not what you value)
- Understand your “cost price” hours + tools
- Understand your “cost price” hours + tools
Iain recommends reading Priceless: The Hidden Psychology of Value to get an understanding of creating value to a client so that you can bill appropriately.
Turning SEO into Gold Summary
I found Iain's presentation insightful, even as an in-house marketer who isn't in the target audience. his talk can be summarised with these 6 points:
- NEVER assume your client/boss knows what you take for granted
- Use analogies to make boss/client understand
- Know YOUR numbers that matter
- Offshore properly
- Set yourself up to implement more
- Charge by value not hours
He was a welcome addition to the Melbourne SEO Meetup speaker list and I am sure we will welcome him today.
Structured Data Explained: Everything you wish you knew about schema.org by Peter Macinkovic
Following Iain, it was my time to shine as I talked all things Schema.org to the Melbourne SEO community. I was slotted 45 minutes, but I ended up talking for 90 minutes due to everyone's insightful questions! Full slides are below:
The talk covered 5 core areas around Structured Data and Schema.org:
- What is Structured Data
- Standardised Formats
- Schema.org
- Google SERP Enhancements
- Schema.org debugging and gotchas
What is Structured Data
Structured Data provides context and semantic meaning to HTML Content. It helps makes human readable content structured so it is machine readable.
Machines aren't very good at understanding semantic meaning in human readable content and with Structured Data we can help close this gap.
When information is highly structured and predictable, search engines can more easily organize and display it in creative ways.
To demonstrate, I showcased a Google result for NFL Quarterback Tom Brady in the Search Results and annotated elements of the page that could be structured in a semantic way.
Standardised Formats of Structured Data for the Web
Structuring Data for semantic meaning has a long rich history, going all the way back to now outdated formats used to categorise data for the purposes of education.
Structured Data for the Web began to formalise in 2004 with RDFa, and other the years format improved, got standardised and now enjoy usage - in particular for SEO. Here is a brief timeline:
- RDFa: Developed in 2004, standardised in 2007.
- Microformats: Developed in 2005. A more design focused standard for humans, not robots.
- Microdata: Developed in 2009 by Ian Hickson - the Father of HTML5.
- JSON-LD: Developed in 2010. A serialised form of Linked Data in JSON Format.
RDFa
RDFa is a legacy of XML and was the first form of Structured Data for the Web. Since 2009, RDFa Lite had become the standard for RDFa structured data.
RDFa uses HTML Attributes to structure markup rendered on a web page. It has the following syntax:
- vocab: sets the Item Scope.
- typeof: sets Item Type.
- property: sets the property of an item.
RDFa is still used today, but it is the least used of the three major formats.
Further Reading:
Microdata
Microdata is the brainchild of Ian Hickson, who designed HTML5. 2009 was a big year for the semantic web, with HTML5 and Microdata leading the way in creating a cleaner, more structured web.
Microdata was designed to be a simpler syntax when directly compared to RDFa and fitted well with the new semantic elements we had received in HTML5.
Between 2013-2018, development was terminated, and was renewed in 2018 under the guidance of Chaals McCathie Nevile from Yandex and Dan Brickley from Google.
Much like RDFa, Microformats use attributes to structure data as key-value pairs. it has the following syntax:
- itemscope: sets Item Scope.
- itemtype: sets Item Type.
- itemprop: sets property of an Item.
Microdata is the most used of the Sematic Markup forms of structured data due to its simpler syntax and how it was designed to be used with HTML5 in tandem. The lack of development is a major issue in adopting it as well as issues with scope with nested properties in messy markup.
Further Reading:
JSON-LD
JSON-LD was developed in 2010 as a serialised form of Linked Data in JSON syntax and has quickly risen to be the format of choice in implementing Structured Data on the web - particularly with Schema.org and the Google Knowledge Graph.
Simple to implement with <script> tags, JSON-LD became widespread due its robust implementation and reduction in scope conflict. An official endorsement by Google also made it the format of choice by SEOs and software vendors alike.
JSON-LD uses the JSON syntax to implement structured data that can be read in an RDF standard. An object in JSON-LD can be used to set Context, Types and Properties.
The only downside with JSON-LD is that you use the sematic structuring of Markup in the DOM, however with new features such as cssSelector and xpath within the Items such as WebPageElement, the Semantic Gap is closing. JSON-lD has been constantly worked on since its inception and the current draft is by Gregg Kellogg.
Further Reading:
What is Schema.org
Schema.org is a collaboratively maintained community to create, maintain and promote schemas for structured data.
It was founded in 2011 by the big four search engines at the time - Bing, Google, Yahoo! and Yandex.
Itemscope, Context Itemtype & Properties
- Itemscope specifies the block of HTML code is an itemtype for RDFa & Microdata
- Context in JSON-LD sets the schema the object belongs to. This is typically set to https://schema.org
- Itemtype is the schema object, which can either be a Thing or DataType
- Properties are the attributes of an Itemtype
Itemtypes
Itemtypes are Scehma Objects. All Item Types are derived of Thing except Data Types.
The syntax of Item Types is in Pascal Case, also know as Upper Camel Case.
There are 9 sub-types of Thing which embody all Item Types with the exception of Data Types.
Data Types are objects liek Text, Boolean, URL etc. which are more for strictly typed data.
A full list of types is available on Schema.org
Below is a visual Representation of the Itemtypes of schema.org v2.2 (circa 2015) This Interactive Diagram is courtesy of Fabio Valsecchi, Gregg Kellogg and Sandro Hawke
Properties
Properties are part of Item Types. They help classify properties of an ItemType in a structured nature.
Properties have Expected Types that they may passthrough. Typically this will be either a subtype of Thing or a Data Type
Properties are in camelCase, specifically lower camel case.
Properties can accept an Item Type that is a sub type of Thing. The Expected Type of an object can also be a Super Type or Sub Type of the Expected Type, as long as that property exists for the Super Type or Sub Type.
Sub Types may gain specific properties for it and its children that differ from the Super Type.
Schema.org by Example
Expected Types
Expected Types are Item Types that the Schema.org definition expect for a particular property.
Typically this will be either a subtype of Thing or a Data Type
Expected Types may still validate with a Sub Type of Super Type
e.g. Expected Type of LocalBusiness can be a Pharmacy
e.g. Expected type of ListItem can be a Thing
Expected Types may have some mandatory fields beyond name or id when validating for Google Search Enhancements
Sub Types
Subtypes inherit properties from their parent Item Type.
Subtypes may have multiple Super Types that it can inherit properties from.
e.g. a Pharmacy can inherit properties from Thing, Organization, Place, MedicalOrganization, and LocalBusiness
e.g. a Pharmacy can be a SubType of either a MedicalBusiness or MedicalOrganization
Inherited Properties can go quite deep for Sub-Types, deriving the core Inheritance from Thing and additional properties from parents with inheritable properties.
Nesting Item Types
Item Types have properties that are expected to be other Item Types.
The nesting of some Item Types are flexible and they can have each other item types. This was especially useful with RDFa and Microdata as you didn't have to rework your markup - instead, you just had to be clever with your schema design.
- e.g. a Product can reference on Offer via the property of offers
- e.g. an Offer can reference a Product via the property itemOffered
Multiple Itemypes
Google recommends using JSON-LD in particular for nested items and multiple items. In practice, it is easy to see why.
JSON as a syntax works very well in dealing with arrays. In JSON-LD, multiple Item Types can be placed in an array using square brackets. This is a lot simpler than refactoring markup or abusing the <meta> tag within scope in the markup which was a big practical limitation of implementing schema in practice.
Many Sub Types of Intangibles such as Enumeration and ItemList are designed to handle a list of items.
Enumeration & Data Types
Data Types handle data types such as integers, strings, booleans amongst others.
- e.g. Text, URL, XPathType, CssSelectorType, Date, Boolean, True, False etc.
- Data Types may be subject to standards such as ISO 8601 for Date or Unicode for Numbers.
Enumeration members can be set to specific canonical Schema.org item.
Handling Multiple Schema Objects
Without any explicit declaration, Google will infer that your page is a WebPage. To quote the documentation:
Every web page is implicitly assumed to be declared to be of type WebPage, so the various properties about that webpage, such as breadcrumb may be used. We recommend explicit declaration if these properties are specified, but if they are found outside of an itemscope, they will be assumed to be about the page.
This is done to prevent conflicts with multiple objects on a page, with the presumption that each ItemType on the WebPage is implictly part of the WebPage itself.
From a web standpoint, this is true - if you are declaring marked up content on a Webpage, it belongs to that webpage in some way, shape or form.
If ItemTypes have a better URI that represents the object, the mainEntityOfPage property works well if Structured Data on the page contains content elsewhere on the web - such as a list of products.
If you have multiple Schema objects of the same type on the page, they will be treated as an array without an explicit declaration.The implicit declaration would render ItemTypes individually, but it will be treated as if it was an explicit declaration of an array of items.
Without setting mainEntityOfPage for the individual objects or using the appropriate wrapper with the mainEntity of a WebPage (or its children) that support listed items - such as https://schema.org/ItemList and its children - this can lead to strange behaviour upon interpretation.
For example, the price of a 'Related products' list may be used as the price in the Rich Snippets instead of the primary product of the page as Google has no way to determine which Product is to be used for price information. This can especially be true when these elements appear earlier in the DOM