Wordpress Archives | Page 13 of 18 | Magento Hosting

CAll Us: +1 888-999-8231 Submit Ticket

Choosing A React Alternative For Your WordPress Themes And Plugins

Photo by qimono on Pixabay

Matt Mullenweg recently announced that the WordPress project will no longer use the phenomenally popular React framework in its projects. React was being used to build the forthcoming Gutenberg editor, which will now have to be rewritten.

WordPress theme and plugin developers don’t have to follow the lead of the WordPress project. They can use whichever front-end technology they like to interact with the WordPress REST API, but if you are embarking on a new WordPress plugin or theme, it’s worth knowing about the alternatives — and there are a lot of alternatives.

If you’re interested in why WordPress is moving away from React, I discussed the nitty-gritty in an earlier post, so I won’t go into detail here. Suffice it to say that Facebook, which develops React, releases the code under a license that doesn’t sit well with many open source developers.

I’ll have a look at three alternatives to React later in this post, but the way we choose a framework is at least as interesting as the framework we choose. I’ll suggest three principles that might be useful to you:

Choose a framework your developer already knows.
Choose a framework the community is invested in.
Unless you have a compelling reason to move away from React, don’t.

The goal is to build things. Any of the major contenders in this space is adequate to that task. If you or the developer you hire is already familiar with a framework, there’s no real reason to switch (unless it’s so obscure you won’t be able to find anyone to maintain the code).

At the time of writing, the WordPress community hadn’t settled on a React alternative. When it does, developers will start pumping out code. They’ll ask and answer questions on Stack Exchange and WordPress developer forums. They’ll write demo themes and plugins. In short, whichever framework the community decides on is a good bet for developers.

If you have already invested in writing lots of React code for your project, think long and hard before you decide to move to a different framework or library. React is awesome: that’s why it’s so popular. Some organizations, including WordPress, have specific problems with the license. If you don’t think those problems are relevant to you, there’s no real need to change.

So, what are the alternatives to React? It really depends what you mean by “alternatives”. React uses the Virtual Dom, it mixes CSS and HTML with Javascript, and it’s a view framework, not a full MVC like some of the competition. Other front-end frameworks make different choices. Depending on your needs, you might choose from Vue, Preact, Angular, Mithril, Aurelia, Glimmer, Elm, and many more.

I’m not a betting man, but Vue is by far the most popular of the React alternatives, and it would be an obvious choice. Indeed, it seems that the WordPress folks have been in conversation with Vue’s developers. The transition from React to Vue may not be smooth sailing because the underlying principles are different (no JSX-type shenanigans), but Vue is a solid choice.

Preact is a lightweight alternative to React that, unlike Vue, uses the same API. It’s very easy to transition from React to Preact, and there is a compatibility layer that allows developers to use React code with the Preact framework. If you’re looking for a direct replacement for React, you won’t go far wrong with Preact.

Finally, Elm is a completely different kettle of fish — it’s not even Javascript. Elm is a functional programming language for building web applications that compiles to Javascript. If that sounds interesting, check out this proof-of-concept WordPress theme from Jack Lenox.

Posted in:
Webmaster, WordPress

Source link

WordPress Publishers Fail To Follow FTC Native Advertising Rules

Photo by Aaron Burden on Unsplash

Traditional display advertising is set apart from editorial content. They exist on the same page, but in different worlds. In the editorial world, the measure of content is creative, factual, and reader-focused, untainted by financial considerations. In the realm of advertising, it’s all about the bottom line.

Of course, this is a fiction — although a useful fiction and an ideal to aim for. The wall between editorial and advertising has always leaked, but it’s never been more leaky than with native advertising.

Native advertising is presented within the flow of editorial content. It takes the form of editorial content. It adheres to some editorial conventions. But that’s where native advertising’s similarity to editorial content ends. Native advertising is bought and paid for; its motivations are to sell and promote. But without a clear and unambiguous signal that editorial standards of independence don’t apply to this bit of screen real estate, it’s easy to mislead the reader.

The FTC has clear guidelines about how native advertising should be distinguished from editorial content. The need for these rules is clear, especially in the blogging world, which hasn’t yet developed the traditions that cause journalists to recoil at the idea that advertising might taint editorial independence.

