25+ Business Scaling Mistakes Running a Large WordPress Website

Running a successful large WordPress website that generates hundreds of thousands or millions of page views a month comes with its own challenges.

Business owners often become victims of various dangerous mistakes while scaling their online presence leading traffic to a platform that couldn’t handle the volume of users or content published on a regular basis.

Since this guide represents a long-form reference sheet, here’s a table of contents that would help you navigate easier in the complex world of WordPress stability challenges:

WordPress Websites in a Nutshell

WordPress is a wonderful platform which currently powers over 35% of the top 1,000,000 websites. There are tens of thousands of themes and plugins available for blogs, small websites, business portals, magazines, membership platforms, eCommerce stores and everything in between.

Wordpress Plugins

On top of that, there are thousands of tutorials that go through the installation process of WordPress in a few quick steps. Most hosting providers include an automated installer which could set up a new WordPress install within a matter of minutes, including a preselection of beautiful themes and several bundled plugins on top of that.

However, scaling WordPress requires some technical expertise. Spinning off a DIY project of your own or launching a minimum viable product with an off-the-shelf theme and numerous plugins on yet another host may have a massive impact on the performance, stability, and security of your WordPress website.

WordPress is a Content Management System written in PHP and JavaScript, working on top of a MySQL database. The core application requires a web server such as Apache or nginx, running mod_php or php-fpm. This setup is often hosted on a Linux box (with alternatives available on a Microsoft stack with an IIS server).

While a simple website receiving just a few thousand views a month may be stable and reliable long enough, production experience with the full stack is required for scaling large WordPress applications.

The Role of a WordPress Development Company

Unlike non-technical business owners or site builders, professional WordPress developers and WordPress development companies profile in building scalable solutions on top of WordPress.

While business owners may mistakenly see WordPress as software, experienced developers know that WordPress is a powerful application framework that could solve various problems for different business needs.

The difference is that WordPress, as a core CMS platform, includes a good number of features available by default to different audiences. The code base of WordPress is well over 300,000 lines of code partially executed across the different entry points of different requests – such as a front-end template view, an admin dashboard page, or an AJAX call. Along with the newly introduced WordPress REST API and the XML-RPC endpoints used by some services and mobile applications, the platform may be exposed to large traffic spikes or different activities that affect the standard flow of events.

A professional WordPress development company is intimately familiar with the common challenges of scaling a WordPress platform and handling the numerous challenges that occur in different events. Some of those problematic areas may be:

  1. Large volumes of data (hundreds of thousands, millions, or tens of millions of blog posts and various post types)
  2. Active communities of millions of users
  3. Highly functional platforms connecting to various 3rd party services and solutions
  4. Complex websites including dozens of custom-built plugins tailored to the user experience of customers and visitors
  5. eCommerce platforms handling thousands of concurrent users purchasing goods or services simultaneously
  6. Membership platforms streaming data on the fly across various platforms
  7. Extensive landing pages streaming live events handling hundreds of thousands of visitors daily

While this is not an extensive list, it illustrates common scenarios where a WordPress website needs professional development help in order to scale for high traffic.

The Most Common Mistakes While Running a Large WordPress Website

Professional WordPress developers working on high-scale solutions carefully investigate the existing code base and tap into the hosting infrastructure in order to identify areas for improvement. There are various scenarios where WordPress developers may spend time on certain WordPress scalability activities such as:

  • Implementing additional caching layers for a website
  • Refactoring existing plugins or frameworks for security and reliability
  • Offloading data management and processing to third-party services or external servers
  • Decoupling existing solutions to small, independent, and cohesive libraries or micro-applications for reliability
  • Refactoring some database queries in order to reduce the load on the MySQL database
  • Replacing existing plugins with lightweight alternatives that reduce the number of HTTP requests or database calls

Here are some of the most common mistakes reported by WordPress development teams when onboarding large businesses struggling with their existing WordPress websites.

WordPress Themes and Plugins

Common problems related to installing specific WordPress themes or plugins.

1. Bloated Multipurpose WordPress Themes

The Premium WordPress Themes - Misconceptions

Multipurpose WordPress themes or complex premium themes often incorporate several sliders or galleries, introduce dozens of shortcodes, tons of widgets, and various scripts or styles for different purposes.

Complex WordPress themes try to provide a large subset of features for different industries. At the end of the day, business owners leveraging WordPress may utilize a small chunk of the features while inheriting the technical debt and complexity of the large theme. Using just 5% or 10% of the features provided by a premium theme will likely lead to stability issues, performance problems, or even security concerns for business owners.

