When building custom web applications, most of the engineers forget or simply are not focused on SEO strategies and miss on some basic rules. These do not affect the application’s functionality, but can lead to a SEO ( further as Search Engine Optimization) nightmare. Today we’ve decided to share some of our team’s do’s and don’ts that will increase your application’s visibility without compromising on your user experience.
Set a proper structure for your access pages
There’s an unwritten rule about structuring a website that contributes to SEO and your customer’s satisfaction. Delivering what matters is crucial, therefore, the most important pages of your app should be accessible in less than 3 clicks. This really works not only for SEO, but also for enabling a good user experience
Don’t use extensive paths and/or vars
Let’s say you’re selling apples and you have a catalogue to display. You’re clicking on a juicy Macintosh and when you want to save that link and share it with your friends, you get something like this:
If you want a proper SEO optimization for your products or blog articles this is a big don’t. Try to keep your link structure as simple as possible.
Here’s how that “nightmarish” example should look:
Trim Down HTML your code
We’re not code-shaming any app – it’s just that “fat” codes take longer to load. For instance, a 250k HTML page loads in 140 ms and this is why we’ve settled for a “rule of thumb”: we keep HTML page size under 200k.
Don’t split your JS/CSS into multiple files
“minify” your JS and CSS files
One way of placing your HTML, CSS and JS code on a diet is by making use of the so-called “minifiers”. These tools compress the original code size and do not its operation by removing unnecessary characters from the code like white spaces, new lines, code comments, etc. If done right, you can end up with all of that code in one line. It is a big deal since such woo-do magic can reduce 10% to 95% the code’s size, ease the workload of your server and as a bonus, your (SEO) score will be forever grateful.
Don’t keep large images locally
While hosting your JS and CSS files locally is a great decision, keeping IMG files locally can drag down your page load times. This is why using images placed on another server might be a great cheat for increasing optimizing your page. Gzip your HTML files Another useful thing to do is compressing your text-based files. You can do this via gzip, a UNIX compressor that’s is there specifically for your HTTP requests. With its help, you can compress a 100kb HTML into a 10kb file easing the load on your browser.
Make sure your cache is enabled
You’d be surprised what cache can do for you (or not). We all know that cache is that temp storage a computer uses, so why should you ignore that resource? If the cache is enabled for HTTP headers, you serve visited documents/pages, without requiring an additional trip to the web server, increasing availability for operations like back/forward navigation, saving, viewing-as-source, etc.
Don’t keep your cookies in the server’s jar
Back in 2007, the standard practice was to store session data on the server, typically in a file, a database, or a distributed memory cache. We’re in 2018 now and our cookies became heavier and because of that, they started to mess with client/server latency metrics, which is really bad for SEO. Just consider the fact that a 1000-byte cookie adds 16ms to the response time of a single request made over a broadband DSL connection (and yes, ADSL still holds 95% of the broadband market). Instead, let the client’s machine take the load.
Say yes, yes and yes again to a proper schema.org, favicon and social media tags
If you want your app to be among the richest results up there, you must definitely use a favicon, have a good structure of your data and social media tags. This way, your app won’t be a random search result or post with boring text, but a nice-looking structure that would outline the app’s purpose, main contact data and/or your logo or a presentation video.
As long as you keep track of the above dos and don’ts, you’re safe. Keep in mind that we’ve only outlined the most critical and basic things noticed in apps that have been refactored by our team. While there are even more aspects to be considered, these were met way too frequently in our day-to-day practice.