Unfortunately, many bloggers, new media publishers, and advertisers are unaware of the rules. It’s all too common to find native advertising without any indication that the content is paid for. This isn’t just an issue of reader confusion: the FTC has been proactive about charging publishers and advertisers that publish misleading content. Bloggers who don’t want to find themselves in legal trouble should take the time to learn how to distinguish promotional content from editorial content clearly and unambiguously.

The FTC has published a blogger and publisher friendly version of the rules, which are quite simple. Promotional content should be clearly marked as “Sponsored” or “Promoted”. The exact language is less important than that it is unambiguous and difficult-to-miss.

The notice should be placed close to the content, not behind a link, in the footer of the page, or anywhere that it would be easy for the reader to miss. Ideally, it should be above the headline of the content on both index and post pages. It should be large enough to stand out, and have sufficient contrast that it doesn’t blend into the rest of the content.

Given the prevalence of ad-blockers and declining revenue of traditional display advertising, native advertising has become a major revenue-generator for publishers. Some of the biggest media success stories of recent years, including BuzzFeed, generate all their revenue with native advertising. It’s a monetization technique well-worth exploring for any content business, but care should be taken not to mislead readers.

Posted in:
WordPress

Source link

What Is An API?

Photo by pawel blazewicz on Unsplash

The biggest buzz in the WordPress world is the REST API and how it will usher in a new age of freedom, flexibility, and functionality for WordPress users and developers. But the term “REST API” doesn’t mean much to anyone who isn’t a web developer, including most WordPress users. To help WordPress users understand why the REST API is a big deal for the WordPress community, I’d like to take a look at exactly what we mean by API.

First things first, API stands for Application Programming Interface. Knowing that isn’t particularly helpful unless you already know what an API is, so we’ll move swiftly on.

We’re all familiar with applications. Take a look at your phone’s home screen. It’s full of applications. Each application is a self-contained chunk of functionality. A weather application tells you what the weather will be. Your email applications lets you read email.

How does your weather application “know” what the weather will be? In most cases, the application asks a weather service on the internet, which returns the information the app needs to display a forecast. The weather application needs to know exactly what to say to the weather service to get it to send the right information. The weather service will only answer a small set of correctly formatted requests for information.

There’s a sort of contract between the weather app and the weather service: the weather app will respond with information in a format the app can understand if the app makes requests in a format the service can understand. That contract and format is an API.

In short, an API specifies how one piece of software should talk to another, and what responses it can expect. Neither piece of software cares what’s happening inside the other (the implementation). They don’t have to understand each other’s code. As long as the API remains stable, they can communicate.

The WordPress REST API specifies how other software should talk to WordPress and what WordPress will do in response to those requests. An application might use the API to ask WordPress to send a list of blog posts, and WordPress would respond with the blog posts in a format the app can understand.

You can see how useful this is for developers. Before the API, if a developer wanted to build a theme that displays blog posts, they’d have to write code that interfaces with WordPress’ internal code. With the REST API, any application that knows the API can interact with a WordPress site. A theme or front-end app, written in JavaScript or any other language, can ask a WordPress site for content or tell it to perform certain actions, like publishing a post.

The “REST” part of REST API denotes how the API should be interacted with — in the case of REST, requests are sent over HTTP. Each request is a specially formatted web address that WordPress knows how to respond to. REST implies other things too. If you want to deeper understanding of REST APIs, which are used all over the web, take a look at this excellent video.

The WordPress REST API is a standard interface that lets developers write software to use of all the content and user management functionality WordPress provides. Developers can create new themes, plugins, front-ends, back-ends, and applications that use the API, creating exciting opportunities to make the WordPress ecosystems even richer than it is already.

Posted in:
Webmaster, WordPress

Source link

Why Do Spammers Attack WordPress Sites?

Photo by Ricardo Viana on Unsplash

A WordPress site with web-facing forms will be spammed. If there’s a form to be filled in, it will be filled in by spammers, even when there is no clear motivation for doing so. Spammers register for membership of any site they find, they fill in forms for gated content, they submit fake email addresses that clutter mailing lists, they take surveys, and they bombard comment forms with gibberish and SEO spam.

Spam is more than an annoyance: it skews the data web-based businesses have available to them, lands the site’s domain on email blacklists when it sends mail to people who didn’t sign up, presents a security risk, consumes hosting resources, and makes a mess. All of which takes time and money to deal with.

I’ve discussed spam registrations and random form-filling with many WordPress users, and a common question is why do spammers do it? What benefit does the spammer get from signing up to a membership site or submitting fake addresses to a mailing list? It’s hard to work out from the point of view of site owners because often there is no real benefit to the spammers.

