Specifying a dedicated server is a set of trade-offs where the expensive choice is often not the useful one. The right specification comes from knowing what your workload is limited by, and most people buy against the wrong constraint.
Find out what actually limits you first
If you are moving from an existing server, measure it before choosing anything.
Watch CPU, memory and disk activity during your busiest hour. One of them will be the ceiling, and the others are usually nowhere near it.
Buying more of something you were not short of is the most common and most expensive mistake here. Monitoring Performance and Server Health goes into the commands that show it.
Cores or clock speed
These solve different problems, and the difference matters more than the total core count.
More cores for many things happening at once: a busy web server, a reseller machine with many accounts, anything serving concurrent requests. Each request gets a core; more cores means more at the same time.
Higher clock speed for work that cannot be split: a single-threaded application, a database query that runs on one core, a slow page nobody is waiting behind.
Most hosting workloads want cores. A sixteen-core processor at a modest clock serves more concurrent visitors than an eight-core at a high one.
The exception is a site whose individual pages are slow. More cores do not make one page faster: they let more people wait simultaneously.
Memory is the one to be generous with
Running out of memory is qualitatively worse than running out of the others.
A server short of CPU is slow. A server short of memory starts swapping to disk, which is orders of magnitude slower and makes everything grind. When swap is exhausted, the kernel kills processes: usually the database, because it is the largest.
So a server appearing to die at intervals with the database stopping is nearly always memory.
Budget for peak rather than average. Memory is also the cheapest thing to over-specify and often the only component you can add later without downtime.
ECC memory detects and corrects bit errors. On a machine running for years continuously, that is worth having: a silent memory error corrupts data without anything reporting a fault.
Storage: NVMe unless there is a reason
NVMe SSD is dramatically faster than SATA SSD for the small random reads a database does constantly. On a database-driven site this is the single largest hardware difference available.
SATA SSD is fine for serving files and for anything not doing heavy database work.
Mechanical disks only for bulk storage, backups, video archives, anything read sequentially and rarely. Never for a database.
A mixed configuration is often the best value: NVMe for the operating system and databases, larger mechanical disks for backups and media.
Capacity: count what you will actually store
Sites, databases and mail, then double it. Mail in particular grows without anyone deciding to grow it.
Then add room for backups if they live on the same machine, and remember that a backup on the same machine is not protection against the machine failing. Backups and disaster recovery goes into it.
A server at 90% disk is one log rotation away from a full one, and a full disk stops everything at once.
RAID changes what you are buying
Two disks in a mirror give you the capacity of one. Four disks in a mirrored stripe give you the capacity of two.
People compare quoted disk totals without accounting for this and end up with half the space they expected. Decide the RAID level and the usable capacity together. Setting up RAID sets out choosing the level.
What to leave out
Two things are commonly bought and rarely needed.
A GPU, unless you are doing video transcoding or machine learning. It does nothing for a web server.
Enormous core counts for a site that is slow because it has no caching. A bigger machine makes an uncached site cheaper to ignore rather than fixed, and the caching would have been free.
Think about what is upgradable
Memory can usually be added, which needs a reboot and a scheduled window.
Adding disks depends on whether there are free bays: worth asking before ordering, because a chassis with all bays full means the next storage increase is a new server.
Changing the processor means a new server in practice. So specify the processor for where you expect to be in two years, and the memory and storage for now.
Managed or unmanaged changes the calculation
An unmanaged server is yours entirely: updates, security, diagnosis, recovery at three in the morning.
Cost that honestly. A cheaper unmanaged server plus the hours you spend on it is frequently more expensive than a managed one, and the hours arrive at the worst times. Introduction to Dedicated Servers deals with the wider trade.
Whether you need one at all
Worth asking before specifying anything.
A VPS with dedicated resources handles a great deal, and it can usually be resized in minutes rather than requiring a migration. A dedicated server earns its place when you need the whole machine's capacity, specific hardware, or single-tenancy for compliance reasons. Comparing the tiers goes into it plainly.
If the honest answer is "the current server is slow and I do not know why", find that out first. It is often a missing index or an uncached page, and neither is fixed by hardware.
Where the machine physically sits decides latency, jurisdiction and how quickly a failed disk is replaced. How to Choose a Data Centre Location walks through weighing them.