Auditing a website in development
Product Owners and developers want to create the most amazing experience there can be for their users. Solutions that not only dazzle them, but also make them think the brand is the most modern company they can buy their things from. It is easy to forget the main reason for having a website in the first place is - to be found so that the users can interact with the content on it and go through a transaction of either money or contact information.
The main goal with a new website is almost always to gain more visibility, traffic and often conversions.
It is extremely important that important pages are built in a way that searchbots can crawl, index and rank them! That’s where we SEOers come in.
For us and our clients, the way to handle this new JS world inferno, has been to break everything down to smaller pieces, creating detailed requirements so that the devs know in beforehand what I will be looking at, iterative learning sessions about both SEO and tech, and then when it comes down to the testing - both me and the devs already know what I will be auditing. The devs usually already have tested the requirements and have ideas for solutions of how to test before launching the site to prod.
The process usually looks like this:
- We set requirements and talk to our developers, making sure they are looked at and understood
- We identify the different page templates (which helps with the testing)
- The requirements are used to set up test protocols
- We ask for frequent demos during development and to be a part of the dev team and participate to all dev planning meetings
Time for Auditing
With a toolbox containing Chrome DevTool, Screaming Frog and a few chrome add-ons, it's time to get cracking and audit the page types.
✅ The first and maybe most important requirement and thing to audit is - will the searchbot be able to crawl the pages.
Requirement: All on-page elements with content should be available in the rendered code.
Check: Chrome dev tool manually per page type, and with Screaming Frog.
Look for: Links, menu, CTAs, footer links, images, text, videos and in fold-out elements that the content is in the rendered code.
Check: the robots.txt manually and with the help of screaming frog. I often ask the CSS to be reachable as well, as it makes my job as an auditor way more easy if I can see the page properly.
Look for: disallowed paths that contain JS assets, crawl with SF checking the respect robots.txt and then check the JS section.
✅ It should go really fast to load a page (like the page you are reading now 😎)
Requirement: Time to first paint shouldn’t be exceeded by loading large JS resources. If we are looking at a CSR page and the assets are large, can the devs bundle and split the JS? If it's a SSR, and the assets are too heavy, can it be solved with caching?
Check: Chrome dev tool manually per page type.
Look for: number of resource calls, big chunks of loadings, how fast can the first paint be painted?
✅ Make sure that the metas in the first load differ from metas in the rendered code
Requirement: The meta data in head should be correctly set up and not changing while rendering.
Check: Use View rendered source add-on.Look for: Title, meta description, canonical, OG:s, hreflangs.
Learnings from auditing 14+ new sites during the covid years
Yes, the covid years were all about new websites. Every shop needed a webshop and every established ecom needed updating to take care of the demand.
Good luck and have fun! 🦄