WordPress spammers hope to find sites that let them send spam emails, submit spam comments, publish spam posts, or to join the site as a prelude to a deeper attack. All of this web form spamming is automated. Simple bots scour the web for forms to fill in. It’s not difficult to automate the filling in of web forms: the bots are unsophisticated and the spammers aren’t skilled developers. Because bandwidth is cheap, it’s easier to spam every form than it is to be selective. So, if a form has an email field, they’ll put an email in it, a name field gets a name, and so on.

In many cases, WordPress sites are spammed as a side effect. If the site is properly secured, the spammers don’t gain anything, but they don’t lose anything either, and in the morally challenged mind of the spammer, that means building more sophisticated bots isn’t worth the effort.

All of which is interesting, but it doesn’t help WordPress site owners handle spam. The only way to stop spam data reaching databases is to implement systems that can distinguish between authentic submissions and junk — preferably without asking users to jump through hoops to demonstrate their status as a human being.

The best way to filter out spam today is Google’s most recent iteration of reCaptcha: Invisible reCaptcha. Old versions of reCaptcha asked users to carry out vision-based tasks that were easy for humans and difficult for machines. This system annoyed users and is based on an outdated assumption: in 2017, sophisticated machine vision is accessible, accurate, and inexpensive. Invisible reCaptcha uses a mixture of on-page behavior and data analysis to automatically categorize visitors as bots or humans in a way that is largely transparent to users. If you’re having WordPress spam problems, take a look at the Invisible reCaptcha for WordPress plugin.

Posted in:
Security, WordPress

Source link

Are You Using A Staging Server For WordPress Development?

Photo by Andres Moreno

If you run a WordPress site, the following scenario is probably familiar to you. You have what seems like an excellent idea for a change to your site. You log in to the administration dashboard, make some changes, and everything looks good. Then you refresh your site’s homepage to find that instead of the elegantly-designed fast-loading front-end you’re used to, it either doesn’t load at all or loads something that looks like your server has forgotten how to put a web page together.

There’s always a risk of something going wrong when you make changes to a live site. WordPress installations are complex systems with many interacting parts, and it’s hard to predict how a change in one area will affect everything else. Avoiding situations like the one above is why you should consider deploying a staging server.

Why do you need a staging server?

Any time you make a change to a complex system, there’s a chance of unforeseen errors. For WordPress that might be upgrading, installing plugins, making tweaks to themes, changing settings, editing the database, and so on. Ideally, you’d be able to test everything you do on an identical replica of your site, so you can catch any potential disasters before they go live.

Creating a WordPress staging server

Identically replicating a hosting environment and WordPress installation, and syncing changes between the staging server and the production environment can be fraught with complexity, but there are plugins that will make the process more straightforward.

VersionPress

VersionPress, as we’ve discussed before, is a plugin that allows WordPress site owners to version control their sites. Under-the-hood, VersionPress uses Git, the version control system of choice for open source software development.

If you’re not familiar with version control, it’s a technique of storing every change that’s made to a piece of software. Storing changes in this way gives VC users a number of useful capabilities: changes can be rolled back to earlier versions, and, most importantly in the context of staging sites, different sets of changes can be merged together.

With VersionPress, it’s possible to create a copy of the live site to use as a staging or development site, make changes to both the live site and the staging site, and then merge the changes from the staging site back into the live site without losing changes made to either site.

WP Stagecoach

WP Stagecoach is a premium plugin that aims to make it incredibly easy to create a staging site and then merge the changes back into the main site. This plugin is not quite as feature rich as VersionPress, but it isn’t intended to be a full scale version control system. It does one thing and does it very well.

WP Stagecoach will create a staging copy of your site, which can be password protected so that casual web browsers don’t stumble across it. What’s particularly good about WP Stagecoach is that it will allow you to copy changes on the staging server to your live production server. So, if you make a change to the staging installation that you want to push into production, it’s very straightforward. It allows you to choose which changes you import, and you can revert changes if things go awry.

A staging server or installation is an essential tool for anyone serious about publishing or selling on WordPress, and hopefully with the help of these plugins, you’ll have no reason not to use one.

Posted in:
WordPress

Source link

Find Out How Your WordPress Plugin Is Used With Wisdom

05 September 2017
by: admin
in: Content,Uncategorized,Webmaster,Wordpress
note: no comments

Photo by Luca Bravo on Unsplash