Solution: Build a custom WordPress theme that is tailored to your business needs. Or use an established starter theme that is extremely lightweight and doesn’t include a ton of 3rd party scripts and styles that would increase the load times by several seconds.

2. Complex Slider Plugins

Some User Experience experts have discussed the usability concerns with sliders but they are still common and widely used across the web. However, sliders are complex components that require a lot of CSS for styling slides across different resolutions and with different effects and captions. All of that is handled through various scripts, some custom back-end logic handling the slide management, and media-related functions for scaling or cropping images on the fly.

Some popular sliders resemble Photoshop and other popular tools by introducing hundreds of different options for slide management. While this is acceptable for some small websites, this often has a massive impact on performance. Moreover, the large code base may lead to major security vulnerabilities as well.

Solution: Avoid large sliders and stick to a simple, custom-made slider whenever possible. Don’t include additional options for resizing images or handling dozens of different formats. Discuss that with your creative team and stick to your brand guidelines and the style guide that provides a limited set of image sizes and placements.

3. Visual Builders

Visual Builders provide non-technical marketers, content writers, and managers the ability to produce dynamic content with flexible layouts. However, many of the existing builders include dozens of available components and introduce a complex framework for handling data within your WordPress pages, posts, or custom post types.

As your WordPress website scales with time, a visual builder may impact the consistency of your data, affect the load times, or introduce regressions while updating your content. Different JavaScript errors introduced due to compatibility issues or ongoing updates may break your pages as well.

Solution: If possible, try to leverage a set of page templates that have a predefined number of sections and boxes for editing content in already defined locations. If a visual builder is a requirement, carefully assess the stability and reliability of the plugin before integrating it within your existing platform. The ongoing maintenance and management of your builder may require additional time and effort on a monthly basis in order to avoid regressions and scalability problems.

4. Multilingual Plugins

Multilingual plugins let website owners create content in several different languages. This is essential for large organizations that want to scare their WordPress websites, serving different audiences across the globe.

However, different multilingual plugins solve various problems. Sometimes, an established plugin may handle a lot more than your web platform needs and affect the rendering cycle of a WordPress page. Moreover, handling multilingual content comes with various considerations when you account for multilingual menus or widgets, right-to-left languages, handling data for terms containing different results per language, displaying product details limited for different regions, handling geolocation and more.

Solution: Carefully discuss the right multilingual solution for your web application with your WordPress development team. Different multilingual plugins implement different strategies on a technical level. Some create additional database tables, others create new post entries for new languages. Some store all versions within the content area and handle it programmatically for each request. WordPress multisite is also a viable alternative for some businesses serving different content to different international audiences.

5. eCommerce Platforms

eCommerce platforms are essential for businesses selling goods or services online. There are various WordPress plugins and 3rd party services available on the market.

While there are no “right or wrong” choices out of the box, eCommerce platforms are extremely complex as they handle product management, orders, deliveries, payments and transactions, user management, shipping, among different options.

Some platforms like Easy Digital Downloads focus only on digital goods. This may be a suitable alternative if you don’t plan on selling physical items as your codebase won’t include all of the features dealing with product weights, quantities, international shipping, and more. However, platforms have developed different communities and add-on ecosystems. A powerful eCommerce store would likely need several additional add-ons in order to bring the right user experience to customers.

Solution: Conduct the right research on the best eCommerce platform for your store. Using a WordPress plugin within your main platform may be a good option if you’re integrating additional features available in your core website. Running a separate shop on a different install may be a viable alternative as well. There are third-party solutions that could be integrated into WordPress as well – depending on your business needs and performance considerations.

6. Membership Platforms

Membership platforms are another large vertical within the WordPress industry itself. There are plenty of ways to monetize a WordPress business and different exclusive access options are available for different plans.

By design, most of the popular membership plugins are large and complex. They have to deal with user management and roles, different payment plans, restricted content of some sort, protected directories and the like. A standard membership platform often relies on a number of 3rd party add-ons and extensions as well.

Solution: Introducing a new membership platform requires plenty of research upfront and deciding on the best option for the business model. There is a tool for every job and that depends on the rest of your WordPress architecture. Work along with your technical and product teams and analyze the roadmap carefully. There are different ways to incorporate a membership, community, LMS platform with a plugin that is suitable for your niche or plays well with other areas of your website – such as WordPress multisite, eCommerce, and the like.

7. Incompatible Plugins Activated Together

