עופר איתן Assert: Why Website Builders Can Be Terrible for Your SEO - Jonathan Cartu - Advertisement & Marketing Agency.
16893
post-template-default,single,single-post,postid-16893,single-format-standard,qode-quick-links-1.0,ajax_fade,page_not_loaded,,qode-theme-ver-11.2,qode-theme-bridge,wpb-js-composer js-comp-ver-5.2.1,vc_responsive
 

עופר איתן Assert: Why Website Builders Can Be Terrible for Your SEO

Jeremy Knauff

עופר איתן Assert: Why Website Builders Can Be Terrible for Your SEO

I’m going to make a bold statement:

Page builders are terrible.

Every single one of them.

They offer no SEO advantage.

Ultimately, these WYSIWYG (“What You See Is What You Get”) website builders will severely limit your business growth.

The HTML markup created by any page builder will always be exponentially more bloated than HTML handcrafted by an expert web developer.

The average person may ask “Who cares what the code looks like as long as I have a pretty design in the browser?”

Here’s why it matters…

WYSIWYG?

This is a software application for designing your website where you simply position your text graphic elements where you want them, and the software writes the HTML, PHP, CSS, and JavaScript necessary for it to function.

If you’re not very technical, you might be thinking, “What’s wrong with this, Jeremy? It seems a hell of a lot faster and easier than learning everything I’d need to know to design my own website, and it’s a lot cheaper than hiring an agency.”

If that’s where your head is, you are correct on both counts.

But these website builders are still a terrible choice for any serious, long-term business.

To understand why, let’s first look at the history of WYSIWYG editors, how the online landscape has changed, and what that means for today’s business owners and marketers.

The Path to WYSIWYG

When people first started using browsers to browse online, webpages had to be meticulously coded by hand, typically in a rudimentary text editor like notepad.

No slick interface. No syntax highlighting. Just a white background where you would manually type your code.

I vividly remember walking into a Barnes & Noble in Jacksonville, North Carolina, and buying my first book on HTML. This was 1997.

Back in the day, this was how we acquired new skills because schools were so far behind current technology and we didn’t have the amazing resources online, like Search Engine Journal, Stack Overflow, and CSS Tricks, where we can instantly find the answer to just about anything.

And even if they had existed, search engines weren’t yet advanced enough nor had they indexed enough of the web to help users effectively find them.

So we learned from these gigantic books that were often more than four inches thick and weighed several pounds.

Creating a webpage was a slow and laborious process, but your code was generally clean and efficient.

Of course, everyone wanted to make this process faster and easier.

The process was improved significantly by adding features like syntax highlighting and code completion to old school text editors, but it quickly progressed to the next logical step.

That was when we saw WYSIWYG tools like Microsoft FrontPage and Macromedia Dreamweaver hit the scene. (Macromedia was later bought by Adobe.)

Some web designers stuck with text editors, but more people began migrating to WYSIWYG editors because of their simplicity.

Rather than having to learn and remember hundreds of HTML elements, you could now design a website as easily as creating a slide in PowerPoint.

But that simplicity came at a price.

While the final website may have looked amazing on the front end, the code behind the scenes that powered it was a dumpster fire.

This often resulted in webpages that loaded significantly slower or even displayed or functioned incorrectly in one or more browsers.

Some web designers knew about these limitations and just used WYSIWYG editors to rapidly prototype a webpage before fine-tuning the code by hand.

Unfortunately, most either didn’t know or didn’t care, which meant there were millions of websites online that didn’t work properly.

This was why throughout the 1990s and into the early 2000s, we saw messages on websites stating things like, “This website is best viewed on Internet Explorer at a screen resolution of 800×600 or greater.”

As time went on, browsers advanced rapidly, as did the technology used in websites.

WYSIWYG editors simply couldn’t keep up, and most real web designers began moving back to hand-coding websites.

This enabled them to produce cleaner code that loaded more quickly, displayed properly on all major browsers, and ranked better in search engines.

In recent years, most browsers began to render webpages more consistently.

Predictably, this encouraged a resurgence in WYSIWYG editors because they could now generally produce markup that would render relatively fine in most modern browsers.

Countless options then sprung up.

Pretty much every hosting company offered either a third-party option or their own branded page builder, several companies launched standalone desktop or SAAS versions of page builders while some offered a complete page builder + hosting package, and a plethora of WordPress and Drupal page builder plugins flooded the market.

What’s Wrong With WYSIWYG?

Page Speed

A fast-loading website is critical in creating a positive user experience, and it has a significant impact on:

  • How long visitors stay on your site.
  • How many visitors convert into buyers.
  • How much you pay per click in paid search.
  • Where you rank in organic search.

Those of us who prioritize page speed tend to focus on details like the size of our images, the number of scripts, and ideal media formats, but often overlook the impact HTML markup has on page speed.

In many cases, people don’t even realize that it does have an impact.

Think about it like this – every single byte increases the amount of time it takes a webpage to load. Though they may seem insignificant individually, they add up fast.

And it goes beyond just the size of the HTML file itself.

Each element is treated as an individual node. The more nodes there are, the longer it takes the browser to process and render the page after it’s been downloaded.

The problem is multiplied with nested elements.

Too many nested elements can cause performance to suffer even more because of the additional processing power required to properly render the page.

Page builders achieve a particular layout by inefficiently nesting multiple elements.

And then...

AiroAV

No Comments

Post A Comment