A few weeks ago we, wrote about a proposal to add data collection facilities to WordPress. The proposal was rejected, but that doesn’t mean the points it made weren’t valid. Collecting data about real-world software use can be valuable to developers. Wisdom is a premium WordPress plugin that allows plugin developers to collect information about how and where their plugin is used.

There’s often a disconnect between software developers and their users. It can be hard for plugin developers — who are WordPress experts — to put themselves in the shoes of the average WordPress user. What seems like a great idea to a developer may get no traction at all with users. Interfaces that seem intuitive to a developer might confuse users. And a developer could waste weeks of time building new features that aren’t used.

Real-world usage data helps developers focus on what matters most to users. But that’s not the only benefit. Armed with detailed information about usage patterns, developers can create user-friendly interfaces that reduce the amount of time they’re required to spend dealing with support requests. For developers with premium plugins or premium tiers, data collected from users can help increase conversions and revenue — if you know what users want, it’s easier to build a business providing features they’ll pay for.

Wisdom makes it easy for developers to collect useful information from sites that install their plugin. Developers simply install a snippet in their plugin files and tracker code on their website. When a plugin user agrees to have their data harvested, the developer will receive a variety of information, including the theme installed on the site, the WordPress version number, and which plugin settings are being used.

The WordPress plugin repository is strict about data collection from users. Plugin developers can’t collect data without getting an opt-in from users. Wisdom includes a two-part opt-in process. Firstly, users can opt in to having general usage data collected. Secondly, they can agree to have their email address collected. Email collection can be useful to developers, but users are often rightly wary of allowing emails to be transmitted to a third-party. Wisdom allows developers to deactivate the email collection opt-in altogether.

If you aren’t using the WordPress plugin repository, it’s possible to disable the opt-in altogether, but I’d advise plugin developers to be open about data collection.

Wisdom isn’t inexpensive, and the range of data it can collect isn’t as a rich as many full-blown analytics solutions, but it’s worth consideration if you want to know more about how your plugin is being used and make evidence-based decisions about future development.

Posted in:
Content, Webmaster, WordPress

Source link

How Two-Factor Authentication Can Help Keep Your WordPress Site Safe

Image by RLJ Photography NYC

There are lots of hacked WordPress sites on the web. Hacked sites are often the victims of botnets that brute force the login process, trying lots of different combinations of usernames and passwords until they hit one that lets them in. After they have access they can plant malware or other undesirable content on a site.

The success of this sort of attack has almost nothing to do with the security of WordPress itself and everything to do with the behavior of WordPress users. In principle, username and password combinations are a very safe way of securing a site. In practice, people don’t understand how to use passwords properly and value convenience over security. If they can get away with having “pa55word” or an equally guessable combination as their password, many will.

We can rail against this sort of complacency all we like, but as responsible site owners we just have to accept lax password security as a part of the landscape. Education helps, but not much; we need to implement other mechanisms for ensuring that our sites don’t fall when the botnets come knocking.

Usernames and passwords work because the number of possible combinations is enormous. For a sufficiently long, complex, and random password, it would take even the most powerful computer many years to hit on the right combination. For a sufficiently simple password, it can take fractions of a second. If users aren’t willing to use random and complex passwords, the solution is to implement another verification mechanism — a second factor – that will ensure the chances of guessing a valid combination remain remote.

There are various ways of implementing two-factor authentication — biometrics such as fingerprinting are one, but that’s more complex to implement than the method I’m about to suggest, one-time passcodes.

Unlike a password, a one-time passcode works for a short amount of time, usually about 30 seconds. The TFA service and the user share a secret — frequently a long string of numbers — which is used in combination with the time to create a unique passcode known to the TFA service and the user without it ever having to be communicated between them. It’s much safer than using passwords alone and because the choice of passcode isn’t up to the user, they can’t circumvent security by using an easily guessable combination.

The typical scenario would go as follows: the user wants to log in to your WordPress site. They enter their username and password, after which they are asked for a further passcode. They will have an application from the TFA service provider installed on their smartphone or a dedicated device, which will generate a passcode that can only be used for a short time. When they enter the passcode correctly, they are logged in.

There are a several good TFA services that integrate well with WordPress, but I’m going to suggest you take a look at two: Duo Security and Authy 2FA.

If you run a multi-user WordPress site, particularly if you have several admin users, implementing two-factor authentication will make it almost impossible for casual brute-force attackers to successfully breach your site. It’s well worth the minimal effort to avoid the risk of becoming a vector for malware or a hacker’s playground.