The WordPress plugin architecture is pretty solid, powerful, and extensible. That said, each and every plugin can tap into the pool of actions and filters and interfere with the standard WordPress core behavior.

As a result, it’s not uncommon for plugins to compete for the same hook and alter the life cycle in an unexpected manner. That’s especially common for several large and complex plugins active at the same time.

While this is partially something that plugin developers have to work on, there are plenty of realistic scenarios where plugins are implemented as they are supposed to and yet, there are discrepancies in the standard workflow.

Solution: Carefully designing the WordPress architecture is paramount. Avoid installing each and every plugin out there that could extend the feature set of your platform. Review new add-ons, extensions, and plugins together with your technical team. Test carefully and extensively on staging before pushing a new update on production.

WordPress Core Management

Various issues related to misusing the standard life cycle of the WordPress Core and missing some best practices for high-scale websites.

8. Useless Components Affecting the Life Cycle

There are certain plugin features that may impact the load times and interfere with the life cycle. Example being a contact form loading CSS and JavaScript across the entire site (including back-end) while being used in a single Contact Us page.

That may be the case with the WordPress Core itself, too. WordPress performs a certain number of checks or database requests for various purposes. A high-scale website may be affected by the additional back and forth in terms of performance and reliability.

Solution: Set up a vanilla WordPress install and carefully debug all of your main areas (the dashboard, the main front-end pages, some AJAX calls and external requests). Benchmark these as well. Compare that with your production system and see if you can exclude some of those components by removing callback functions, deleting options, and replacing some heavy snippets with lightweight ones.

You may prevent some unnecessary calls by checking for the currently active website language, the usage of comments, or the default generation of standard widgets.

9. Triggering Excessive AJAX Requests

Overusing AJAX may harm the overall user experience and hit the performance setup as well. Review the dynamic layers and see what part of those could be optimized accordingly.

This may be the case with sliders or parallax, galleries, lazy loading, refreshing data on the fly, internal validation or dynamically populated stock quantities in an eCommerce.

Solution: Keep an eye on your AJAX requests. Start a few sessions with anonymous and logged in users and monitor your ongoing requests. Consider a simplification or a better caching mechanism within your wp_ajax_* callback functions. See if a REST API callback would be suitable in some cases, extracting data in a separate data layer, or switching to a more streamlined solution which may be suitable when dealing with more data.

10. Phantom WP-Cron Calls

WordPress has a virtual cron job manager that is meant to execute scheduled jobs. It’s less reliable than a UNIX cron job since it’s dependent on the new requests toward the site (hence may be delayed or skipped in certain events). Moreover, different plugins may populate the pool of cron jobs and slow down your requests accordingly.

Solution: Review your existing scheduled jobs and keep an eye on plugins that may be populating these. In the event of a hiccup with your WP-Cron engine, you may end up with timeouts or even 500 requests due to slow queries or endless requests that can’t be processed for some reason.

11. Connecting to Widely Used Hooks

WordPress provides a large suite of hooks triggered in different parts of the life cycle. Some are isolated and available on specific screens or only when a component is fully loaded. Others are somewhat global and are available on numerous screens across your website – such as the entire admin dashboard or accessible on each and every request made to the website.

While certain components should be available everywhere, that’s not the case for many callbacks.

Solution: Based on your performance and stability reviews, consider excluding certain callback functions or moving them to the corresponding hooks. The WordPress life cycle is complex and it may take a while to identify the best filters or actions to leverage. Keep in mind cron jobs, AJAX callbacks or REST API endpoints. You can execute or dismiss various callbacks in order to optimize different requests across the site loaded from different services and applications.

12. Repetitive Internal Redirects

Internal redirects are commonly used for SEO purposes and often incorporated due to different activities across the website – ads, popups, dynamically fetched data. They could aim for the homepage of the website or an internal page – a lightweight request that still fetches a lot of data on the fly.

While some are inevitable, part of those requests can be avoided or at least cached for better performance, preventing security reports, and leading to a more stable workflow.

Solution: Inspect the number of internal redirects while rendering certain areas of your website. Try to decrease the number of required redirects or avoid them as a whole. Whenever internal redirects are required for some data processing reasons, make sure that caching is in place and you can leverage a valid data which is stored in the object cache or the page cache of your website.

13. Overusing WordPress APIs When Not Applicable

Leveraging the APIs provided by WordPress is usually a best practice and should be followed whenever that makes sense. Plugins are complying with the available WordPress APIs and can introduce additional behavior without extra programming.

