Multiple rounds of hashing with a regular hash function (e.g. SHA256) used to be a reasonable approach, but these days it does not really provide strong resistance against modern cracking approaches such as GPUs and FPGAs/ASICs. One reason for this is the availability and low cost of commoditised hardware implementations of SHA-family hashes, largely due to the popularity of cryptocurrency mining.
What you're describing is a little like PBKDF2, which utilises a large number of rounds of a pseudorandom function (PRF) such as HMAC-SHA2. However, it is important to note that cascading hash functions (e.g. using both SHA1 and SHA256) is not particularly useful here. The goal is to force the attacker to eat up a lot of CPU time (and other restrained resources, e.g. memory bandwidth) so that cracking the hashes is infeasible. Using a lot of different hash functions doesn't help in this goal. It also makes you beholden to a lot of different implementations, which increases the likelihood that one of them has a bug, and reduces portability if you want to replicate your hash function design elsewhere. Ultimately I would avoid any situation where you need to implement any kind of cryptography - just use a premade library/function for password hashing and be done with it.
The current recommended approach is to use a function which is both CPU-hard and memory-hard, such as Argon2. Such functions are designed to somewhat level the playing field between CPU, GPU, and FPGA/ASIC attack models by introducing operations that don't optimise well across any of them.