Dear Web Developers: A Letter From a Digital Marketer

Cats and dogs. The Hatfields and the McCoys. Soup and forks. Orange juice and toothpaste.

The list of things that have a hard time of working together goes on and on. For anyone who has ever worked on a website as a digital marketer, web developer or a consultant on either side, you know that many times the DM team and the Dev team can have a hard time seeing eye to eye on what issues are priorities, what needs done, what can wait and what just isn’t in the budget.

Well, personally, I’m all about building bridges and whatnot so I have taken it upon myself to write an open letter to all Web Development and IT teams on behalf of digital marketing professionals everywhere.

Marketers, feel free to print this out or email it to the IT department as needed.

You’re welcome.

— -

Dear Web Developers,

We (or, in this case, ME) the undersigned digital marketing professionals would like to inform you of the following five points.

5. Pagespeed insights reports are NOT ‘Busy Work because DM had to Justify their Existence’.

I promise you that Pagespeed insights is not something Google created for digital marketers just to make developers’ lives miserable.

If the tool says your HTML and CSS isn’t minified and suggests you do it, there is a reason behind it.

If we tell you that you need to compress the site images to save like 500 KiB, we’re not just giving you ‘busy work’.

When we say ‘The server response time needs to be less than three seconds’ and you’re thinking, ‘But it’s already at five seconds! What’s the difference?’ I promise you, there’s a difference.

Look, there is almost no reason you should already know this, but in the world of Conversion Rate Optimization and Search Engine Optimization, milliseconds can make the difference in getting ranked, being seen and a page making a sale or an abandoned cart.

Every little tiny bit helps.

We’re not being jerks and trying to give you a ton of work that will take forever (see: AMP compliance) for no good reason and we understand you can’t do every single thing on the list but you need to know that every thing we tell you has a point so please, if you can do it. Do it.

4. We Really DO Need to Implement Schema/OGP/Tracking Pixels, etc.

Yes, we know that code and markup is your thing and we should stay out of it but there are some code snippets that we really need you to handle.

For example, you know what Schema Markup is right? Do you know why its critical that you use the right kind in the right place? I mean, sure, poorly implemented schema usually won’t break your site like busted HTML, CSS or JS would but it sure can tank your site’s search presence and what’s the point of a website if no one finds it?

Whether you want to use the standard Schema markup or JSON-LD, we need you to do something.

We need it. Thanks.

Along with that, our Social Media Marketing friends need things like Facebook Open Graph Protocol, the Facebook Conversion Pixel and the Twitter Conversion Pixel in place on the site.

Also, if they need help uploading the eCommerce product feed to Facebook, you probably should help them. We can’t make Dynamic Product Ads without it. Also, while I’m on the topic of product feeds, if they need help uploading it to Google for shopping or marketplace sites like Amazon, you probably should help them with that too.

Think about it.

When you help them do this, you’re doing yourself a favor too: do you REALLY want marketers messing around with your code and trying to add pixels themselves?

I didn’t think so.

And sure, you can let them try to upload the feeds to third party sites themselves but we both know all they’re going to do is mess it up and then call you for help anyway. You might as well do it right the first time.

3. AMP Compliance Really is a Good Thing

I know. I know. I know.

Look, I taught myself how to code in HTML way back in the HTML 3 days of Angelfire and Geocities websites. We didn’t use Dreamweaver or WYSIWYG editors to make sites. We coded. We sat there and coded page after page by hand so we could be in crappy web rings and make pages full of ‘Stuff I Like’ link spam.

Years later before I got into digital marketing, I did coding for a boss who didn’t believe in Dreamweaver and made us all hard code everything in Notepad++.

Incidentally, this is why I changed career paths and no longer code.

More importantly, believe me when I say that I know being given a task to sit there and code a whole mess of stuff for something that you may feel is pointless is enough to make you want to throw your Fritos and Mountain Dew at the nearest idiot wearing a ‘301 Your Attitude’ T Shirt when they bring up making the whole site, or even part of it, AMP compliant.

Especially when you find out, probably from researching on your own and not from your DM team, that AMP Compliance by itself is not a ranking factor yet.

That being said, we want you to know that Pagespeed, like we discussed before, is a ranking factor. Good content is also a ranking factor. AMP compliance is all about delivering good content at a high speed and therefore, in a very roundabout way, AMP Compliance is a ranking factor.

Is it a pain? Yes.

Will it take forever? Yeah, probably.

Is it worth it? Yes. Absolutely.

Remember: Page load times. That’s what we, and searchers and Google, care about.