However, WordPress is not designed to fit each and every use case out there. Large websites may be locked within the existing database architecture or the default admin interface for certain portions of their website – which may consecutively affect the overall performance.

Solution: Consider building certain layers of the website yourself. Stick to the WordPress architecture and API whenever possible and extend that when that would drastically improve the stability or performance. You can build micro-dashboards or separate pages leveraging the REST API for various sections of your website. Or create normalized database tables for data which doesn’t fit the standard schema designed in WordPress. Or build intermediate layers working beside your existing infrastructure.

Mario Peshev

Get personalized leadership advice and monthly goal assessment

Database Management

Various caveats when using the default WordPress database schema along with the way the WordPress Core works.

14. Default Content Management for Post Types/Taxonomies

Storing data in WordPress comes with certain best practices that are suitable in most use cases.

As discussed in the previous point, that’s not always the case for large websites that need to squeeze the best out of performance and stability.

For instance, WordPress post type entries are stored in the {prefix}_posts table and their metadata is populated in the {prefix}_postmeta table. Due to the nature of the schema, each meta field is stored as a separate row. That leads to growing the postmeta table immensely as your WordPress data grows as well.

Some plugins try to store metadata by serializing information within a single array and thus storing a single row. This makes the programmatic updates of serialized data slower and more complex. Filtering in advanced search forms is even more challenging.

Solution: Consider extending the current database schema in a way that supports your business needs. You can create custom tables that store all of your required fields in one row – making it easier for searching, updating, filtering. Or introduce certain constraints in order to improve validation across different devices working with the same database. Don’t forget that this may require additional code for WP_Query calls or building your meta boxes in the dashboard.

15. Excessive Volume of Database Queries

This one is more common than not and could be caused by plugins, the theme, 3rd party services, and the WordPress core itself. A higher volume of database requests across the site impacts the stability and responsiveness of the database and serving database requests to different users.

Solution: Review the SQL queries generated by your WordPress plugins and your theme in different areas of your website. Some components may be disabled or moved to their corresponding pages. Other queries could be optimized. You can combine some queries by replacing them with more suitable ones and reduce the number of database requests as well.

Each business case is different. Object caching certainly helps (along with page caching) but that still impacts the first visitor after purging the cache. It also affects the database as a whole and adds on top of your dynamic, non-cached requests.

16. Storing Multimedia in the Database

For the most part, WordPress stores uploads and assets in the uploads/ folder within wp-content. Theme and plugin assets are usually served from within their corresponding folders or loaded externally.

Some document or video management solutions store data as BLOB entries in the database. While this makes sense in certain scenarios, it’s likely that this would have a massive impact on your overall load times within your database.

Solution: In case you’re storing data as BLOB entries, consider switching to an Amazon S3 bucket or another secure external storage with the right credentials and authentication for secure review and access. See if using a video hosting solution or another document management platform would fit into your WordPress architecture design, too.

17. Excessive Load of Autoloaded Options

WordPress stores various settings and options related to your website and config arguments from various plugins in the options table. Other than polluting the table if used improperly, the large volume of autoloaded options may impact the site speed and the database load when fetching tons of information that’s not widely used across the site.

The main idea of autoloaded options is running a single query that would pull the most widely used options across the website instead of a repetitive set of separate queries. The problem is that functions such as update_option for missing entries would create an option that is automatically loaded – thus frequently leading to hundreds of generic options stored in RAM.

Solution: Inspect the autoloaded options ran for every single page request. Update the ones that are not widely used or available only in the dashboard. Clean up the options table if some of those entries are no longer in use (deactivated plugins or upgrades).

Custom Code

Various issues related to programming new plugins and leveraging 3rd party solutions that are affecting the overall stability and productivity of the platform.

18. Omitting Established Design Patterns

PHP is a fairly flexible programming language that doesn’t necessarily define a tight set of best practices. There are different approaches to building a plugin or a framework and some are suitable for different use cases.

Given the WordPress Life Cycle and the variety of features that a website can incorporate, implementing some established design practices, sticking to the right WordPress APIs and deciding on the right approach for building a plugin’s architecture may be crucial for the long-term stability and reliability of your web application.

Solution: Always conduct an extensive code review of 3rd party plugins, libraries, and frameworks before incorporating into your platform. Carefully review the code produced by your WordPress team and refactor it as needed.

19. Lack of Compliance with Scalability or Security

Custom WordPress plugins or themes may solve a multitude of problems for various industries. The best approach for building a large and scalable WordPress website is crafting custom-made solutions tailored to business needs.