Posted in:
Security, WordPress

Source link

Which Languages Do You Need To Know?

WordPress is enormously popular and that popularity shows no sign of waning. If you learn how to build themes, plugins, and other integrations, you can tap into a massive market. It’s a competitive market, to be sure, but one that offers opportunities to developers in many different areas: bespoke theme and plugin development, premium theme and plugin development, WordPress management and security services, and, with the introduction of the REST API, the ability to build novel and innovative front-end and back-end integrations that transform WordPress.

You could learn WordPress development as you go, picking up snippets of knowledge here and there as you work to solve problems. But I’d advise prospective WordPress developers to invest some time into understanding the fundamentals of the technologies WordPress is built on. Fundamental knowledge will help you write code and solve problems more efficiently, as well as avoid common security and performance pitfalls.

So, what do you need to know to be a WordPress developer?

HTML and CSS

HTML is the markup language webpages are written in. WordPress uses HTML everywhere: themes are largely written in HTML and WordPress’ most important job is to produce HTML that browsers understand.

While HTML structures documents, CSS dictates how those documents appear on the page. HTML may say “this is a header,” but CSS says what the headers look like.

HTML and CSS are the basic building blocks of all web development. They’re essential to any sort of web development, including WordPress development. There are any number of excellent free resources for learning HTML and CSS on the web, but rather than cobbling knowledge together from tutorials, I’d advise new learners to take a course from Code School or Code Academy, which cover the fundamentals and provide a strong grounding learners can build on.

PHP

Unlike HTML and CSS, PHP is general purpose programming language that can be used to build almost any piece of software. WordPress is a PHP-based application — to develop a deep understanding of how WordPress works, PHP is vital. As programming languages go, PHP is not difficult to learn, but if you have no prior knowledge of programming, you should set aside a few weeks to learn the basics.

To develop themes, you won’t need more than the basics of PHP and an understanding of how it’s used in the WordPress theme architecture, but if your aim is to build plugins and more advanced WordPress integrations, you’ll need a strong grasp of PHP and the APIs that WordPress makes available.

You’ll find no shortage of learning resources for PHP, but I’m going to once again recommend you use Code School or Code Academy, both of which offer excellent PHP tracks.

JavaScript

Web applications like WordPress can be divided into two parts, the code that runs on the server and the code that runs in the web browser. There are many different server-side languages, but, as we’ve discussed, WordPress uses PHP. There is only one language that runs natively in web browsers: JavaScript. JavaScript is used heavily in WordPress themes, so learning JavaScript (or at least JQuery) is essential if you’re to progress as a WordPress developer.

There’s another excellent reason to learn JavaScript: the new WordPress REST API can be accessed with any language, but the JavaScript ecosystem provides many frameworks specifically designed for building interactive front-end interfaces. WordPress’ creator, Matt Mullenweg, has advised WordPress developers to “learn JavaScript, deeply.” In fact, if you have no prior knowledge of coding, I’d advise you start with JavaScript and then move to PHP.

As you might expect, CodeSchool and CodeAcademy have JavaScript tracks, but new learners should check out these resources too:

This might seem a little complicated, but it’s possible to pick up a thorough grounding in the fundamentals you need to get started on WordPress development with a couple of months of dedicated study. Then, as you work on WordPress projects, your knowledge and expertise will deepen. WordPress development offers great opportunities to new developers, and, most importantly, there’s a huge community willing and able to help you and make WordPress development fun.

Posted in:
Content, WordPress

Source link

Why Is It Important That WordPress Is Open Source?

WordPress is open source software. For a project to be called open source it has to fulfill a couple of criteria: the source code must be freely available and it must be licensed in such a way as to ensure that anyone can modify and share and the code.

If you aren’t a developer, your response to that might be, “So what?” The vast majority of WordPress users don’t look at the code and even fewer modify it. To the writers, bloggers, marketers, and businesses that use WordPress sites, coding is an arcane practice a million miles away from their everyday experience of WordPress.

If that’s true, why should WordPress users care that it’s open source? If they never look at the code, does WordPress being open source really matter to them? Why not choose a proprietary publishing platform or site builder like SquareSpace or Medium.

I’d argue that it does matter. In fact, WordPress being open source is vital to every WordPress user, whether they look at and modify the code or not.

WordPress Is Free