2. Clean That Junk Code and Everything Else You Don’t Need Out of There

This should go without saying but you’d be surprised.

I’d personally have thought that you guys would be the first people to want clean, readable code. I mean, you’re the ones that have to go in there and fix stuff and find things and whatnot far more than we do but man oh man, have I seen some nonsense code in my life.

Let me tell you about a client I had once. They were a big retailer with a huge national presence and physical stores in multiple states. They were big enough that if I said the name, you’d probably know them. The problem was that their site didn’t rank for anything.

My colleague at the time took a look a their code for an initial SEO audit and immediately called me over to his desk by saying, ‘You gotta see this.’

Boy, did I ever need to see that.

I had never seen anything like it before. They had so much junk code in their page that literally did nothing. There was, and I’m not making this up, a JavaScript calendar building tutorial that someone copied and pasted in there from some random website.

Yes. A JavaScript tutorial on how to build a CALENDAR was copied and pasted onto their landing page. Not just the code snippet, the full tutorial. Notes and all.

What’s more is that there wasn’t even an actual calendar on their page nor would their business model require one.

I’d like to say that was my only foray into the world of ‘why is this even a thing?’ code and technical errors but that was just one of many.

We had another huge national brand that had a four page long 301 redirect chain that literally had no point and did nothing that they, for some reason, refused to fix.

I could go on and on and on but it always boiled down to the same thing:

All this junk code ended up in there because these companies would go through contractor after contractor and programmer after programmer who saw the previous mess in the page and went ‘pfft…I ain’t messin’ with that!’ and just coded around the crap instead of cleaning the page itself.

Yeah, don’t do that.

All that junk code will slow down your page and, as we discussed before, we need these pages to be as light and fast as possible.

Also, if there is a need for us to go into your code, whether we’re checking the schema markup or just running a standard SEO audit, it would be nice to not see Javascript tutorial templates for calendars that don’t even exist on the site in your code.

Thanks.

1. Sometimes You Gotta Cut Your Losses and Migrate.

I know this is more of a ‘people who make the budgeting decisions’ thing but hey, you guys will be the ones that end up doing the heavy lifting on a site migration so I’m telling you.

Some CMS systems are ancient. Some are just garbage. You know it and I know it.

After reading all of the above points, knowing that dynamically generated pages for eCommerce stores aren’t ideal, having your shop’s product pages controlled by a feed to the point where you cant even put in a meta description (let alone on-page content) is the worst SEO idea ever and realizing that there isn’t a single thing you can do about it because of ‘limitations of the system’, you’ve realized that sometimes its better to just burn the whole thing down and start again.

You’ve also realized that the CMS is base of all your eCommerce operations and if you have a terrible base, you have a terrible site.

We agree with you there.

But then you realized if you do that, that’s going be a super long project with sandboxing and migrating and redirecting URLs and beta testing and everything else that is going to probably take months. Then after the relaunch, you need to go through and debug any problems that might arise on the new site.

Yeah, who really wants to do that when we can just tweak a little here and there and go, “Well, at least the site is better than it used to be!”

Nah, dude. Don’t do that.

As I said last week, ‘better than it used to be’ isn’t good enough.

Sometimes you just have no choice but to move your entire platform to something more modern that can do what we all need it to do. If you’re on a no-name junk platform, dump it. Get with your DM team from the beginning and work together. We’re more than glad to help you plan this out if no other reason than we know that eventually (after the recovery from the inevitable traffic crash that comes with any relaunch, of course) we’ll be able to actually start bringing in quality traffic.

The Bottom Line

I hope my Web Dev friends now understand that we’re not just giving them ‘pointless crap to do that will only increase page speed by like half a second because they need to justify their existence’.

That half second might not be a big deal to you but it really is in the world of CRO and SEO.

IT and DM need to work together far more than they usually do to make sure that everything is going as they should be — also, both teams shouldn’t be afraid of a relaunch.

Will there be a huge loss in traffic and conversions for a few months? Probably. Will there be a ton of work for IT during a relaunch? No doubt. But if you have a failing site, a good relaunch is usually the best thing for both Digital Marketers and the IT team because it keeps people happy and makes them money.

For Digital marketing, more traffic and more conversions means that the suits are happy because the site is making money. It keeps them off their backs. For you it means the page is fast, light and functional. This keeps the digital marketing team off your back.

It’s a win/win.

Take advice from the Smokehouse: If you can’t fix the site due to ‘technical limitations’, just pretend its a mobbed up restaurant that isn’t making money, burn it down and start again clean on a new platform.

Just don’t do it around holidays, your busy time of year — or on a Friday.