This results in a maintainable code base with less technical debt and overhead.

That is dependent on the technical team that has to pay attention at all times to stability and security. Implementing the best practices both in terms of WordPress standards and business needs is of utmost importance. Always ensure that your application implements the right solutions and can scale without opening security leaks for non-authorized users.

Solution: Introduce some key indicators regarding speed and security for your application. When assessing a new solution, work along with a consulting company that specializes in penetration testing or at least utilize some of the available solutions on the market. Test your code base with a lot of production data in order to identify possible memory leaks. Run some load/stress tests in order to measure the resilience of your server environment.

20. Misusing the Default WordPress APIs

WordPress provides a set of APIs used by tens of millions of websites. WordPress developers may stick to the original design by adhering to the best practices when using the existing WordPress APIs.

There are several problems that could occur while building a new solution integrated in a new website.

  • Not using an API which would be a good fit for the application
  • Using the wrong functions or classes for an API that don’t utilize caching or would conflict with other available solutions (such as query_posts() vs. get_posts() vs. a new WP_Query object)
  • Overusing the WordPress APIs when a custom solution would be more applicable in terms of stability or scalability

Solution: Carefully revise the architectural decision when building a new component. Does a new admin page need the Settings API? Are custom fields suitable for the Metadata API or would rather require a new database table? Is running a custom database query for a subset of posts something that could be accomplished more efficiently with a WP_Query request?

21. Serializing Data During Filtering

Storing new information in the database could come in different shapes – utilizing the established APIs, serializing data, creating new database tables, offloading to 3rd party solutions.

There are certain scenarios where serializing data in order to prevent creating multiple new rows for a single entry may cause problems. Performing effective database queries dealing with advanced search or product filtering may be severely challenging for the database load and the overall website performance.

Solution: Decide on the right storage mechanism for your use case. Avoid polluting the database when it doesn’t make sense and make sure that features requiring filtering and advanced search can be implemented with effective database queries without a ton of internal processing or conversions.

22. Performing Custom Built Complex Search and Archive Queries

The standard database schema is overall effective in terms of populating new information and fetching standard archives or single views. Performing complex and conditional search and filtering queries may become a challenge for high-scale websites targeting customers who depend on a powerful search engine.

Certain solutions like Elasticsearch can be of help but they also depend on your original database storage.

Some themes may even affect strategic pages such as the homepage of the website. When fetching featured images for a list of popular posts or published data, WordPress may trigger a separate query for each post instead of enumerating post IDs and fetching the entire data set in a query or two.

Solution: Complex queries, navigation, filtering, and search options should be discussed as early as possible. There are third-party solutions and libraries that could ease the pressure from building a complex search engine within WordPress. Even standard requests require special attention. Benchmark your existing solution and decide on the best approach for building an effective engine that doesn’t perform slow queries or large sets of separate queries for the same type of problem.

23. Missing Minified and Combined Scripts and Styles

There is a limited number of parallel HTTP requests that a browser can make in order to render the full page. That includes the initial page load, images, CSS files, scripts, fonts, and 3rd party services.

Minifying the scripts and styles would reduce the size of those requests and speed up the load times (less bandwidth wasted during a request). Combining scripts and styles together will limit the number of consecutive requests performed by the browser while loading the page.

There are plenty of problems that may occur, though. Aligning scripts and styles in the right order is paramount – otherwise, you will break certain dynamic features or break the styling of a page due to overriding the wrong selectors. Some scripts should be added to the header while others have to stay in the footer – which may impact your decision, too.

Solution: Make the best out of minifying and combining scripts and styles for your WordPress website. Carefully test each and every feature in order to prevent regressions. Consider refactoring your code or extracting snippets from certain libraries that are carrying over plenty of unnecessary code base. Use precompilers for Sass or LESS in order to maintain your codebase in a more organized manner. Keep an eye on when performing plugin updates which may affect the stability of your combined files. Test on different browsers that could report different issues for certain scripts.

24. Loading Fonts Offsite

Modern online businesses are no longer constrained to a limited subset of fonts for their digital presence. Which is why services such as Google Fonts or Typekit are that popular and widely distributed.

However, a default implementation or a wide range of fonts across the site may impact the load and render times and the look and feel of the site before loading all fonts.

Solution: Whenever possible, don’t load fonts from external resources. Typekit has occasional outages. All external resources may take a while to create a reliable connection and serve your fonts accordingly. At peak times, it’s possible that a paid fonts service may hit a limit and reject a request for fetching a certain font as well. Otherwise, make sure that you’re using suitable fallback fonts at all times.

