This is a deck I put together for a Technical SEO interview for iProspect in December 2019. The task comprised of two questions relating to JavaScript SEO and E-Commerce SEO for a specific product category. I have no affiliation with either the Body Shop or Asos and any data in the presentation was sourced from publicly available third party tools; it was a purely hypothetical and educational exercise. Several assumptions have also likely been made, and the contents of the deck merely reflects my thoughts looking from the outside in. Please don't take anything in the slides as gospel. Thanks for checking it out, Nick Samuel

1. BY NICK SAMUEL – 17TH December 2019
TECHNICAL SEO DIRECTOR –
QUESTIONS

2. Agenda for today
2
Contents
1 Question 1: Body Shop (15 mins)
2 Question 2: ASOS (15 mins)
3 Appendix
4 Additional Questions (30 Minutes)

3. Question 1: The Body Shop

4. Question 1: The Body Shop
4
Headless Commerce and Single Page Applications (SPAs)
“The Body Shop are planning on implementing a headless
commerce solution with a SPA for the front end, what are
the key factors for SEO that need to be considered and
communicated to the client? (15 minutes)”
What will be covered
1. What is a Headless & SPA?
2. How does it differ from a traditional CMS?
3. Pros, Cons & Challenges
4. Googlebot: Indexation/Crawling
5. SEO Considerations
6. Potential Solutions

5. 1.1 What is a Headless CMS…
5
“A headless CMS is a back-end only content management system (CMS) which makes content accessible via a
RESTful API for display on any device.”
The term “headless” comes from the concept of chopping the “head” (the front end) off the “body” (the back
end).
A headless or decoupled CMS is front-end framework agnostic, and usually the front-end involves a “Single Page
Application” powered by JavaScript.
…and what is their relationship with SPAs?
Body Shop currently uses
1.3.16

6. 1.2 How does it differ from a traditional CMS?
6
Short answer: Client side vs Server Side
Headless CMS
1. A way to store data
2. A CRUD UI
3. An API to the data
4. Client Side
Regular CMS
1. A way to store data
2. A CRUD UI
3. Ways to display the data
4. Server Side
Admin
Interface
View
Layer
Database
Integration Integration
Write
Read
Read
Admin
Interface
Database
API
Read
Write, Update
Offline
Store
WWW
iOS
App

7. Single Page App != Headless CMS
7
BUT it usually follows…
It’s arguably represents a natural evolution and the easiest way of interacting with a headless CMS
A single-page application (SPA) is a web app or site that interacts with the user by dynamically rewriting the
current page rather than loading entire new pages from a server.
In an SPA all necessary code (HTML, JavaScript, and CSS) is retrieved with a single page load. The name SPA is
in contrast to a traditional CMS or multi-page application (MPA).

8. 1.3 Pros and Cons: Headless VS Traditional CMS
8
Warning: Every point is context dependent
Advantages
• Front-end Agnostic
• APIs
• Future-Proof
Disadvantages
• Fragmentation of Tech Stack
• More Niche
• Less Marketing Friendly
Challenges
• SEO Efficiency
• Client Side Rendering

9. 1.4 A Quick Googlebot Primer – Indexation/Crawling
9
This is where client vs server side comes into play…
• The first wave requests source code,
crawls and indexes any present
HTML/CSS, and adds any present links
to the crawl queue.
1. Initial
Crawl
• On a client side rendered site however,
there’s basically nothing for Google to
index in the source code during this first
wave.
2. HTML
Render
• URLs in the second wave join a queue
and Google returns when resources are
available to fully render and index the JS
generated content.
3. JavaScript
Render
HTML
RENDER
INITIAL
CRAWL
JAVASCRIPT
RENDER
Instant, first
wave of indexing
As rendering resources
become available
Second wave of
indexing
New links to be crawled

10. 1.5 Key SEO Considerations
10
Relevant to both Body Shop and all SPA websites
Indexation/Crawling
Google doesn’t have finite
resources
5 Second time out rule
No user actions will be
triggered
</head> can break
On-site SEO
Each page needs a unique
URL
Links need to be rendered
with </a> tags
Creation of basic SEO
elements e.g. canonicals
Server response codes e.g.
404s & redirects
User Experience
Mobile First Indexing
JavaScript lives on CPU
Page Speed can be effected
Others bots not as adept as
Google

