How to check the site before publishing: 38 points to control
Developing a website is one thing, but "release it to the world" is quite another. Want to avoid embarrassing failures? Check the site before publishing according to our checklist.
- Test notifications about orders and registration for the site owner, make sure that all data comes in full.
- Set up an auto-responder with a real e-mail so that the visitor can reply to an automatically generated email.
- Make a copy of the box, which will prevent the loss of letters. Create an alternative channel for receiving applications.
- Record requests separately by creating an external database.
Thank You Page
- Make sure the Thank You Page opens after each order.
- Check how relevant and simple the forms are, where surnames and phone numbers are supposed to be entered.
- The test site after the launch of the "main" site must be closed. It is better to check it from another IP, and not from the one from which the placement was carried out.
- Opt out of the firewall and robots.txt to prevent indexing. Otherwise, you will get a site that is inaccessible to search engines, unavailable for indexing.
- It is better to close the test site through Apache: the system will ask for a username and password, but no IP is required for authorization.
All debugging modes must be disabled. Make sure you have done this:
- If the site is on WordPress, then the value of the constant should be WP_DEBUG;
- If other CMS are used, then set the .htaccess directives php_flag display_errors, php_flag display_startup_errors, php_flag html_errors to off.
- Look at the date the cache was created in chrome://cache/, where the required css/js files are listed.
- See if all file versions in the page's source code are up to date.
- Make sure that all changes after publication open without unnecessary page refreshes.
Access from different browsers
Typesetting "for everything" will not work, but if from another browser your site is seen as paintings by Kandinsky, this is not good. That's why:
- Test the site on different software and different devices. For testing, the Cross Browser Testing service is suitable.
If we are talking about adaptive layout, then it is tested on smartphones - everything is simple here. And if the site is dextop, then:
- Evaluate how well the desktop version scales on smartphones. Get the viewport tag right and test everything.
- Set a stub for mobile users - let them see the contacts of the mobile version instead of the site.
- Installing a preloader is a real lifesaver for layouts with a "heavy" background, for users with a slow connection. This is where it's worth the wait before seeing the perfect design.
- Check the download speed using standard developer tools. A preloader is required if the loading time is more than 3 seconds.
- Favicons must be compatible with all major operating systems so that the user can bookmark the site anywhere and at any time. Check them out with Real Favicon Generator.
- Open Graph meta tags
- Check the meta tags through the appropriate service. By using the correct Open Graph page markup standard, you will be able to correctly display site previews on social media when links are mentioned.
What if SEO fails?
What affects the position of the site in the search engine? No one knows. As well as there are no instructions on maintaining the site's position in the TOP after a redesign or any changes. However, you can avoid "jambs" in advance if:
- Register redirects for the most visited pages, as well as for those to which advertising links lead. Use a 301 redirect with htaccess and php.
- Remove "broken" links, that is, those that lead the user to a 404 page. You can check their availability using online services. By the way, the Topvisor service will also demonstrate other critical errors (for example, it will highlight the absence of a description in red).
- Check through the browser for the presence of sitemap.xml and robots.txt files.
- Register in Yandex.Webmaster and Google Search Console by adding a new site here. Otherwise, indexing can not wait.
The most banal security errors can lead to failures after site placement. So, if e-mails are not encoded, then the owner's mailbox will "break" from spam. The recommendations here are:
- In the source code of the page, you need to check if there is @. Use search: Ctrl+U for Windows and Alt+Cmd+U for MacOS.
- Use the password generator to close the site's admin panel. Also enter the admin username.
- Use Wordfence for WordPress sites. This plugin will allow you to track common site vulnerabilities, suspicious activity, and also conduct a full automatic scheduled scan, including the search for dangerous functions in the code. The plugin can also track traffic in real time.
What else could go wrong?
Here is a list of fakups that must be "neutralized". So check:
- what your 404 page looks like.
- the presence of a counter in the source code.
- whether data is received by the counter, whether attendance reports are received in the personal account.
- that there is no hardcore test domain: go through several pages, comparing the browser strings and their appearance in the source code.
- main page title. In Chrome, hover over the tab and make sure "Just another WordPress site" is not there.
- that the "Hello, world!" page also removed.
You should also do the following:
- Save the old site by cross-referencing between versions. All links should work well. Don't worry - most conservative users will appreciate new developments sooner or later.
- Do load testing. Use services like Load Impact to see how well the server is handling the load.
- See how successfully the files are uploaded to the admin panel. Check the correctness of generating temporary files, including captchas.
And the last thing: even if you find a failure, do not fix it in emergency mode. Adrenaline and time trouble are, of course, good, but not in the case of the site. So take enough time. Otherwise, there is a big risk of making things worse.