During my time as an SEO, I have slowly but surely honed in on my specialty – Programmatic/Dynamic SEO.
It’s something I enjoy more so than regular SEO, because the smallest of change can have such a vast impact due to the sheer volume of pages being modified.
However, I’ve seen a large gap in many SEOs understanding of what dynamic SEO is, how it works, and most importantly – how to think about it.
You have to go through a different thought process when compared to normal SEO, but I’ll get into that shortly.
So let’s run through what is it, how to think about it, dynamic strategies, and a handful of examples for some inspiration.
What is programmatic SEO?
Programmatic SEO at its core is bulk optimising a website using variables/templated elements across many pages once. One change affects thousands of pages. These variables are stored in a database somewhere, that could be extended out to create the new pages.
You could be building out the system, or just optimising an existing system.
With ‘normal’ SEO, you make one change and it will affect a single page.
Dynamic SEO refers to making a single change and having it affect hundreds, thousands, or even hundreds of thousands of pages.
Imagine a car hire website, with hundreds of locations available to rent their cars from. You could have a page title of;
Car hire <location> – Deals on rental cars in <location>
Then every location page will dynamically insert their location and you’ll get;
Car hire Melbourne – Deals on rental cars in Melbourne
Car hire Sydney – Deals on rental cars in Sydney
Car hire Brisbane – Deals on rental cars in Brisbane
But then maybe you want the combinations of vehicle type in there too, you’d look at a title like;
<vehicleType> hire <location> – Deals on rental <vehicleTypePlural> in <location>
Which would give you;
Car hire Melbourne – Deals on rental cars in Melbourne
Truck hire Melbourne – Deals on rental trucks in Melbourne
Van hire Melbourne – Deals on rental vans in Melbourne
4WD hire Melbourne – Deals on rental 4WDs in Melbourne
With this being replicated across all locations & vehicle types in the database.
Another good example is a real estate website.
Imagine all the different search result pages available when looking for a property.
There are two key elements in there that should almost always be optimised for – Channel, Property Type & Location.
So if we use a page title template of;
<propertyType> for <channel> in <location> – <channelSecondary> <propertyType> from <price>
That will throw out titles like;
Apartments For Sale in Richmond – Buy Apartments from $499,000
Houses For Sale in Richmond – Buy Houses from $499,000
Apartments For Rent in South Yarra – Rental Apartments from $599,000
Units For Rent in Richmond – Rental Units from $325 p/w
Those titles use the combination of channel, property type, and location, along with a secondary version of channel to optimise for that variation. I’ve also thrown in a dynamically updated price which would reflect the lowest price from that search result and would be leveraged in an attempt to help the CTR a little.
Each of these pages would obviously have optimised content, whether it be just a search result page or whether it be some sort of dynamically optimised location page.
That is Dynamic SEO in the most basic form.
The types of websites that can leverage dynamic SEO
There’s what I feel is a common misconception when it comes to programmatic SEO, and that’s that it involves completely JS websites dynamically updating all the time.
Mostly poorly optimised, client-side JS crap essentially. And hey, that’s what I used to think because I never really understood it.
There’s so much more to it than that though!
Yeah, JavaScript websites tend to do this a lot more as they are built to allow this type of optimisation. They don’t have a core set of “pages” for the most part and just leverage a database.
So do many other websites though.
So, who could use dynamic SEO?
Anyone with a database of some sort of content. This could even be a simple spreadsheet to start.
Something that could be used to basically create a page.
My favourite example is for portals, marketplaces and classifieds websites.
You get to leverage your consumer’s & customers’ content to rank!
You don’t need to create the content. Just need to organise the DB content most effectively.
Large portions of the content on these types of websites get copy-pasted across many different websites so it just comes down to who uses it most effectively.
These sites have listing data. This data is super valuable, but not just for the listing page itself.
This data becomes valuable for the information associated with that listing.
Categories, locations, features… the list goes on!
Let’s say for a real estate portal.
A listing can rank for its address, but a term like “real estate Sydney” is silly to rank for with a single listing.
Consumers want multiple options shown when they search for that.
So, you create search result pages (SRPs).
Search result pages that are dynamically optimised because they aren’t actually “created” one by one.
Using all the listing data, you aggregate your listings based on factors that make sense to rank for.
Location – “real estate Sydney”
Property type – “Apartments”
Channel – “Real estate for sale”
Location + Property Type – “Apartments Sydney”
Location + Property Type + Channel – “Apartments for Sale Sydney”
The list just goes on.
For these larger websites, these pages aren’t created one by one. They’re set up similar to how I mentioned above, where you kind of just map the templated elements.
The listing data contains all these properties on each listing so that the URL can then be used to make the appropriate request.
A URL of /buy/sydney/ would obviously represent all properties for sale in Sydney, so that is what the database would return.
A URL of /buy/sydney/apartments/ would be all the apartments for sale in Sydney, and thus that is what would be requested from the database.
There is no /buy/sydney/apartments/ page itself, the system just knows the specific values.
These variables essentially just filter the database query that is made, to return related content.
The dynamic SEO thought process
The biggest thing to think about with dynamic SEO is that you won’t always get everything 100% right.
You will have to make sacrifices.
Sacrifices that may hinder a portion of pages, but will benefit the majority.
One optimisation that will benefit some, won’t benefit others.
You need to just think about, and optimise for, the majority.
As time goes on, you can slowly refine your strategy as you go, to lower the sacrifices that are made.
Depending on the level of site/client you’re working with will come down to what % that majority will be in the initial stages.
So you may launch something that helps 80% of the pages, great! But that poor 20 % sits off alone. Next time, you could come back and specifically tweak that 20% so that 80% of them, could be helped. Each tweak is less valuable individually, but can still help you grow overall once all the quick wins are ticked off.
What do I mean by this?
Well, let’s say you have a list of 1,000s of locations. Those location names have different lengths.
“Sydney” is a nice 6 characters long, but then the suburb of “Sydney Olympic Park” is 19 characters.
If you’re trying to come up with a single page title that allows for the lengths of both, you could be missing out on keyword/CTR opportunities for the shorter location but also be getting the longer one truncated.
Apartments For Sale in Sydney – Buy Apartments from $499,000
Apartments For Sale in Sydney Olympic Park – Buy Apartments from $499,000
Another one could be where “Apartments for sale in Sydney” is the top keyword for Sydney, but then for Melbourne, the keyword used could be “Melbourne apartments for Sale”.
You’ll have to pick one to target as your primary format.
Down the track, you might be able to tweak the system to allow for both formats. You’d also need to go through and assign the formats to each, so it’s nowhere near as simple as just picking a single format to work with.
Think about the majority
You should do an analysis of all the top keywords, work out the average format, and primarily optimise for that.
This means that you will need to make sacrifices, but just remember – you want to try to optimise for the 80%, with 20% of the effort. Keep it simple, to start.
At this level of site, page-by-page matters less than for a smaller site, especially when you’re getting started.
Once you’ve really started to take hold across the board, and there are no more ‘bulk’ changes you can do, that’s where you can focus on your more manual, page-by-page optimisations.
After a while, you could come in and do fallbacks for these titles.
So you may have one format if the location is less than x characters, and another format if the location is longer than that.
Yeah, you could do it from the start, but you may increase workloads to get all the possibilities created when they just aren’t needed right away.
You’ll also get additional buy-in from stakeholders if you can find the quick wins within your optimisations.
Optimising a Programmatic Build
The Variables
What variables do you have access to
The data points that you actually have access to, and can leverage.
For a real estate portal, this could be things like; Location, Property Type, Price, Bedrooms, Bathrooms etc
You should start by listing them all out somewhere so that you can work out if there are any gaps that you might want to optimise for.
What variables do you actually want to rank for
Based on keyword research you’ve done for the niche, you should be able to line up some of the variables you have access to, with the keyword data.
Using the real estate portal example, Location & property type are both great and a large portion of keywords will contain one, or both, of these variables.
What variables should you actually try and rank for – not all are equal
Not all variables are equal. You will get more ‘bang for buck’ with some, over others. For many variables, you will just end up creating significant amounts of crawlable/indexable URLs that will waste Googlebot’s time and offer minimal to nil value.
It’s vital to choose your variables carefully.
With real estate, you’ll have pricing, bedrooms, bathrooms, sqft and many more that just may not be what you should create pages for due to the significant volumes of variable options.
Using pricing as the example here, there are soooooo many different price filters that could be set. If a site offers 50k increments for the filter, and starts at 200k, they could go into the low millions meaning there could be 50+ variations of the single filter. This becomes large issue when you mix this with a location set of say 10,000 locations, and end up creating 500,000 price-related indexable URLs when only a handful of the keywords like ‘real estate for sale under 500k’ may be worth actually optimising for.
Similar thing with bedrooms. Yeah, 3 bedroom houses in <largeCity> may be worth it, but ‘3 bedrooms houses in <middleOfNowhereTown>’ when you have 10,000+ towns like that, along with 5-6 bedroom filter options, you’re creating 60,000+ URLs just for that single additional filter.
You can add rules to these, and create more ‘manual’ pages to target specific versions of the variables, but as a whole, anything that creates significantly more URLs that what would actually be used to rank should be avoided.
Multi-variant – multiple options
When creating pages, you could create single variable pages that could target pages like ‘houses for sale’ or ‘apartments for sale’, but many of the keywords may include two variables, like ‘apartments for sale in Sydney’.
You will need a way to allow for the creation of these pages. Not only that too, but a way to create them cleanly so that you can ideally set one as the ‘parent’ in the hierarchy to appropriately pass value around the site.
Why would too many low-value URLs become an issue?
There are a few reasons why too many URLs isn’t always a good thing, and the first comes down to crawling. Whilst Google will try and prioritise certain URLs as best possible, you will end up just wasting your crawl budget if a significant percentage of your crawlable URLs offer little to no value.
The other reason is that the content being used on these pages begins to show up on 100s to thousands of similar pages leading to Google essentially seeing duplicate pages. If it keeps seeing the same content page after page it’s may not treat it the same way, and will start devaluing these specific URLs. Then you’re left with URLs that are still available to crawl, but with minimal chance of ranking.
There are edge cases to this, particularly when you have an extremely strong domain that can hold up on its own, however, for the majority of the sites they will not be able to effectively use this content at all.
Programmatic Rules
Creating rules for the pages will significantly help a dynamic system in ranking. Rules can help stipulate what gets pages ‘created’ by limiting what content you’re linking to.
Setting up these rules will greatly benefit crawling performance as you basically say whether a page ‘exists’ or not. When it ‘exists’, you include it in the sitemap, along with internal links. This basically hides the lower value pages away in a dark hole, since you don’t want them found by the crawlers.
0-result SRPs Rule
One of the main rules I work with my clients on setting up is a 0 results rules. Google often flags 0 result pages as soft-404s, as it can somewhat understand that the page may as well be a 404 as the results are ‘not found’. When a search page returns 0 results, it should be excluded from sitemaps and links, ensuring that we don’t waste value & crawl budget on URLs that are returning ‘no results found’ type text. Google will often even flag these as soft 404 errors.
Variable-match rules
Another rule you could create would be one that only ‘creates’ pages when the variable matches one from a list. You could have say 20 property types, but maybe 5 of them are super close matches, or crossovers, of the other property types. By using a match rule like this, you could get the developers to exclude some property types from the pretty URL and instead just used them as a query parameter.
Variable to Pretty-URL Rules
Following on from choosing which variables you want to optimise for, you could set up a rule that only creates optimised pretty URLs for specific variables. ie you could create one of the property type & location variables, but not create it for bedrooms, bathrooms & filters, and instead just use a query parameter for those filters. That would ensure the user experience isn’t impacted, along with ensuring that you can cleanly cut off the lower-value filters with a canonical tag.
Graceful Fallbacks
Graceful fallbacks are used to best help you bulk optimise, but not completely stuff over the remaining 20% that may not benefit from a change you want to make.
They’re essentially just a catchall rule that is only used when another rule won’t work. It’s for the edge cases.
An easy example is a result count sentence. On an SRP you could have the text ‘We have 10 properties that match your search.”
That’s all well and good until you don’t have any. You should avoid just saying “We have 0 properties that match your search.”
It’s bland and offers both 0 value to users (… and Google).
But, a fallback could be added that was something along the lines of “We currently have no properties matching your search, but here are some highly similar properties” with either some listings included below, or a link out to related listings.
The fallback just allows you to catch that edge case, and make it a little cleaner by either optimising the content a bit, or just lining out to somewhere more appropriate for the user.
I follow a “use what you’ve got” SEO methodology.
Even if 10% of your content has a specific element you can optimise for, why limit that 10% by not using it? – other than the added time it can take of course :)
Just get a rule going to use it, and then use a fallback to catch & handle the other 90%. Takes time once you get to this level, but it’s well worth it to ensure continued growth.
The best thing about it is that even if say 90% need that fallback initially, as the site grows maybe it’s only 80% in a month, then 70, 60, etc. Once your rules are set up, they’ll live there forever.
Internal linking for Dynamic SEO
When optimising a dynamic site, you should really place an emphasis on a good internal linking structure. Between helping to set up a site’s hierarchy, and passing link value around the site in a more prioritised way, internal links can truly work wonders.
I wrote a bit more about my specific internal linking strategies here but the crux of it is; link through the hierarchy. Yes, links can help you prioritise pages and pass value around the site. But, at the core of any good dynamic site is the internal linking through the hiarchy. Start at the parent pages, and work your way down through the children.
Cross-link between page types when it makes sense.
Only once you’ve done the core linking strategy like that, should you look at a more individualised linking strategy that will help the key pages that may be a little deeper within the site.
Ideally, you do both at once. But ensuring efficient indexing of your setup should be a higher priority than prioritising a handful of pages in the beginning.
Finally, with linking, avoid linking to 0 value pages. This sort of setup can be built to automatically link to new pages as they get enough content to be considered a ‘page’. New content posted on the business, means new pages being created. These new pages being ‘created’ means these systems can automatically grow as the business grows.
Dynamic content generation
Ideally, you have a manually crafted piece of content for each page. When you have 10,000+ pages with a dynamic setup, that isn’t always possible.
This is where dynamic systems can shine, and a lot of websites aren’t leveraging their dynamic site to their full potential.
Using whatever variables you have that relate to a page, you could generate a dynamic piece of content to use.
One of the best examples of this is the many travel comparison websites.
ie on https://www.booking.com/city/au/sydney.en-gb.html you’ll find expandable FAQs down the bottom.
One of them is
“How much does it cost to stay in a hotel in Sydney?”
which is essentially just
“How much does it cost to stay in a hotel in <location>?”
They give an answer of:
On average, 3-star hotels in Sydney cost AUD 273 per night, and 4-star hotels in Sydney are AUD 388 per night. If you’re looking for something really special, a 5-star hotel in Sydney can on average be found for AUD 568 per night (based on Booking.com prices).
That piece of text, could be broken down into a template like;
On average, 3-star <propertyType> in <location> cost <currency> <3starAverageCost> per night, and 4-star <propertyType> in <location> are <currency> <4starAverageCost> per night. If you’re looking for something really special, a <propertyType> in <location> can on average be found for <currency> <5starAverageCost> per night (based on Booking.com prices).
There would then be rules added, that if there were no 5 star hotels in that location, then just not include that sentence. So maybe there would only be 4 star hotels in a city, then only that sentence would be added.
Just don’t forget though, you could always override this dynamic text section with a manually written section when it makes sense. So maybe your top 1% pages get ‘upgraded’. Another strategy here is to use the dynamic text to kick things off, and then as pages start to gain some traction you upgrade them with manual content.
You essentially let your users decide on the content to upgrade, and to, if all goes well, continually grow a specific page.
If you’re just starting, my dynamic content generation Google Sheets template might help.
Expanding dynamic content generation with spintax
Taking the dynamic content generation to the next level, you could also add in variations so that each version of this is a little bit more separate from the last. Essentially just a great new use for spintax.
So instead of just the single version of;
On average, 3-star <propertyType> in <location> cost <currency> <3starAverageCost> per night
You could work in the variation of;
<location> 3-star <propertyType> have an average cost per night of <currency> <3starAverageCost>.
Spintax obviously doesn’t work the wonders that it did back in 2010, but the layer of the dynamic variables within text changes things up a little bit. When you’ve got 10,000+ pages using a rather similar sentence too, mixing things up a little bit certainly can’t hurt!
However, there’s a pretty big caveat here. If you do something like this you definitely need to make sure that the text isn’t being regenerated each time the page is built. It should generate the template once-off, and then only dynamically update the variables on page build. Chunks of robotic-ish text that completely refresh each time Googlebot visits might be a nice little red flag for them.
Adding a ‘manual’ page element to dynamic builds
A programmatic SEO build doesn’t need to be 100% dynamically generated pages. You can add a more manual layer into the mix.
I lean towards calling these more ‘custom’ pages, and are essentially there to catch the leftovers that a dynamic build can’t efficiently catch.
Using the pricing filter as an example, not every price needs a clean URL.
However, top cities could benefit from having an under 300k, under 500k, under 1mil type page. So maybe 5 pages, across maybe 10 cities.
Yeah, you could work some rules into it to curtail the page creation to just what you want.
However, sometimes it might be easier to literally list out the 50 pages, and then have some sort of page filter rule to limit the content to what you want.
In this case, it could be;
Houses under 500k in Melbourne
With filters of;
propertyType = house
price < 500000
location = Melbourne (or alternatively, ‘location CONTAINS melbourne’, depending on your setup & variables)
This sort of setup would also allow the creation of pages like ‘Beachside houses in Melbourne’ if you have some sort of property feature of ‘beachside’. You might not want that created for everything, so this could be the way to maintain some flexibility.
Optimising search verse creating separate landing pages
One of the options that have come up with a couple of clients for me now, is whether we try and optimise their existing search, or create a separate landing page style setup.
Both have their own merits, with the landing page setup being great due to an easier ability to limit content should you have some sort of gating/membership type setup.
Optimising an existing search can also need a few tweaks to things like dropdown filters. A good old fashion text link has always worked the best for crawling, so additional links need to be added to make things work properly. Whereas a separate build could be a bit less ‘design-heavy’, and more focussed on initial users to get them into the system.
It really depends on tech capability too, as a simpler landing page system may be the way to go to effectively build out an MVP. You can then get it to market, and see how it performs before a larger investment can be made.
Common Dynamic SEO Mistakes
The joys of a dynamic system are that one tweak can affect all pages. It’s not hard to optimise, in bulk, so you don’t really need to hold them back too much before launching with a skeleton.
However, there are some mistakes to keep in mind with these systems.
Over-creating indexable pretty-URLs
This is by far the worst thing that can happen with a programmatic site build. Allowing variables to create pretty URLs that really shouldn’t be, leading to 10s or even 100s of thousands of pages being crawlable, and found, by Google that have minimal to nil value.
This can be avoided primarily via controlling what variables get pretty URLs, and what variables stick to parameters. This is due to query parameters being a little easier to control crawling of.
Over-indexation of query parameter URLs
Whilst these won’t tend to be linked to, query parameter URLs can still cause over-indexation issues. One of the main issues I have seen cause this, is that once one URL contains a query parameter filter, the rest of the URLs on that page may also contain the parameter to maintain similar results from a UX point of view.
At a minimum, non-pretty variables should be stripped from the URL with a canonical tag. That should limit the amount that are getting indexed, but minimising / completely avoiding links through to query parameter results will stop this issue at the root.
Letting crawlers run wild
Even if you’ve significantly culled the number of variables creating indexable URLs, linking through to them all can still create major over-indexing issues. Say you’ve got a variable of location, with 10,000 locations in there. Maybe only 1,000 of those locations are actually valuable enough, or even have content.
So whilst a ‘pretty’ URL may be created for all 10,000, it technically won’t exist to Google unless it’s linked to.
Ensuring you have proper rules set up on all linking widgets will help limit what is crawled, which will then obviously limit what gets indexed. This goes the same for any XML sitemaps you have. Exclude anything you’re deeming as ‘lower value’.
If you’ve run into this issue already, and are looking for a fix, 301 redirecting or 404/410ing the URLs have been the only way I have seen it efficiently patched. No canonical hack, or other trick, seems to work.
Forgetting to establish a hierarchy
“But a flat architecture works best”. For a 100-page content site, maybe! For a 1,000+ page website, you need to establish a hierarchy via a site structure.
It best passes value around the site, appropriately prioritises URLs, sets the clear parent/child relationship between URLs that share content, and helps crawlability.
This could be via URL structures and/or breadcrumbs, along with a hierarchical interlinking system with footer/sidebar links.
The hierarchy is helpful for crawling, but extremely helpful in establishing whats what on the website, and what page is essentially a ‘filtered’ version of another page.
If you’ve got property type URLs like ‘apartments for sale in Sydney’ you really need this linked to ‘sydney real estate’ in the hierarchy. The filtered apartments page will already be using content found on the generic real estate page, so clearly showing that this page sits below the generic one will help Google understand the relationship between them.
Yeah, it probably can without setting a clear hierarchy. But why make things more difficult for Google? Make their life easy, and maybe they’ll make yours easy.
Not thoroughly understanding the variables at play
When you’re working with dynamic elements, they heavily rely on the actual data within the system, If this isn’t heavily vetted, or understood, you could be created content or filters that could be led stray by the data.
A simple one here is words that are plurals v singular. If you have property types that some are plurals, and some are singular, your content sentence that uses these variables won’t make sense.
Find an apartment for sale in Sydney
Find an apartments for sale in Sydney
That one little letter throws it all off, so you really need to know all datapoints of a variable to be able to work with them.
Same goes for formatting, where if some cells have a dollar sign $ and others don’t, you need to try and standarise it.
Another example is when a datapoint could contain multiple options. So for the property types, a data point could be like ‘apartments, land’ rather than the property types individually.
So you’d need to account for this by splitting them, otherwise you may end up with additional unexpected pages and/or weird wording within the content.
Programmatic SEO Examples
Zapier
Without a doubt one of my favourite programmatic examples as it’s a non-standard setup.
Firstly, have a read of this post by Ryan on zapier’s SEO strategy.
The post is great, but the following point is a bit off:
But Zapier recognized the SEO value of each page having unique, relevant content.
Yeah, they recognized it. Just not from the start. Their growth exploded well before they took on the strategy he talks about to expand their unique content.
In it’s early days, Zapier really just did bare-bones pages. They used what they had, which was written purely for users.
Their original system looked like this;
Source: Wayback Machine 2012
Each specific zap has a single sentence, with the entire page’s content just being made up of these zap-specific sentences. Nothing else added.
They’ve then come in and done their first big upgrade, which included both the design, along with page-specific content & content about overall zapier.
Source: Wayback Machine 2017
This upgrade was when they really started leveraging templated dynamic text, using the variable of the software’s name.
They then upgraded a couple years later, with additional zap content being loaded in.
Source: Wayback Machine 2019
A similar transformation was seen on their more specific zap pages, where you can see the content evolve a bit more.
Early version:
Source: Wayback Machine 2014
How it’s going:
Source: Live 2022
Unfortunately can’t find a super original version of the zap pages, as it seems wayback only holds about 2014ish onwards, but even from the 2014 version we can see how basic their original zap pages were.
Whilst Zapier has improved their offering as time has passed, its crucial to remember where it began for them. They’re a great example of starting with whatever you can, and improving it along the way.
Porch.com
You’ve probably never heard of these guys and yet they’re one of my favourite examples of a true rules-based programmatic SEO builds.
Well, at least they used to be. Just looked at them whilst writing this up, and they’re taking a little dive. So, why not just break out a few of the things they’re doing.
Doubt it’s actually the cause, but hey, you never know!
The last great example of the porch.com I knew was from November 2020 here.
Why do I say that? Well, they had one key element:
This hideous but sexy thing provides deep links to their key category pages.
They’ve still got the header menu, but that was always there too. They just don’t seem to have the same effect that I’ve seen from these raw link widgets.
Digging into their specific category/location pages, we can see a mild but also clear difference between older and newer versions of their page.
Comparing this version to the live one here.
They’ve decreased quantities of content within each of the widgets.
Instead of 25 electricians being shown, it’s now 10.
Instead of 20 reviews, it’s 9. (however some other pages look like they have more…)
Instead of 15 ‘more electricians’ it’s 8. (again, possibly more so not sure what they’re doing here)
They’ve also updated their linking widget from the below;
To become;
They’ve essentially updated this from being highly relevant links for either the category or location, to being somewhat related by child-location types. But since these child-locations go to other categories, like plumbers, that it throws any related value out the window and just becomes a random link in Google’s eyes.
Same category, or location. These types of links shouldn’t be mixed with child locations & different categories.
Whilst there are still some extra sidebar links, these sorts of highly relevant to not-as-relevant change could impact things.
Could this be what is impacting them? Possibly, but again, these are pretty mild changes. Combined with other changes they’ve made they could all be adding up, and I’d certainly be recommending a few patches to them to try and revert a couple of items to see if they can re-acquire their former glory.
Gumtree.com
Gumtree is a staple in Australia for buying stuff, but I prefer the .com setup over the .com.au version.
Gumtree has gone the route of optimising their standard search, and has a mix of a great setup, with a slightly too loose keyword targeting strategy.
But hey, it’s working for them so who’s to judge.
Their setup starts with their homepage linking widget. With popular searches first, and popular locations second.
Clicking through to one of their cars section pages here, we can see what they’re doing with a car model page.
There are two main widgets here that really stand out for their build.
The first is their dynamic content widget;
They’re using all the magical dynamic words in there to try and pad the content, and not make it sound programmatically generated.
A similar widget is generated for pretty much every other car page too, when there’s enough content. Some widgets have less sections, so they’ve got some rules to limit what’s being used.
If we compare this content side-by-side with completely separate page we can see;
You’ll see that the questions and answers pretty much exactly match. They do seem to either rotate through questions and answer templates, with both examples have the same question, yet different answers. They then have separate questions for #2 and yet have the same answer.
Looking at once in particular, “What is the average mileage on <model> cars?”
We can see two templates they’re using;
On Gumtree, <model> cars have an average of <averageMiles> miles on the clock. To give you a guide on pricing, you can expect to pay around <averagePrice> for an average <model> on our site.
The average mileage on <model> cars is <averageMiles> miles. On Gumtree, you can expect a <model> to currently sell for around <averagePrice> on average, and the most popular years for these models are <popularYear1> and <popularYear2>.
Very similar responses, with the second one even getting a little extra added with the popular years. However, it does seem that it’s a two-sentence format, with the first being the actual miles, and the second being pricing. The popular years could just be included in that particular popular years text template. It could just be that they’re tacking an extra sentence into each section to try and pad the content a little.
They even manage to sneak some internal links into these sections, but there definitely seems a rule to it. They either aren’t able to correctly match, or just don’t, like to every variation that is mentioned within the widget. ie for colour, they link to grey, black and white, but don’t like through to yellow or green. Both seem to have enough results, so who knows.
The other widget that stands out is there footer linking widget;
All of the ‘top searches’ are highly related to the current page. Whether direct children, or similar models, they’ve done a great job of keeping these links to somewhat tight knife groups.
They seem to be pulling in top searches that fit into the matched hierarchy for the page, being the current page, parent pages, and then other children of the parent pages.
Then the ‘top locations’ tab of this widget links through to the other ‘country’ versions of this current page.
Not every page has these links, so they’ve got something setup that determines whether a page has this shown or not. It also just seems to be a handful of top locations, mixing cities/countries, rather than a proper hierarchical linking setup.
If you also go to the wales version of this page here you can see that the ‘top searches’ widget is now hidden behind an expander, and becomes very broad:
So it seems if they either can’t match it correctly, or just don’t have enough ‘sub’ results they default to a more country-wide link widget and then hide it under an expander.
One shortcut they’ve taken though, is using query parameters for all sidebar text links. Even though they’ve got an accessible ‘pretty’ URL in there system, a query parameter version still gets linked to from the sidebar.
So even though
https://www.gumtree.com/cars/uk/mercedes-benz/a-class/black
exists, the ‘black’ selector from the sidebar will link through to;
https://www.gumtree.com/cars/uk/mercedes-benz/a-class?vehicle_colour=black
This would definitely be impacting crawling, and potentially causing them issues, but they’re Gumtree. This stuff can pass pretty easily for them.
If you’re looking to jump into a contested market, you should definitely try and avoid a situation like this. It certainly won’t help you.
I tend to recommend that clients should link to the pretty URL version of a page all the time, to avoid these issues.
At minimum, when only a single parameter exists and it has a pretty URL, it should be redirected to that pretty URL, but even that still doubles crawling for what could be seen as key pages.
It becomes a little messy, and highly modified on a case-by-case basis, when a multi-select filter is at play where multiple options can be chosen.
They’re less likely to cause as many issues, as they tend to not be linked to as much as single option filters.
Wrapping it up
Programmatic SEO builds can come in all shapes and sizes, but they’re all coming back to one thing at their core – leveraging data.
You need to change how you think about SEO, to be able to work with these types of sites.
You can’t just deliver 10,000-page titles in a spreadsheet for a dev team to implement. But hey, I’m sure we’ve all tried!
Once you get over the initial step in thinking, you will realise how the large sites develop and grow their strategy.