11. 1.6 Overcoming Limitations
11
Thankfully most issues can be overcome by optimising delivery…
Option 1: Pre-
Rendering
• Serves up different versions of the site depending on user
agents
• Bots = HTML Snapshot, Users = JavaScript Experience
Option 2: Server-
Side Rendering
• Rendering logic offloaded to Node.JS backend
• Data retrieved with each new URL clicked
Option 3:
Isomorphic
• HTML sent for initial view, subsequent actions handled
client side
• Can also work like traditional JavaScript e.g. jQuery

12. Conclusion: JavaScript + SEO = OK
12
The Body Shop Website has survived so far with an Angular front-end
Atwood’s Law: “Any application that can be written in JavaScript, will eventually be written in JavaScript” –
2007
The rules of traditional SEO apply when dealing with a consistent Source & rendered DOM. This can be
achieved by a number of approaches, most notably “pre-rendering” and server side rendering.
Every SEO requirement can be accommodated by popular Frameworks; don’t confuse Bad SEO with JavaScript
Limitations. SEOs need to work closely with developers and vice versa!

13. Question 2: ASOS

14. Question Two: ASOS
14
My approach to supporting ASOS through Technical SEO
“ASOS are looking to focus on the Bridesmaid
Dress category in preparation for Summer,
what would your approach be to support this
initiative through technical SEO? (15
minutes)“
1. Key Considerations
2. Data Analysis + Benchmarking
3. Technical SEO Audit
4. Potential Quick Wins
5. Roadmap + Implementation

15. 2.1 Key Considerations
15
How does a focus on Bridesmaids fit within the overall strategy?
Timing / Seasonality
Content / PPC / Cross-Channel Strategy
Existing Technical SEO Activities
Developer Roadmap
Links
Content
On-Page
Optimisation
Keyword Research
Technical SEO

16. 2.2 Data Analysis + Benchmarking
16
What are the KPIs and does forecasting existing?
1. Traffic
YOY Organic
GSC Metrics
Visibility/Rankings
# of Products
2. Behaviour
(Conversions)
Pages Viewed
Site Speed
Mobile Vs Desktop
New vs Returning
3. Revenue
Conversion Rate
Total Sales
Number of orders
Average Value

17. 2.3 Technical SEO Audit
17
As part of any “campaign” I would usually perform the following activities:
Ranking
Site Speed Checks
Internal Link
Opportunities
Schema Mark-up
Meta Data Review
& Creation
On-Page
Recommendations
Indexation
Meta Robots Canonicals
URL Pathways +
Site Structure
JavaScript Tests
Content/“Excerpt
search”
Crawling
XML Sitemap Robots.txt
Parameter
Exclusions
Server Log Analysis Hygiene (Links)

18. 2.4 Potential Quick Wins
18
Based on previous experience I would investigate the following areas:
1. Pagination/Infinite Scroll – Indexation Clean-
up
2. Keyword Cannibalisation – Keyword Mapping
(minimum)
3. Category/Product Descriptions – more text!
4. Internal Link Reclamation + Breadcrumbs are
inconsistent
5. Site Speed = 21 score on Mobile – Defer
Offscreen images and render blocking JS
TECHNICAL CAN OF WORMS:
Error Response codes 400 vs 404
URL capitalisation and canonicalisation
Analytic Tracking Parameter Indexation e.g. CTAref= 99,200
results

19. 2.5 Roadmap + Implementation
19
Below is a top level Technical SEO proposal “Bridesmaid category”
ACTIVITY WEEK 1 WEEK 2 WEEK 3 WEEK 4 WEEK 5 WEEK 6 HOURS
Crawling
Server
Log
Analysis
(16)
Website
Crawl (16)
48
Benchmar
king (8)
On-Page Audit + Analysis
(8)
Indexation Internal Link + Content
Recommendations (12)
16
JavaScript
Tests (4)
16
Ranking
Site Speed
(4)
Meta Data
Review
(8)
On-Page
Recommend
ations(4)
Total 24 24 8 6 14 4 80
Note: Timings designed to work with business as usual activities e.g. Monthly Reporting

20. Appendix

21. Glossary / Additional Terms
21
Here is a glossary of terms referenced but not explicitly covered:
API (General) - An application program interface (API) is a set of routines, protocols, and tools for building software applications. Basically,
an API specifies how software components should interact - https://www.webopedia.com/TERM/A/API.html
Client Side Rendering - Client-side means that the action takes place on the user’s (the client’s) computer. Server-side means that the action
takes place on a web server - https://skillcrush.com/2012/07/30/client-side-vs-server-side/
CRUD - In computer programming, create, read, update, and delete (CRUD) are the four basic functions of persistent storage/interacting with
databases - https://www.codecademy.com/articles/what-is-crud
Front-end Frameworks - A web framework (WF) or web application framework (WAF) is a software framework that is designed to support the
development of web applications including web services, web resources, and web APIs. Web frameworks provide a standard way to build and deploy
web applications on the World Wide Web - https://en.wikipedia.org/wiki/Web_framework
RESTful API - A RESTful API is an application program interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data -
https://searchapparchitecture.techtarget.com/definition/RESTful-API
Source Code and DOM - The source is the raw HTML that is unadulterated by any client-side scripts. It is the direct response of the HTTP request
to the server. The DOM, on the other hand, is the same HTML structure that has been modified by JavaScript -
https://stackoverflow.com/questions/29273391/what-is-the-difference-between-source-code-and-dom?noredirect=1&lq=1
Status Codes/404 Error - For every HTTP request the server provides a response code depending on the nature of the response. A 200 response
means the request was successful, 301 a redirect and a 404 means a page was not found - https://moz.com/learn/seo/http-status-codes

22. Further Reading
22
Here are the sources used in assembling this presentation:
1. Headless CMS and Decoupled CMS in .NET Core - https://www.hanselman.com/blog/HeadlessCMSAndDecoupledCMSInNETCore.aspx
2. What is a headless CMS? https://medium.com/@dominikangerer/headless-cms-explained-in-5-minutes-450f063850f7
3. Headless CMS vs Decoupled CMS: The Ultimate Guide - https://www.coredna.com/blogs/headless-vs-decoupled-cms
4. Headless CMS explained in 5 minutes - https://www.storyblok.com/tp/headless-cms-explained
5. WhiteHat Security Introduces Dynamic Single-page Application Scanning for an Automated, Seamless Customer Experience -
https://www.businesswire.com/news/home/20181009005239/en/WhiteHat-Security-Introduces-Dynamic-Single-page-Application-Scanning
6. Priorities for diagnosing JavaScript-powered websites - https://searchengineland.com/priorities-for-diagnosing-javascript-powered-websites-299519
7. Single-page application vs. multiple-page applicationt - https://medium.com/@NeotericEU/single-page-application-vs-multiple-page-application-
2591588efe58
8. JavaScript SEO: Server Side Rendering vs. Client Side Rendering - https://medium.com/@benjburkholder/javascript-seo-server-side-rendering-vs-
client-side-rendering-bc06b8ca2383
9. The Ultimate Guide to JavaScript SEO - https://www.onely.com/blog/ultimate-guide-javascript-seo/
10. JavaScript & SEO: Making Your Bot Experience As Good As Your User Experience - https://moz.com/blog/javascript-seo
11. JavaScript SEO: Server Side Rendering vs. Client Side Rendering- https://medium.com/@benjburkholder/javascript-seo-server-side-rendering-vs-
client-side-rendering-bc06b8ca2383
12. What’s Server Side Rendering and do I need it? - https://medium.com/@baphemot/whats-server-side-rendering-and-do-i-need-it-cb42dc059b38
13. Isomorphic JavaScript: The Future of Web App - https://medium.com/airbnb-engineering/isomorphic-javascript-the-future-of-web-apps-
10882b7a2ebc
14. @JohnMu Twitter - https://twitter.com/johnmu/status/894901485238190080

23. Thanks / Questions?
By Nick Samuel