Open source advocates might not be happy that I’ve included this as my first reason that open source matters, but it does matter to WordPress users. You can use WordPress for free. There is no license fee. You don’t pay for updates. You’ll never be forced to pay for WordPress’s features.

That doesn’t mean a WordPress site is free: for WordPress to be useful you’ll need to pay for WordPress hosting. But you can freely choose where you host WordPress. You’re not locked into a proprietary platform. It’s simple to take your data and set up a new WordPress site elsewhere. WordPress gives you freedom.

No One Can Take WordPress Away From You

It seems like every week we hear about a proprietary publishing platform that has “pivoted” or been “sunsetted” to the detriment of its users. That’s because these platforms don’t exist for the sake of the publisher or blogger: they exist for the platform’s owners and investors.

They exist to make money for people who aren’t the people who create and publish the content.

WordPress is different. When you download WordPress and install it on a web hosting account, that site exists to meet your needs, whatever they might be. No one will tell you what your site should look like, what you should and shouldn’t publish, and how you should make money.

That won’t change and it’s WordPress’s open source license that ensures it won’t change.

You Can See And Edit The Source Code

Even though most WordPress users will never look at or edit WordPress’s code, it’s important that someone can look at and edit it. On a proprietary platform, only the people who work for the platform’s owners can look at the code. Their motivations are aligned with whomever pays their wages.

If there’s a problem with WordPress, there are millions of PHP developers capable of understanding the problem and raising the alarm. No single developer or organization can warp WordPress to its own interests.

I don’t want to give the impression that there’s something intrinsically wrong with proprietary content management systems — there are several excellent options, including CraftCMS (which isn’t open source, but does offer a free tier and make its code available for scrutiny). The best proprietary content management systems offer many of the same freedoms as WordPress, but the same can’t be said for publishing platforms that tightly integrate hosting and content management system.

Even if you never intend to look at the code of your content management system, its status as an open source project should be part of your decision-making process.

Posted in:
WordPress

Source link

Will Moving To A JavaScript Front-End Hurt Your WordPress Site’s SEO?

When the REST API was first introduced, Matt Mullenweg said WordPress developers should “learn JavaScript, deeply”. The REST API, which recently gained new content endpoints, makes WordPress more than a content management framework: it can now act as the back-end for a huge variety front-end applications and we can expect to see more WordPress themes embracing JavaScript and the API.

In 2017, web apps are par for the course. Many of the pages we see on the web are put together by JavaScript code running in the browser. Modern web apps render most of the content on the front-end or use a hybrid server-side / client-side technique. In time, that’ll be the case for WordPress too, which has many WordPress users wondering if the adoption of JavaScript-based front-ends and themes is going to hurt their SEO — can Googlebot cope?

The short answer is yes; Googlebot can cope perfectly well with JavaScript of the level of complexity involved in most web applications. It will deal with JavaScript-created content just as well as HTML built on the server. There are some limitations, but for the most part, JavaScript doesn’t make Googlebot sweat.

In the past, search engine optimization best practice has encouraged server-side rendering, the strategy used by WordPress. The browser sends a request to the content management system, which gathers up data from the database, executes PHP scripts, and combines the results with templates. The output is HTML that browsers — and search engine crawlers — can handle without a problem.

A few years ago, search engine crawlers weren’t all that great at dealing with JavaScript, and site owners couldn’t guarantee JavaScript that rendered content or handled routing would be executed properly.

Last year, John Mueller, webmaster trends analyst at Google and a frequent poster on SEO issues, published a post on Google Plus that detailed best practices for JavaScript SEO — if developers steer clear of the some of the gotchas mentioned, JavaScript front-ends won’t have a negative impact on SEO. Google is quite capable of indexing content — including title and meta description tags — rendered by JavaScript. Similar advice is also given on Google’s guide to building crawlable web applications.

If you have any doubts about whether a particular theme or front-end app is crawlable and indexable, Google provides a Fetch As Google tool so site owners can see how their site looks to Google.

Finally, engineer Stephan Boyer ran several experiments to test whether Google is capable of executing JavaScript in a number of scenarios, and, although the tests were far from comprehensive, Google passed with flying colors.

JavaScript is a big part of WordPress’ future, and many of the most interesting advancements in the WordPress world will involve JavaScript front-ends and themes. Happily, it appears you shouldn’t let SEO worries prevent you from embracing the future of WordPress wholeheartedly.

Posted in:
Content, WordPress

Source link