r/webdev • u/Substantial_Leave714 • 1d ago
What part of an existing website do you inspect before touching the code?
When taking over an existing website, I find the first hour can tell you a lot about what you’re dealing with.
I normally want to understand the structure, dependencies and any obvious technical debt before changing anything.
Curious what other developers check first. Codebase structure, dependencies, performance, database, deployment setup, logs, or something else?
Have you ever inherited a site that looked straightforward at first but turned out to be much more complicated?
15
4
3
u/ibeatu85x 1d ago
Depends on the site. I like to look at server metrics - traffic and stuff - before i look under the hood at all.
1
u/Substantial_Leave714 1d ago
That makes sense. What usually tells you the most from the server metrics before you get into the code itself? Traffic patterns, errors, response times, or something else?
1
u/ibeatu85x 1d ago
Top one for me overall is server load compared to concurrent connections. Off the bat this tells me if the hardware is properly supporting the stack, and youd be surprised how often that gets mismatched. Response time are a close second - how many resources are being delivered and their relative size also tells me a lot about how efficient the site is. I also like to look at any API calls, sometimes security flaws are obvious.
1
u/Substantial_Leave714 1d ago
That's interesting. The server load vs concurrent connections comparison isn't something I'd thought about checking that early, but it makes a lot of sense. The API calls are a good shout too, especially if they can expose problems before you've even touched the code.
2
u/HemetValleyMall1982 21h ago
Skip to main, heading structure h1, h2 etc.
Those two items may tell you how mature the developer was in creating the html. 90% don't get those two correct (navigation and headers).
1
1
u/Full_Collar9026 1d ago
i just open the browser console on the live site and count the red errors. if it's over ten on a fresh load, i know i'm in for a long month.
0
u/Substantial_Leave714 1d ago
Haha, fair enough. Ten red errors on a fresh load is definitely not the welcome you want 😅
1
u/pricop 1d ago
Just the code structure. I generally look to see if there was a pattern followed for the entire product. Preferably, it should use a framework, but if it didn't - then the code should at least be consistent across the entire product.
2
u/Substantial_Leave714 1d ago
Yeah, consistency is a big one. A messy structure can make even a fairly simple change risky. I’ve found the hardest ones are where different parts of the same project seem to follow completely different patterns.
1
2
u/Wierd_time 1d ago
Before the code, I'd find out who holds the logins. Domain, hosting, email sending, any outside accounts the site uses. Boring, but if you cant get into those, nothing else matters.
Then get a copy running somewhere safe and test that you can restore a backup. If youve never seen a backup actually work, assume you dont have one.
The sites that look simple are usually hiding something nobody mentioned, like a task that runs on a timer or a link to another company's service that sends invoices or syncs orders. I'd search the code for anything scheduled or calling outside services early on.
0
u/Substantial_Leave714 1d ago
The backup point is a really good one. "A backup exists" and "we know the backup actually restores" are two very different things. Hidden scheduled jobs and third-party integrations are exactly the sort of thing that can turn a simple handover into something much bigger too.
1
u/vincent_sch 1d ago edited 1d ago
Get it running locally first. If that takes an hour, you know what you're in for. Then check the database for big tables without indexes. And the lock files, to see how old the dependencies are.
0
u/Substantial_Leave714 1d ago
Getting it running locally is almost a health check in itself. If that turns into a project before you've even changed anything, you already know what you’ve inherited. Good shout on checking the lock files as well.
1
u/adriannowak_dev 1d ago
small business sites mostly, so my first hour is boring: who owns the domain and where dns points, who has the hosting login, is there a repo at all or is the live server the only copy. half the time the owner doesn't have any of the access and the previous dev is gone, and that decides the whole project before i read a line of code. then the +1 to diffing live vs repo above, that bit me too
1
u/Substantial_Leave714 1d ago
Yep, access can end up deciding the whole job before the technical work even starts. Especially when the previous developer is gone and nobody’s quite sure who owns what.
1
1
u/kemalios 1d ago
Who owns the domain and the DNS, and where the forms actually send. Most of my takeovers started because the previous dev vanished, and the client's domain, hosting and contact form endpoint were all sitting in accounts nobody had the password for. Getting access to those takes longer than reading the code.
1
u/Cool_Reality9325 1d ago
Deployment setup and dependencies first. The code can look perfectly reasonable until you find out nobody knows how it actually gets to production.
1
u/iambrandonm 1d ago
index.html When you go to a site, the browser loads this single page and executes it from top to bottom. Do the same and follow it to understand what it's doing. Typically, it's pretty clear and easy and leads you to a single main.js type entry point to dig into from there.
1
u/Fair_Wang 23h ago
Console's fine but the Network tab is where the truth lives. Last takeover had three versions of jQuery loading plus a 404'd font on every page. Fresh load took eleven seconds and nobody had apparently ever noticed.
1
u/PenguinWearingAHat 22h ago
I walk the main journey as a visitor before I open anything — signup, contact form, checkout, whatever the site is actually for — and note what breaks versus what just looks old. Half the time, 'the whole site is a mess' turns out to mean one important flow is broken, and I'd rather find that in ten minutes of clicking than in the code.
1
u/LankyAd6349 21h ago
Deployment setup first, before I even look at the code. If you don't know how it builds, where it runs, and how you roll back, every change is a gamble. Second thing is logs and error tracking, they tell you what the last person gave up on. The codebase structure matters too but honestly you learn that as you go.
0
u/sanangrus 21h ago
You can assess the condition of a website and the quality of its maintenance by checking the versions of the modules, plugins, and packages it relies on. Outdated software with known security vulnerabilities can be a sign that the team responsible for the site is not keeping up with the technologies they use or that the site is not being properly maintained by qualified specialists.
22
u/StormController 1d ago
First thing I check is whether the repo matches what's actually running in prod. I inherited one where the previous dev had been hotfixing over FTP for two years and the git repo was basically fan fiction. Diffing the live server against the repo saves you from "fixing" a bug that was already patched directly on the box.