Otherwise, make sure that you’re using suitable fallback fonts at all times. Switch to a very slow connection (such as GPRS tethering – could be triggered in some browsers) and see how your copy looks on different pages before the new fonts take effect.

3rd Party Services

Discussing the dependability and possible caveats whenever using 3rd party services.

Disclaimer: External services may be desirable in plenty of cases – but use them wisely and keep into account the possible repercussions.

25. Relying on Slow 3rd Party Services

A decent medium-sized or large/enterprise WordPress platform likely interacts with a number of 3rd party services – HubSpot or Salesforce, a number of analytics tools, an opt-in solution, a business-specific platform for car rentals, real estate listings, a job board integration and the like.

Different platforms are built in various ways. Some load JS scripts embedded on the site. Others have WordPress plugins that bridge the features accordingly. Some are implemented as iframes. Or require a set of REST/SOAP requests transferring data both ways.

While external solutions may reduce the impact on the database or the code triggered on the web server, it’s likely that the render times would be higher until all resources are loaded in their entirety. This may affect the load times and the customer experience whenever the page isn’t fully loaded and visitors see jumping boxes all over the place.

Solution: Always assess 3rd party services before integrating them in a WordPress platform. Consider the standard workflow. Review the required code base and what is the impact on the overall platform. Review all data stored in the WordPress database. See if the scripts required are loaded only in the designated areas. Consider the impact on loading a complete page and what is visible by customers in different scenarios. Keep in mind access control and rendering the right data to the right user roles if needed.

26. Hitting 3rd Party Limits

Working with 3rd party services may lead to reaching their limits. As a result, several things could happen – the 3rd party component may be disabled, an error may be displayed to your users, requests could be throttled thus slowing down your site – not to mention the surcharge that could follow. Consequences could vary dramatically depending on the case.

Solution: Carefully review the limitations of the service in use and ensure that the WordPress utilization sticks to healthy limits. Build fallback handlers that would take care of whenever those limits are reached. Moreover, protect yourself against downtime – third-party services could also face technical challenges and you don’t want to depend on these as a result.

27. Lack of Preprocessing Data Before Offloading

Sending data to a third-party is usually somewhat automated. However, dealing with large volumes of information in WordPress may lead to delays in processing a request, multiple queries to the same engine, or slower processing and filtering afterwards.

This could be the case with lead generation or marketing automation tools, data analytics platforms and more.

Solution: Monitor your load times and the quality of the received data. Consider optimizing the outgoing data by preprocessing and filtering on the server side. If you control the external environment, consider packaging it up in a way that requires a single response and could serve the business needs without additional computation.

Note: the list will keep expanding with additional notes on SEO, media management, hosting, caching, security. Take a look at our Retainer plans if you’re interested in talking more.

15 thoughts on “25+ Business Scaling Mistakes Running a Large WordPress Website”

  1. Collins Agbonghama says: December 7, 2017 at 10:12 pm

    Wao!. this is a great resource for anyone looking to avoid pitfalls and build large web app in WordPress.

  2. Mario Peshev says: December 8, 2017 at 1:17 am

    Thanks Collins!

  3. Shivam Sahu says: January 5, 2018 at 12:42 pm

    Great article, and while I knew most of these tips there are a still a few I didn’t know about. One thing I see on some new (and maybe even older) WordPress site is people don’t disable/remove the meta admin widget from their sidebar. No reader/viewer/client/customer, etc needs to see a link for you to log into your WordPress dashboard when they got to your site. That tab is completely useless (just go to yoursite.com/wp-admin) and should be removed as soon as your site is active.

  4. nofearinc says: January 5, 2018 at 3:00 pm

    Thanks Shivam. I have a number of additions in my backlog and the post will be updated on a regular basis with additional suggestions and areas that need work for sites receiving a good amount of traffic.

  5. Marc says: April 30, 2018 at 10:55 am

    great article and a very helpful Website! i will recommend it to my friends…

  6. ep6tri says: November 13, 2020 at 5:24 pm

    Wonderful post! I live in South Korea, and I am a small WordPress developer. The post contains almost everything that I want to tell about developing with WordPress. Although I am not good at writing in English, but I am sure that I can translate the post in Korean. Can I translate your post into Korean? If you allow me, I will try to.

  7. Mario says: November 13, 2020 at 5:27 pm

    Yes, that’s fine, feel free to post the link to the Korean post once translated 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *